Paul De Vrieze
email: pdvrieze@bournemouth.ac.uk

Lai Xu

Resilience Analysis of Collaborative Process Management Systems

Keywords: Collaborative process systems, resilience, federated process management, process resilience

Process management allows for the automated coordination of processes involving human and computer actors. In modern economies it is increasingly needed for this coordination to be not only within organizations but also to cross organizational boundaries. The dependence on the performance of other organizations should however be limited, and the control over the own processes is required from a competitiveness perspective. Overall, this indicates a federated process management approach instead of a centralized one. This paper analyses the resilience of automated process management overall and especially how the use of federated process management impacts that resilience.

Introduction

Collaborative networks as a relative new scientific discipline [START_REF] Camarinha-Matos | Collaborative networks: a new scientific discipline[END_REF] have been applied to application areas such as Factories of the Future [START_REF] Effra | Factories of the Future 2020 Roadmap[END_REF], Manufacturing and logistics networks [START_REF] Alice | Information Systems for Interconnected Logistics Research and Innovation Roadmap[END_REF]. Organizations, enterprises, and communities are interconnected by networks in the new application areas. To support such collaboration in a hyperconnected world, existing technologies need to be improved and adapted in terms of larger scale integration and more intelligent devices, sensors and cyber-physical systems involvement.

The scope of business collaborations can be limited to a particular department in an enterprise, it may span multiple divisions within an enterprise or it may require interenterprise collaboration. In this research, we are especially considering how to manage interenterprise collaboration, i.e. collaborative business processes are executed among enterprises. In this work, we consider that (web) services and human interactions are coordinated through an automated process management system to form an SOA. In a traditional approach, the process management system forms a single point of failure. We defining resilience as the degree as to which the system can continue to meet its goals in the presence of errors. Based upon an analysis of different structures for federation we have analyzed how process federation can impact overall system resilience.

In this paper we focus on federated control of collaborative business process systems as well as analysis of resilience related the federated collaborative business process systems. Federation in this context is the coordination of the execution of individual business process instances by multiple independent process engines. In the next section, we review challenges of collaborative networks and collaborative business process managements, federated control of information systems, large-scale systems, business process management systems/business services, and cloud services. In Section 3, different management types of federated collaborative processes are classified. Resilience of the federated collaborative processes is reviewed in Section 4. The paper is end with a summary of the paper and future research.

Related Work

Increasing importance of value chains and production networks, of interconnected organizations, collaboration dynamics, outsourcing, and the increasing potential of new ICT technologies supported innovations has driven research of collaborative networks [START_REF] Niehaves | Collaborative business process management: status quo and quo vadis[END_REF]. Collaborative networks [START_REF] Dong | Cooperative Federated Multi-Agent Control of Large Scale Systems[END_REF] [13] and collaborative business process management [START_REF] Liu | Challenges and opportunities in collaborative business process management: Overview of recent advances and introduction to the special issue[END_REF] [START_REF] Niehaves | Collaborative business process management: status quo and quo vadis[END_REF] have been fostered by globalization over decades.

Federated control method has been applied into different areas. Federated information management architecture is provided to manage information across different organizations in virtual organization domain [START_REF] Afsarmanesh | Federated information management for cooperative virtual organizations[END_REF]. Different management level schemas of federated databases are specified for interoperation.

Systems control is another research area which federated control methods has been applied [START_REF] Dong | Cooperative Federated Multi-Agent Control of Large Scale Systems[END_REF]. In this area, large-scale systems normally consist of several interconnected local systems, which conventional centralized control schemes are not suitable for due to global dynamic behavior complexity and computational difficulties. Many multi-agent based federated control systems are used to high performance computing area. Federated Cloud Services [START_REF] Buyya | Intercloud: Utility-oriented federation of cloud computing environments for scaling of application services. InAlgorithms and architectures for parallel processing[END_REF] [9] [START_REF] Konstanteli | Elastic admission control for federated cloud services[END_REF] emerges recently to deploy and to manage multiple external and internal cloud computing services for meeting business needs.

Paper [START_REF] Erol | A framework for enterprise resilience using service oriented Architecture approach[END_REF] proposes a framework to create enterprise resilience using service oriented architecture approach. Antunes and Mourão consider a framework and related services for building resilient business process management [START_REF] Antunes | Resilient business process management: Framework and services[END_REF]. Both works are not look at resilience of collaborative systems. Previous work on federated business process management [START_REF] Kutvonen | Interoperability middleware for federated business services in web-Pilarcos[END_REF] [2] [START_REF] Leymann | Web services and business process management[END_REF] are proposed to handle the dynamic nature of collaborations among autonomous enterprises, which different structures are specified for different interactions among business partners.

Today we are facing to support enterprises' agility and resilience in turbulent business environments [START_REF] Camarinha-Matos | Collaborative networks: A mechanism for enterprise agility and resilience[END_REF]. Advances in ICT, Internet, and cloud have led to the explosion of collaborative networks both people and organizational levels. A pervasive interconnection of and collaboration among physical and virtual objects provides opportunities of realization of manufacturing 2.0 (industrial 4.0) and sustainable development. Our previous work [START_REF] De Vrieze | An Analysis of Resilience of a Cloud Based Incident Notification Process[END_REF] provides a method to analyze resilience of a cloud-based collaborative process solution. We thus review federated collaborative process management and analyzing resilience of federated collaborative process management in the new context.

Federated Collaborative Process Systems

Processes that involve multiple parties may be collaborative. While it is possible for this to be limited to two parties, generally one would expect more than two parties. Various degrees of collaborativeness can be distinguished. At the lowest level of collaborativeness, collaborative processes have little differences to distinguish them from simple provision of (web) services. At the highest end there are complex interactions between the involved parties.

In addition to degrees of collaborativeness, there is the dimension of balance of power or control. Collaborations with dominant partners, as for example occurs in supplier networks for large manufacturers of cars or airplanes, are quite different from more peer-to-peer oriented collaborations where no partner is dominant.

Collaborative Processes

In terms of process management, it is convenient to make the distinction between service provision/consumption on the one hand and collaboration on the other hand. Starting from the precept that all processes have a single initiator, a process can be seen as collaborative if, at operational level (not purely on an intellectual basis with human owners) the initiator and executor have some awareness of each other's process and use this in some aspects of operations. The use of process nature can be limited, for example to monitoring, but there should be some use of the process nature.

In real terms we primarily consider automated processes that are managed through some form of workflow or business process management system. In this digital representation a process is represented as control flow as well as activities whose interaction is managed in line with the control flow to provide the process outcomes. Please note, that in this context we look at logical uniqueness and do not consider load balancing or replication of services or process management systems.

Centralised Process Management

Traditionally process choreography is seen as performed by a single process management system (or process engine). This system has a full view of the process and all components. In case that external components are involved, they are treated opaquely as service consumption where the system itself has no further knowledge of the underlying processes or possible interactions.

In this scenario, collaborative process management would imply that the management system requires quite some insight into and control over the implementation of activities within the collaborating organizations. While cloud computing makes this somewhat easier, many collaborators may object to this. In most cases, tight contractual arrangements are needed to allow this to happen [START_REF] Liu | Challenges and opportunities in collaborative business process management: Overview of recent advances and introduction to the special issue[END_REF] [12], and this is mainly seen in a context with dominant players.

Federated Process Management

Federated processes are distinguished from centralized process management in that process-aware collaboration occurs, but is controlled by multiple autonomous management entities. While federated process execution is normal when processes are managed and executed by humans (each person manages his own actions within the agreed boundaries), such coordination is not the norm for automated process management.

Federation as concept implies that there is some degree of meta-level coordination between the management agents that perform the service choreographies. Considering multiple copies of the same process (description) to be the same process (model), multiple instances of a single process model can, from a technical perspective, be instantiated on/coordinated by different management systems. For overall management it is however worthwhile that meta-information is coordinated to allow for overall statistics. Each process instance should have a single, eventually consistent, state.

When parts of a process are coordinated by different process management systems in a federation, there are different ways this can be organized. In this paper we only consider those approaches where at any point of time there is a single "master" or "owner" of the process instance. The coordination of a subset of the activities can be delegated to a different management engine. Ownership may also be transferred (voluntarily or in response to failure). While many real-world process would consist of combinations of these (descriptive) classifications, it is still worthwhile to consider them separately.

Hierarchical federated processes Within federated process management, some processes are purely hierarchical. This means that the process is designed such that process instances are primarily managed by a single management system that delegates parts of the execution to other process management systems under control of a different collaborator. If we define an execution domain as those parts of a process managed and choreographed by a single management system, hierarchical federation is defined through a strict hierarchy of execution domains.

An example of a hierarchical federated process setup could be where a cooperative of specialized manufacturing companies is set up as collaborative network organization to be able to deliver more end-to-end solutions. As part of this collaborative network some centralized coordination is required and can be provided and managed by the cooperative. Individual manufacturers would however retain control over their own processes, but the overall process would be managed by the master process management system. Sequential federated processes A sequential federated process is a process where there is a clear transition from one locus of control to another, after which the original execution domain is no longer involved in the choreography of the process. Effectively this means that responsibility and control can be transferred.

Free-form federated processes In many cases, a strict hierarchy of execution domains is a significant restriction and sequential federation is also not applicable. Free-form federated processes as such are those processes where there are no restrictions are set on the relations between execution domains.

Collaborative Network Resilience

In determining resilience of a process system within a collaborative network it is first of all of import to define what degrees of resilience are considered. In this sense we only consider the resilience of the system, not the resilience of the network as a whole.

Resilience of a process system exists on four levels: the resilience of the system overall, the resilience of individual processes within the system, the resilience of process instances and the resilience of individual constituent services. In achieving resilience one would certainly require that failures at a lower level have minimal impact on the higher layers, but the failure forms do inform the achievement of resilience at a higher layer.

In this paper, resilience of the federated collaborative process systems can be defined as adaptive capacity and its ability to cope with, adapt to and recover after a disruption or failure. Thus we first look at failure model in Section 4.1 as well as service resilience (Section 4.2), process instance resilience (Section 4.3), process resilience (Section 4.4) and overall resilience (Section 4.5) respectively.

Failure Modes

The various process system aspects can fail in various ways, but they share many aspects of the ways in which they can fail. For the purposes of resilience, only the external aspects of failures are of interest. We are also looking at failure from a software perspective, where manufacturing failure modes inform the perspective taken, but are not sufficient to analyze interactions across levels of resilience or the kinds of systems. Overall we distinguish the following orthogonal dimensions (please note that these are not exclusive):

• Temporal failure: Along the time dimension a failure can be temporary (an independent temporary event, for example a network failure due to a power cut); failures can be intermittent based on a systematic issue (related failures for example due to insufficient capacity during nightly batch operations); Failures can also be permanent (the company providing the service has seized operation). • Failure detectability: Some failures are easy to recognize such as those where error messages are provided, signaled failure. Other failures are detectable based on business rules or SLA's such as failure to respond within a certain time period, detectable failure. The final category of failure detection is are silent failures either in silent non-performance (ie. the request is accepted but never actioned), silent partial-performance (ie. some aspects of the request are not performed, but those aspects performed are valid. The final form of silent failure is silent corruption where the system provides incorrect state or results without signaling any error. • Partial failure: Partial failure concerns the degree to which the system is failing.

Full failure is a possibility, but partial failure can occur in various forms such as degraded performance (eg. not meeting time expectations), reduced quality (the results are valid but not of the quality or precision normally provided, the range of the function is reduced) or reduced provision (the domain or image of the functionality is reduced, ie. not all inputs are supported, for example a weather service would have reduced provision for an area if the weather station in that area was unavailable for some reason). • Failure origin: The origin of a failure can either be internal as in it is caused by issues within the logic control of a system, or external where the failure is outside of the control of the system. An internal failure could be a bug in a service implementation or process description. A bug in the process management system would be external from the perspective of a process. A network failure that causes a service to be unavailable would be external to that service. Both examples can, in circumstances, be seen as internal to the overall system. An internal failure can either be a delegate failure (a used component causes the problem) or a direct failure where the problem is not fundamentally in the delegate (although a delegate may return unexpected (but not invalid) results that trigger the issue).

Service Resilience

Services form the building blocks of a SOA based process system. The causes of their failures are therefore out of scope of this discussion, but they may exhibit all forms of these failures. These failures do impact the overarching resilience levels however as for the system to work, the failures need to be able to be handled.

Process Instance resilience

Process instance resilience relates to how process instances can recover from failures. In this aspect, direct failures are normally due to incorrect assumptions or pure logic errors (bugs in the process model), and of less interest within the resilience discussion.

From a temporal dimension perspective, process instances are, due to their inherent nature as long-running, reasonably resilient to non-permanent failures. The lower the pressure on timing, the stronger the resilience.

From a detectability perspective, only signaled failures are normally handled by process instances, and higher resilience generally implies more complete failure management, that includes the availability of sufficient semantic information such as to allow automatic restarts or rerouting for failed paths/components. Silent non-performance can possibly be handled through monitoring and timeouts, but in many cases cannot be distinguished from other forms of silent failure.

In terms of partial failure, degraded performance may lead to timing issues on the process instance, but otherwise should not impact the performance of the process. Reduced quality of performance leads to reduced quality of the instance, and reduced provision would lead to some instances failing (those affected by the reduction) and some succeeding.

In relation to the location of failure, external failure is normally failure of delegates/activities, but can also be a failure in the execution environment (eg. hardware failure). External failure of the execution environment could be compensated by regular replication solutions for the state of the execution environment (eg. database replication / sharding etc.) that is not specific to process management. In terms of direct failure, there are two aspects to the resilience of process models. First is the ability of humans to interject in process instances and possibly modify them or provide "missing" data, this mainly a property of the management system and the used process language. The other aspect is the frequency of instances. In other words, while it may be technically feasible to intervene in a process instance and recover it, it may not be feasible for large amounts of instances that failed due to fundamentally the same cause.

Process Resilience

The resilience of processes is strongly related to the resilience of process instances. There are however ways in which the execution system can make processes be resilient even when individual instances fail. Conversely, timing and speed issues that are not problematic at instance level, may become so at process level.

Process resilience at a temporal level requires monitoring and (pre-emptive) intervention and/or rerouting. Processes are resilient when it is easy to (automatically) replace the providers of services for the process (activity execution or process management), but it requires a resilient system to actually make use of those possibilities. Obviously if these measures can be performed on already started process instances, this would even be better.

At process level, the detectability of failures is limited to the ability to express overall expectations, possibly at aggregate level. These process level specifications could then allow for pre-emptive intervention in the instantiation of new processes. Note that at process or system level it may also be feasible to determine some degree of likelihood of the various forms of silent failure by aggregating monitoring data and linking it to the expectations.

At process level partial failure of some instances would constitute partial failure of the process. A resilient process would allow the instance failures to be minimized and possibly corrected through re-execution along an alternative path. To do the latter, does require sufficient information to be available for the process components to be able to determine the semantic validity of doing so.

Locus of failure at process level implies some degree of process quality requirements as well as designs that minimize the impact of external failures. Again, monitoring of individual service and instance performance can help in detecting, mitigating and avoiding these failures or transitioning them from non-performance to degraded performance by for example choosing a lower quality service that does not have availability issues.

Overall Resilience

Overall the entire systems resilience is a combination of the resilience of the constituting processes. Many measures at overall level can however help to achieve this resilience. In particular the provision of fallback execution environments or services will improve the overall resilience of the system. Resilience in terms of fault tolerance mainly depends on the resilience of the components (services, processes) and sufficient provision of execution environments without single point of failure.

Resilience for Federated Process Management

Where the previous section discussed the resilience of the components that make up a federated process management system that is on a technical level rather than a utility level. The possibilities of federated process management can, on a theoretical level be seen as a subset of what single entity-controlled process management provides. on a practical level, there are resilience benefits to federated process execution (there are also disadvantages in complexity and management). In addition, in real-world business scenarios it is often not desirable to have centralized process control.

In terms of resilience, federated process management means that by implication, processes are managed by multiple independent execution environments. While these environments may have access to different components (such as company internal services) they would have similar orchestration capabilities. As federated processes allow parts of execution to be delegated to other execution environments this means that an overall master coordinator does not require direct access to all required components for process execution.

At system and process level, through a lack of single point of failure and lack of global coordination requirement, federation provides a strong level of resilience against total failure. Performance degradation, especially non-functional degradation, can be compensated for by additional provisioning elsewhere within the collaboration. Even the absence of certain unique resources, would only result in those processes being unavailable.

The services used by a system are independent of the form of process management, and their resilience is mainly a property that influences higher levels. Federation however brings some interesting perspectives to process instance resilience. In the case of sequential federation, given a well-defined ownership transition model, the failure of preceding execution environments would not lead to instance failure.

Within hierarchical federation it is possible that, beside the master execution environment multiple delegate environments are active concurrently. Fallback, if semantically valid within the process, would however still be possible as long as a strict order of fallbacks is known by all candidates. These candidates would also be required to have some degree of overall knowledge of the process, possibly under some sort of escrow approach.

Conclusion

From the discussion above, it is clear that beyond meeting business needs in providing the benefits of collaboration while safeguarding independence of control, federated process environments also bring interesting resilience properties. In particular, the independence of execution environments prevents the full failure at system level in the case of failure of individual execution environments. At process level, full failure is limited to those cases where no fallback to a component is available (a unique, mandatory, service only provided by a single partner). Instance resilience is no longer restricted to an ability to work around failure of single components, but also handle failure of execution environments.

Process resilience, in federated and other forms, does however require processes to be designed for resilience, to have additional information that specifies the semantic validity of cancellation and retries, and for there to be good, shared, monitoring of component performance and reliability.


Ana Inês Oliveira

Mohammad Shafahi
email: m.shafahi@uva.nl

Hamideh Afsarmanesh
email: h.afsarmanesh@uva.nl

Filipa Ferrada

Luis M Camarinha-Matos

Competence Matching in Collaborative Consortia for Service-Enhanced Products

Keywords: Service-Enhanced Product, Collaborative Networks, Specification, Virtual Organization

To exploit new market challenges in manufacturing industries, collaborative environments permit that different stakeholders achieve value creation and differentiated products when addressing the design and development of products that include associated business services (service-enhanced products). In order to facilitate a suitable context for networks of SMEs in the domain of highly customized and service-enhanced products, the GloNet project addressed collaborative networks with different configurations and purposes. In this context, this paper is focused on how a collaborative consortia for serviceenhanced products can be created having into account the requirements for a new product and the necessary normalization of organization's competences.

Introduction

In manufacturing, to meet customers' demands, the current tendency is to achieve highly customized products. Therefore, the idea of service-enhanced products represents a growing trend due to the fact that consumers more and more demand not only the manufactured products, but also services associated to the physical products. Examples of such services associated to products can be: insurance to protect it, expertise to install it, support to maintain its operation during its life cycle, etc. [START_REF] Shen | Research on organization mode selection of service-enhanced manufacturing enterprise[END_REF][START_REF] Bitner | The evolution and discovery of services science in business schools[END_REF]. Examples of service-enhanced products are: power plants, intelligent buildings, or complex technical infrastructures. As a consequence, if business services are associated to products in order to create and add value, then certainly that new business or collaboration opportunities can emerge. Hence, to achieve such services it is necessary to consider the involvement and collaboration of several stakeholders organized in collaborative enterprise networks [START_REF] Camarinha-Matos | Cloud-Based Collaborative Business Services Provision[END_REF]. Nevertheless, one obstacle that organizations typically face when creating a consortium to respond to a new business or collaboration opportunity is how to identify the needed competences to respond to the requirements. To achieve some solutions in this field, the GloNet project [START_REF] Glonet | Glocal Enterprise Network Focusing on Customer-Centric Collaboration[END_REF] (collaborative project funded under the Factories of the Future program of the European Commission) aimed "at designing, developing, and deploying an agile virtual enterprise environment for networks of SMEs involved in highly customized and service-enhanced products through end-to-end collaboration with customers and local suppliers".

Prior researches addressed the product specification and design such as collaborative CAD systems [START_REF] Li | An Internet-enabled integrated system for co-design and concurrent engineering[END_REF][START_REF] Li | Collaborative computer-aided designresearch and development status[END_REF]. In our previous work the requirements for a product specification system within a Coopetition environment like VBEs and goal oriented VOs [START_REF] Shafahi | A Coopetition Space for Complex Product Specification[END_REF] and how users can be guided through the specification process [START_REF] Afsarmanesh | On service-enhanced product recommendation guiding users through complex product specification[END_REF] were investigated.

In this line, the main challenge that is presented in this paper is twofold: (i) the description of the service-enhanced product specification that considers the customers' requirements and a mapping with existing standards of products classification; and (ii) considering the previous requirements and specification (product goals) with the corresponding mapping of product classification, match it with VBE members' competences to create a consortium. Section 2 briefly summarizes the main outcome of the GloNet project, section 3 responds to the main challenges here presented and, section 3 concludes.

GloNet Approach

In GloNet, depending on the type of required support and objectives, collaborative networks with different configurations and purposes were addressed. Those networks are summarized in Table 1.

Table 1. GloNet networks

Long Term-Strategic Network

Manufacturers Network

Similar to a virtual organizations breeding environment (VBE), based on long-term alliances involving: manufacturers, project/product designers, service providers, and other relevant supporting stakeholders and entities.

Customer Network

Or "customer related community" -a part form the customer, it also includes, service providers, and a variety of local support entities. Although this network might not be fully structured, some principles are shared, such as geographical context, business domain, legal restrictions, culture, etc.

Goal-Oriented Network

Product Development Network

Short-term VO related to the design and development of the physical product and its associated business services. This VO usually ends once the product is delivered.

Product Servicing Network

Long-term VO with the aim to support the involved stakeholders in the required business services during the product life-cycle.

Service Cocreation Network

Temporary VO with the aim of co-design and co-create innovative products and/or associated business services.

For the above networks definitions, the adopted definitions for VBE and VO were:

-"Virtual Organization Breeding Environment (VBE) is an association of organizations and related supporting institutions, adhering to a base long term cooperation agreement, and adopting common operating principles and infrastructures, with the main goal of increasing both their chances and preparedness towards collaboration in potential Virtual Organizations" [START_REF] Afsarmanesh | Methods and tools for collaborative networked organizations[END_REF][START_REF] Msanjila | A multi-model approach to analyze interorganizational trust in VBEs[END_REF].

-"Virtual Organization (VO) is a temporary alliance of organizations that come together to share skills or core competences and resources in order to better respond to collaboration opportunities and produce value-added services and products, and whose cooperation is supported by computer networks." [START_REF] Camarinha-Matos | ECOLEAD: A Holistic Approach to Creation and Management of Dynamic Virtual Organizations[END_REF].

The creation of a new service-enhanced product is therefore performed by a temporary goal-oriented network, in this case a product development network, whose formation is triggered by a new business opportunity brought in by the customer, and eventually found by a broker member of the VBE. The partners of the product development network (VO) are primarily selected from the manufacturers network (VBE) and if needed, additional partners, from the customer related "community" and other stakeholders from the geographical region of the customer, can be added.

The creation of the product development network is prepared inside the manufacturers network. After receiving the product order from the customer the member in charge of all the necessary arrangements for the creation of the VO (i.e. the VO Planner) begins the formation procedure, that: starts with the detailed specification of the product order; continues with the selection of the partners according to their competences against the skills and capacities that are necessary; and ends with the establishment of the necessary agreements and contracts to regulate the VO during its operation phase [START_REF] Oliveira | Negotiation and Contracting in Collaborative Networks[END_REF][START_REF] Oliveira | Electronic Negotiation Support Environment in Collaborative Networks[END_REF]. Therefore, the product starts being developed under the supervision of the product development network and this network lasts the necessary time to have the product created. Meanwhile, new ideas for new business services might appear. These ideas need to be discussed and brainstormed with some of the product development network partners. Thus, after choosing the most appropriate partners to the mission, a service co-creation network is created. This network (also a VO) has as its main purpose the co-design and co-innovation of novel value-added services to enhance the product being developed by the product development network. Considering that numerous new business concepts may occur, also numerous service co-creation networks might be formed. Once the product and its services are created, the product development network dissolves. Fig. 1 illustrates the interplay among manufacturers' network, customer networks, and product development network.

The GloNet project developed an ICT support environment system comprising a cloud-based platform supporting various collaboration spaces and a collaborative networking framework that enabling the specifications of service-enhanced products and management of collaborative networks, which gives support to the networks presented before (Fig. 2). The work presented in this paper relies on two core components: the Service-Enhanced Product Support and the Goal-Oriented Networks Management.

Matching Competences for Consortia Creation

One major challenge after the specification and design of a product development network, was how to map the specification of the service-enhanced product order with the corresponding required competences of the partners to be part of the VO. As a response to such challenge, the European standard NACE [START_REF] Eurlex | European Parliament and of the Council of 20 December 2006 establishing the statistical classification of economic activities NACE Revision 2 and amending Council Regulation (EEC)[END_REF] was adopted as a match with organizations' competences. In this line, three main systems were designed and developed to provide an integrated solution: the VBE Member Management, of the VBE Management system; the Products and Services Specification System; and the VO Formation System. Fig. 3 , exemplifies the flow of the creation and operation phases of a serviceenhanced product. The creation phase corresponds to a product development network, and the operation and maintenance/monitoring (O&M) phase corresponds to a product servicing network. The dashed rectangle identifies the interactions of the mentioned three systems, and their description follows.

VBE Member Management System

A VBE's main aim is to provide commonality and support for interactions among its members [START_REF] Afsarmanesh | Methods and tools for collaborative networked organizations[END_REF]. Moreover, a VBE facilitates the collection and maintenance of members profile data, enabling refined selection criteria usage, comprising levels of trustworthiness, value system, and historical collaboration performance. As such, the establishment of a VBE requires a proper management system that should provide functionalities to manage the members' profiles and VBE's competences, to enable performance management, and to facilitate trust building amongst VBE members. A strategic objective of a VBE is to increase preparedness of each member of the alliance concerning fast configuration of VOs in response to market opportunities.

The VBE members management system is intended to facilitate the VBE administrator with the management of the VBE members. It provides functionalities for VBE member admission and registration in addition to withdrawal. Furthermore, it contains functionalities that VBE members can use to list all other VBE members, and to permit searching for any VBE member and its profile. In both cases, the usage of these functionalities is conditioned by the permissions that the VBE members have. It is considered that the VBE administrator has fully access to all information of VBE members. The VBE members profile management permits the management of the VBE members' profiles. The profile contains a number of defining elements for each individual VBE member (e.g. business domain, name, address, capabilities, skills, etc.) about each VBE member. Moreover, the VBE member competences consists on the main part of the VBE member profile including the latest information related to each VBE member capabilities and capacities, and conspicuous information of their validity, making the VBE members involvement in actions and activities in the VBE eligible, and prepared to VO creation.

In order to have a common understanding within the VBE, a taxonomy of competences is included, consisting of a hierarchical classification of the competences foreseen for the VBE (i.e. the competences that the VBE would like to fulfill in order to be as competitive as possible in its domain of operation). Each taxonomy class includes a related informal description. To make this taxonomy as broad as possible, the representation of competences is based on the European standard NACE [START_REF] Eurlex | European Parliament and of the Council of 20 December 2006 establishing the statistical classification of economic activities NACE Revision 2 and amending Council Regulation (EEC)[END_REF][START_REF]NACE Rev. 2 -Statistical classification of economic activities[END_REF].

Service-Enhanced Product Specification Tool

The service-enhanced product specification system supports two main functionalities of product/service specification and product/service registration. This tool is designed and implemented to primarily assist the design & engineering phase of the serviceenhanced product lifecycle (PLC). Nevertheless, it may also be needed from time to time to specify new sub-products within the operation and maintenance phase of the PLC.

The system facilitates specification of new customer-oriented service-enhanced products, and enables involvement of different stakeholders, e.g. equipment providers as well as the EPC designers. The service-enhanced product specification system primarily captures, handles, and manages the detailed meta-data about the product and all its sub-products/services, and assists users with their specification. The aims of the functionality provided in the product specification system are three-fold. The first goal is to support gradual specification of the products. This is needed to reflect the reality of products that are neither defined in one session and nor by one stakeholder. Therefore, detailed specifications that capture and transform customer requirements for a product into discrete sub-product specifications, can be gradually defined by the involved multi-stakeholders, using the developed service-enhanced product specification system. The second goal is to properly capture the classification of all relevant sub-products and enhancing services in a granular and modular manner in the product environment, e.g. distinguishing and capturing both the electrical and mechanical aspects of a sub-product. This will in turn support effective multiperspective retrieval/discovery of information related to sub-products, as well as creating their concise presentation, needed for common understanding among different related stakeholders. The third goal is to capture all the details related to sub-products in a reusable from. As such, the existing specifications of already introduced subproducts can be either fully or partially (e.g. at the level of certain detailed feature-kind) be reused for the specification of other sub-products. Fig. 4 demonstrates the overall flow for the specification process for complex products. Other than the above mentioned functionalities sub-products specified using the product specification system are semi-automatically classified using the PRODCOM [START_REF]Your key to European statistics[END_REF] convention for classifications, that are pre-defined in the system. The choice of PRODCOM suits this case because it is an extension of the CPA and as such compatible with NACE [START_REF] Eurlex | European Parliament and of the Council of 20 December 2006 establishing the statistical classification of economic activities NACE Revision 2 and amending Council Regulation (EEC)[END_REF]. Furthermore, PRODCOM itself is accepted within the EU as a standard extendable coding system. The NACE Rev. 2 coding system, as suggested by its description of "Statistical Classification of Economic Activities in the European Community", classifies the economical activities preformed to realize a product or service. This provides valuable input when a specification is being realized by the VO formation sub-system and organizations need to be selected for the VO. A PRODCOM code is constructed by further extending the NACE activity code, and therefore embeds in itself the activity that is preformed to realize the product. If a product class is associated with at least one PRODCOM code, we can then use this coding in order to find suitable organizations that can realize this product class by focusing on the NACE part of the PRODCOM code and looking for organizations that have announced this NACE code as one competence.

Mapping of Service-Enhanced Product's Specification and Organizations Competences

As suggested before, the recommendation of a set of organizations that can produce or support a certain class of products can be achieved by looking at the NACE code of their competences, when related to the PRODCOM code of the product. If the class of some product is not directly associated with a PRODCOM code, then sub-products of the product can be used, were their classes are coded with PRODCOM, so that the competence of organizations standardized through the NACE [START_REF] Eurlex | European Parliament and of the Council of 20 December 2006 establishing the statistical classification of economic activities NACE Revision 2 and amending Council Regulation (EEC)[END_REF][START_REF]NACE Rev. 2 -Statistical classification of economic activities[END_REF] coding convention can be used to build the link to that product. As such interlinking the subproducts of the product with the competences required from organizations to realize the sub-product, are established. As an example, the PRODCOM code "C27.11.43.80" refers to "Transformers, n.e.c., having a power handling capacity > 500 kVA" and its respective NACE code of "C27.11" refers to: "Manufacturing of electric motors, generators, transformers and electricity distribution and control apparatus". Now if a sub-product for instance is associated with this PRODCOM code "C27.11.43.80", then the suitable organizations that can realize and/or support this product can be identified by taking the NACE part of this PRODCOM coding which is "C27.11", and then looking for those organizations who have defined the NACE code "C27.11" as one of their competences. The above mechanism enables our system to recommend a set of organizations capable of realizing and supporting a complex product. The approach suggested by Resnik [START_REF] Resnik | Semantic similarity in a taxonomy: An information-based measure and its application to problems of ambiguity in natural language[END_REF] was used in order to further rank the suitability of a NACE code used as organization competency for realizing a product associated with a PRODCOM code. Clearly in the case when a product is associated with more than one PRODCOM code, and the organizations are associated with more than one competence (i.e. NACE codes), which is rather a typical case, then the most overlap between the interlinked NACE and PRODCOM codes are desired, in other words the more matches between an organizations set of competencies and the PRODCOM codes defined for a product, the more that organization is suited for realizing and support that product. Such a large number of matches in fact indicate that the sub-product and the organization belong to the same sector.

Consortia Creation

The formation of the VO for service-enhanced product development mostly involves the plan and scheduling of the work order consistent with the service-enhanced product specification, and selecting the appropriated partners considering the existent VBE competences. Nevertheless, to finish the VO formation, and assist the VO partners in attaining agreements, negotiation functionalities are also essential [START_REF] Oliveira | Electronic Negotiation Support Environment in Collaborative Networks[END_REF]. The VO agreements will serve as foundations for the VO governing principles through its operation phase [START_REF] Oliveira | Negotiation and Contracting in Collaborative Networks[END_REF]. Fig. 5 exemplifies the main flow of the VO formation process. Nevertheless, as the focus of this work is on competences for consortia creation, this section highlights the three first services: New order characterization, VBE members competences analysis, and Potential VOs assemblage.

As such, important services in the VO formation are: New Order Characterization: to assist the VO planner in the characterization of the new order for products or/and services. Considering the identified requirements of the new order, the characterization relies on the decomposition of the new order into goals considering the outcome of the product specification tool and the VBE competences taxonomy.

VBE Members Competences Analysis: to support the VO planner in searching for the suitable partners for the VO. It allows checking how the New Order Characterization goals can be fulfilled considering the existing competences of the VBE members. Thus, the VO planner can properly detect the appropriated partners for the VO being created. The members are therefore searched within the VBE, the customer network, and also other relevant local entities or suppliers related with the VBE.

Potential VOs Assemblage: to assist the VO planner in making the conceivable consortia compositions considering the information already provided by the New Order Characterization and the VBE Members Competences Analysis. In this step, the VO planner already has a list containing the potential partners that can deliver, or are able to complete, the defined goals. Moreover, the VO planner can make a VO risk assessment [START_REF] Oliveira | Negotiation support and risk reduction in collaborative networks[END_REF] using other VBE functionalities (such as evaluate the trustworthiness levels of partners [START_REF] Msanjila | Trust analysis and assessment in virtual organization breeding environments[END_REF], and their value systems alignment [START_REF] Macedo | A qualitative approach to assess the alignment of Value Systems in collaborative enterprises networks[END_REF]). As mentioned, to finalize the VO formation, the VO planner starts the negotiation process [START_REF] Oliveira | Electronic Negotiation Support Environment in Collaborative Networks[END_REF] to achieve agreements among VO partners, and launch the VO.

Conclusions

One of the aims of the GloNet project was the design, development, and deploy of an agile enterprise environment for networks of SMEs involved in highly customized and service-enhanced products through with customers and local suppliers. One of the achievements was the specification of configurations and purposes of collaborative networks: product development network, service co-creation network, product servicing network, manufacturers' network, and customer network. This paper addresses the creation of a product development network focusing on three systems that were developed to permit its support, namely: the VBE Member Management, of the VBE Management system; the Products and Services Specification System; and the VO Formation System. The interaction of these three systems considered the normalization of the requirements of a new product and the necessary competences of organizations. Therefore, the challenges of addressing: (i) the service-enhanced product specification, mapping it with existing standards; and (ii) the consortium creation focusing on the VBE members matching, were achieved.

The approach was validated in the scope of the GloNet project, in a solar industry and intelligent buildings networks. As a general result, the solution was positively validated in terms of developed models and prototypes. Nevertheless, when evolving to commercial products, some improvements shall be considered, namely in terms of user interfaces.

Fig. 1 .

 1 Fig. 1. Interplay of some GloNet networks

Fig. 3 .Fig. 2 .

 32 Fig. 3. Flow of the creation and operation & monitoring phases of a product

Fig. 4 .

 4 Fig. 4. Flow of the complex product specification

Fig. 5 .

 5 Fig. 5. Main flow of the VO formation process

Acknowledgments. This work was funded in part by the European Commission through the GloNet project (FP7 programme). The authors also thank the contributions from their partners in this project. Partial support also comes from Fundação para a Ciência e Tecnologia through the PEST program UID/EEA/00066/2013.


Sónia A C Teixeira
email: sonia.c.teixeira@inesctec.pt

Pedro Campos
email: pcampos@fep.up.pt

Catarina Roseira
email: croseira@fep.up.pt

Renato Fernandes
email: renato.s.fernandes@inesctec.pt

Collective Intelligence and Collaboration: A Case Study in Airline Industry

Keywords: Collective Intelligence, Airline Industry, Flocking Behavior

In order to improve their competitive performance, airline companies often adopt as a strategy to establish arrangement between two or more organizations agreeing to cooperate on a substantial level. This strategy is often known as airline alliances. A paradigm to analyze the collective intelligence behavior which emerges from a group, as a strategic alliance, is the flocking behavior. Inspired by the Cucker and Smale algorithm (C-S) we propose a new version of the flocking behavior algorithm applied to airline alliances. Our goal is to understand the link between strategic alliances and flocks. For this new approach, metrics were obtained for the parameters of C-S algorithm, namely position, velocity and influence, where the latter uses cooperative games. Besides, reinforcement learning mechanisms have been explored. Some relevant outputs for airline alliances as the permanence rate and the growth rate were computed for each of the five configurations in analysis.

Introduction

The evolution of markets induces a change in the way organizations act. Collaboration between organizations, as an alternative or in parallel to competition, allows them to get the edge over other competitors or potential new organizations of the same market [START_REF] Johnson | Exploring Strategy[END_REF]. In this work, we focus on airline industry and explore the emerging collective intelligence and collaboration in the perspective of flocking behavior. The nature of airline industry is different from other industries because it requires public reassurances and operating procedures that include a governmental involvement, which implicitly encourages collaborative working practices [START_REF] Evans | Collaborative strategy: an analysis of the changing world of international airline alliances[END_REF]. Collaboration in airline industry allows organizations to reduce costs from sharing operational staff, making investments or negotiating extra volume discounts, what can represent lower prices due to lowered operational costs for a given route. In that way, organizations increase revenue and generate opportunities. What derives from the shared belief that together the network members can achieve goals that would not be possible or would have a higher cost if they try to achieve individually [START_REF] Camarinha-Matos | Collaborative networks: A new scientific discipline[END_REF]. Social dynamics factors are important to understand fundamental economic questions, which can be compromised when social preferences are not taken into account, because it is not possible to understand adequately the laws that govern cooperation and collective action, or the effects and the determinants of material incentives or even the important forces which shaping social norms and market failures [START_REF] Fehr | Why social preferences matter: the impact of nonselfish motives on competition, cooperation, and incentives[END_REF]. The algorithms of flocking behavior [START_REF] Cucker | Emergent behavior in flocks[END_REF], [START_REF] Cucker | On the mathematics of emergence[END_REF], [START_REF] Olfati-Saber | Flocking for multi-agent dynamic systems: Algorithms and theory[END_REF], [START_REF] Reynolds | Flocks, herds and schools: A distributed behavioral model[END_REF], [START_REF] Vicsek | Novel type of phase transition in a system of self-driven particles[END_REF], are methods that use simple rules to describe the evolution of a flock and are appropriate to simulate the behavior of a group of organizations, such as airline alliances, that move in accordance to a common goal. We propose a new version of the flocking behavior of Cucker and Smale (C-S) algorithm [START_REF] Cucker | On the mathematics of emergence[END_REF] applied to airline alliances, taking into account a learning mechanism. The model is named AllFlock and the goal is to understand the link between strategic alliances and flocking behavior. The permanence rate of the alliances (computed for simulated and real data) and the growth rate of the alliances were computed for each of the five configurations in analysis, which can be important to evaluate the fitness and the structure of the alliance. The paper is organized as follows: In Section 2 we introduce collective intelligence, swarm intelligence and flocking behavior algorithms. Our case study in airline industry is described in Section 3. In Section 4 results are presented and finally Section 5 presents the conclusion.

Collective Intelligence, Swarm Intelligence and Flocking Behavior Algorithms

The terminology used by Saminen in [START_REF] Salminen | Collective Intelligence in Humans : a Literature Review[END_REF] mentions swarm intelligence to refer to emergent collective behavior in simple agents. On another hand, collective intelligence in humans is a relatively new and multidisciplinary subject. Since the appearance of the name of collective intelligence many other approaches arose, as purely theoretical, conceptual, for simulations, case studies, experiences and systems architecture [START_REF] Salminen | Collective Intelligence in Humans : a Literature Review[END_REF]. Areas such as psychology, complexity, cognitive studies, biology, computer science and the media also gave their contribution to this multidisciplinary theme [START_REF] Salminen | Collective Intelligence in Humans : a Literature Review[END_REF]. Swarms algorithms [START_REF] Beni | Swarm Intelligence in Cellular Robotic Systems, Proceed[END_REF] are based on social and collective behavior that is observed in ants, birds, insects, etc. Ant colony optimization (ACO), particle swarm optimization (PSO), as well as self-propelled particles algorithms (SPP) [START_REF] Vicsek | Novel type of phase transition in a system of self-driven particles[END_REF], are part of the class of swarm intelligence algorithms. The term self-propelled particles arises when flocking algorithm proposed by Vicsek et al. in [START_REF] Vicsek | Novel type of phase transition in a system of self-driven particles[END_REF], which describe a group of particles, each them which acts as an autonomous agent and each follows same simple rules as a way to regulate their behavior. The intelligence of these same systems are triggered by the collective behavior of individuals, that is, interactions between individuals lead to the emergence of a global intelligent behavior, named collective intelligence [START_REF] Lévy | Collective Intelligence: Mankind's Emerging World in Cyberspace. Challenges. Perseus Books[END_REF]. The flocking has been seen to Olfati-Saber [START_REF] Olfati-Saber | Flocking for multi-agent dynamic systems: Algorithms and theory[END_REF], as "a form of collective behavior of a large number of agents that interact with a common group goal". This complex movement caught the attention of Reynolds, also, who in 1987 proposed a simulation-based approach to the flock movement [START_REF] Reynolds | Flocks, herds and schools: A distributed behavioral model[END_REF]. This movement, very similar to a natural flock, is created by a distributed behavioral model in which each bird acts as an independent agent and chooses its course. The flocking behavior is the result of the interaction of simple behaviors of agents, represented by rules. The starting point for the Cucker and Smale (C-S) model [START_REF] Cucker | On the mathematics of emergence[END_REF], one of the most important algorithms of flocking, arises from an extension of a work by the same authors [START_REF] Cucker | Emergent behavior in flocks[END_REF], in which an analysis is made to the flocking model from Vicsek et al. [START_REF] Vicsek | Novel type of phase transition in a system of self-driven particles[END_REF]. Motivation for such extension was the observation that under certain initial conditions of the state the flock converge, ie all birds fly at the same velocity. The proposed development model [START_REF] Cucker | On the mathematics of emergence[END_REF], uses three important parameters namely: position, velocity and influence and aims at searching for the conditions for the state under which the convergence is established. We propose an innovative extension of the flocking algorithm of [START_REF] Cucker | On the mathematics of emergence[END_REF] where position is viewed as the choice of potential partner organization, velocity is the performance of the organization when compared to the alliance (measured as the growth of the net income between two time steps) and influence is measured through the Shapley Value [START_REF] Papapetrou | A Shapley value approach for influence attribution[END_REF], [START_REF] Shapley | A Value for n-person Games[END_REF], with the aim of dividing goods gained by the cooperation among many organizations. We also consider that organizations learn through interactions within the alliances where they belong. Reinforcement learning [START_REF] Sutton | Reinforcement Learning: An Introduction[END_REF] is the method we use to implement the learning mechanism in the flocking behavior. The permanence rate and the growth rate of the alliances were computed by each of the five configurations in analysis. The permanence rate was also computed for simulated and real data, by each alliance.

3

Case Study: AllFlock Applied to Airline Industry Airline industry growing business, in terms of market prospects, once the traffic has been duplicating every 15 years. The AllFlock model (Flocking in Strategic Alliances) proposed in this paper intends to recreate the way as organizations act in order to analyze it in terms of flocking behavior. AllFlock models the intragroup behavior where each agent knows the decisions of the other agents (companies) belonging to the same alliance. There are two important decisions: 1) What company to follow (based on a combination of the utility function -Choice -and the Growth; 2) The decision of remaining in the alliance (based on Shapley value and the Growth). The pseudocode of ALLFlock is presented in the following lines. The velocity in C-S is represented by the performance of an organization relative to the performance of alliance. Influence is measured by how much the organization considers to win with a specific alliance, which is the impact of a coalition could have on the organization. This is considered regardless of their physical location, unlike C-S. Simply put, each organization has to choose another organization to follow in each instant t, and this choice is dependent of growth, choice and influence (impact) of the alliance in previous moments. Regarding the position, we assume implicitly that organizations choose to collaborate with other organizations in order to maximize the gains. Following that idea, we compute choice value the result of tendencies by particular organizations. The AllFlock model considers that depending on their aspirations, at every time t, organizations give different importance to these three aspects. For that reason we included , e , as the weights with which organization i attaches choice, influence and growth, respectively. Choice considers which organization j the organization i wants to follow as a potential partner. When organization i is looking for the best direction to go, which means the organization that maximizes the choice expression, it collects information throughout their interactions in respect of previous choices. In our view, organization i is learning by trial and error, which is common in reinforcement learning situations. Collaboration is also taken into account in the reinforcement learning, where each company gives rewards or punishments to other companies for their attunement with choices. Let us denote the velocity at which the agent assimilates information by , the reward and the amorti-zation rate by (the latter being defined by the user. Therefore, denoting by , the choice, at time t; the influence of the alliance is , and the growth of the organization i at time t is , we have:

+ = 1 - * * + * + * + * + * * + * + * ] (1)
The Shapley Value is used to measure the expectation of how much an organization can gain if it belongs to that alliance. Let a set of n companies ={ , … , }, the function gain . , and the subset ⊆ [START_REF] Papapetrou | A Shapley value approach for influence attribution[END_REF]. The Shapley value is computed taking into account the value each company gains for being in the cooperation:

= ∑ |"|! |$|%|"|% ! |$|! ∪ ' ( - "⊆$ (2)
The impact of the alliance on the organization is given by the influence that affects the agent in its decision making. Organizations decide to remain (or not) in the alliance based on growth and on the impact of the alliance. If the organization is growing and has the expectation to improve its results for belonging to the alliance, then the organization will remain. When the organization is not growing and does not expect to have better results, then, it will go out of the alliance. If the organization has different indicators from the growth and the impact of the alliance, then the organization will evaluate what to do in the next period. In the case when a positive change happens then the organization stay, otherwise it exits. We assume that there is convergence in the flocking, when the organizations give the same reward in 80% of time, in two different iterations of the algorithm. Exits and the permanence rate of the alliance are given by equations 2 and 3, respectively.

)* = + ,-./012 34 325, 6,+ 3 7%4 ,-./012 34 325, 6,+ 3 7 + ,-./012 32 325, 6,+ 3 7

(3)

Results

The AllFlock model that was created to simulate the flocking behavior has been developed in Netlogo [START_REF] Vicsek | Novel type of phase transition in a system of self-driven particles[END_REF]. The final results are the average of the 100 simulations for different number of iterations. In the analysis of the five configurations, the evidence of convergence has the highest value at configuration 2, with the average of 106 iterations. The configuration that presents, on average, a fewer iterations occurs in the configuration 4. A Kruskal Wallis test was applied to verify if the distribution of iterations is the same between the configuration categories, as the permanence rate and the growth rate. The null hypothesis was rejected for a significance level of 0.05 in all three situations. Four different instants of simulation are possible to observe at Fig. 1. As we can observe at Fig. 2 the highest average permanence rate by alliance occurs at Configuration 2 with 78.81%, with 81.72% at Configuration 3 and at Configuration 5 with 80.92% and 79.73%. The lowest average permanence rate by alliance occurs at Configuration 1 with 54.95% and at Configuration 4 with 53.42%. Average permanence rate between alliances in same configuration is not much different, in some cases is very close as in the alliances at Configuration 1 (54.95%, 57.62% and 56.08%) and between the Alliance0 and Alliance1 at Configuration 4 (59.27%, 59.37% and 53.42%). In Best result for average permanence rate by alliance with simulated data, using expression ( 4), occurs at Alliance0 with a rate of 69.69%. The highest value in the air transport alliances, with real data, for the average permanence rate by alliance can be observed at SkyTeam alliance which has a rate of 79.17%. Oneworld has the lowest value with an average permanence rate of 75% and StarAlliance has an average permanence rate of 75.68%. In the results for simulated data, (for which there is no correspondence with real data), the maximum number or organizations is in the initial instant.

Conclusions

Inspired on three C-S algorithm concepts: the position, velocity and influence, we used the same ideas concepts not always nearby, as in the case of the position and influence to construct the AllFlock model. The AllFlock model (Flocking in Strategic Alliances) proposed in this paper intends to recreate the way as organizations act in order to analyze it in terms of flocking behavior. We observed the evidence of convergence (existence of flock behavior).

In some configurations, such as, configuration 1 and configuration 4 companies remain in average less time in alliances, which can be explained by their need for good results ("time").Was also observed that the average of permanence rate is closer between alliances than the average growth rate, which may be an indication of heterogeneous growth between companies. The AllFlock model does not allow for an organization to leave from an alliance and change to another. In addition, it does not consider other possibilities of sub-collaborations inside the companies of the alliance.

These are limitations of the AllFlock which are being considered for future work. With this evidence of flock behavior in strategic alliances, an analysis of typologies can be improved in future work (since there is some evidence that some typologies can be related with some parameters of simulation, like "time").

The proposed model can be seen as a first step to understanding the collective intelligence in organizations, namely in airline industries, by using flocking behavior.

Fig. 1 .

 1 Fig. 1. Organizations behavior at four different instants of simulation (instants 0, 7, e 76) for configuration 5 (Netlogo screenshots).

Fig. 2 .

 2 Fig. 2. Average permanence rate and average growth rate by alliance, for each configuration.Average growth rate between alliances for Configuration 3 (55.26%, 57.78% and 51.11%) and Configuration 4 (40.77%, 33.34% and 31.10%) are very close, as is possible to observe at Fig.2. The same does not happen in Configurations 1, 2 and 5.

Table 1 .

 1 Results from StarAlliance, SkyTeam, Oneworld (adapted from Oneworld site, SkyTeam and StarAlliance annual report 2015)

		StarAlliance	SkyTeam	Oneworld
	Passengers (million)	641.10	612	512.6
	Countries	192	177	154
	Employees	432603	481691	389788
	Total Revenue (US millions)	179.05	186.331	141.404
	Daily departures	18500	16323	14313

Until September 2015, there were mainly three alliances in airline industry: SkyTeam (founded in 2000, with 20 members), Oneworld (founded in 1999, containing 15 members) and StarAlliance (1997, with 27 members). A new alliance, Vanilla Alliance started in September 2015, and U-FLY Alliance in January 2016, with 5 and 4 members respectively. Some annual results from three biggest airlines alliances are presented at Table

1

.

Table 2 .

 2 Configurartions and Combination of parameters

			Parameters (given by the user)
		Initial number	Exploration rate	Delta	Discount	Evaluation
		of organiza-	vs. knowledge			time
		tions	(Sigma)			(time)
	Configuration 1	Low	Low	High	High	Low
	Configuration 2	Low	Low	High	High	High
	Configuration 3	Low	Low	High	Moderate	High
	Configuration 4	Low	Moderate	High	High	Low
	Configuration 5	Low	Moderate	High	High	High

  Configuration 1 the average growth rate by alliance is 38.83%, 59.17% and 41.65%, the average growth rate by alliance is 54.11%, 43.26% and 54.53% at Configuration 2, and for Configuration 5 with 45.11%, 6.37% and 48.14%. Average growth rate by alliance has the lowest value, 6.37%, at alliance 1 in Configuration 5 and the highest value for the same alliance at Configuration 1.