Mahdieh Shadi
email: m.shadi@uva.nl

Hamideh Afsarmanesh
email: h.afsarmanesh@uva.nl

Behavioral Norms in Virtual Organizations

Keywords: Virtual Organizations, Behavioral Norms, Promise Formalization, Trust modeling, Behavior Monitoring

Virtual Organizations (VOs) consist of groups of agents that collaborate towards achieving their specified goals. VO Partners are independent, autonomous, and heterogeneous, thus often exhibiting complex behaviors in coworking. Frictional behavior demonstrated by even a few partners, may cause drastic results and total failure of the VO. Therefore, it is necessary to model and analyze VO partners' behavior. This paper introduces the VO Supervision Assistance Tool (VOSAT), developed based on leveraging partners' commitments/promises, to monitor partners' behavior against the synergetic norms in the VO. For this purpose, three kinds of behavioral norms are defined, including: socio-legal norms, functional norms, and activity-related norms. Additionally, a fuzzy norm is introduced to indicate agents' trustworthy behavior. The functionalities supported in VOSAT enable the VO coordinator with identifying the high risk tasks and the weak or weakest points in the flow of VO planned operations. It further assists the coordinator with finding suitable candidate partners for handling the exceptions that arise during the VO operation phase. These in turn improve the success rate of the VOs.

Introduction

An agile Virtual Organization (VO) can be effectively launched within a Virtual organizations Breeding Environment (VBE), to respond to the emerging opportunities, either for innovation or to reflect on market changes [START_REF] Afsarmanesh | On the classification and management of Virtual organisation Breeding Environments[END_REF]. Typically VOs consist of autonomous, heterogeneous, and geographically distributed organizations, which collaborate to achieve the specified set of VO goals. As reported in [START_REF] Gao | Study on the Construction and Benefits and Risks of Virtual Enterprise[END_REF], the study of Laciyt on the construction, benefits and risks of Virtual Enterprises indicates that less than 50% of these established VOs were successful, while more than 30% of these VOs ended up either in total failure or having high risk to fail. Primarily, two categories of risks -exogenous and endogenous -are highlighted in the literature [START_REF] Sun | Tabu search based distributed risk management for virtual enterprise[END_REF] in relation to the success rate of virtual organizations. The former refers to the risks caused by external factors such as the external political risks, technical risks, financial risks, etc. The latter refers to the risks that caused by factors internal to the VO, which rise through its business activities. Furthermore, the behavior of involved organizations is identified as a main element of the endogenous risks. In the approach, which is proposed in this paper, the behavior of organizations can be monitored through the time, such that weak points can be identified and brought to the attention of the VO coordinators, to take appropriate strategic actions.

For this purpose, a framework is introduced for monitoring partners' behavior in the VO. Within this framework, we introduce three kinds of behavioral norms, including socio-legal norms, functional norms, and activity-related norms for the VOs [START_REF] Shadi | Agent Behaviour Monitoring in Virtual Organizations[END_REF], which constrain the partners' behavior and that can be monitored for predication of potential related risks in the VO. Although these three kinds of norms are briefly described below, please note that the main focus of the paper and the remaining sections is on the activity-related norms.

The main norms that rule over the socio-legal aspects applied to VO partners are either those that are known and generally observed in the society, or those that are formalized as clauses within the consortium agreement prepared for the VO, and which are agreed and signed by all partners. We have adopted the approach proposed in [START_REF] Tinnemeier | Programming normative artifacts with declarative obligations and prohibitions[END_REF] to categorize the socio-legal norms as obligations, prohibitions, and permissions, although formalization of these norms is not the main focus of the paper. For example, leadership rights are considered as socio-legal norms from the permission category.

The general terms of operational collaboration among agents involved in a VO are officially negotiated among them via the contracts signed during the VO formation stage, indicating that the partners together fulfill the VO's objectives. In our framework, based on the specifications provided in the VO contracts, a responsibility template is first assumed to be extracted and formalized partially as a time chart, and partially as textual terms specified in the contract, indicating the main roles and general responsibilities of the VO partners. However considering the dynamic and adaptive nature of the VO, these contract terms do not and/or cannot specify the details of dayto-day activities of the VO partners.

Functional norms in the VO correspond to and reflect on the assignment of coarsegrained tasks, but with partial responsibility for each partner, according to what is expressed and represented within the VO responsibility template. Furthermore, the functional norms together with the responsibility template provide the base for definition and assigning of day-to-day activities to each partner, throughout the VO operation phase. However, before such activity assignment is made, it needs to be planned and agreed among the VO partners. In fact such agreement must be reached between two parties, e.g. the task leader who suggests the sub-task, and the partner who commits to the sub-task. In our proposed approach, after reaching each agreement, a promise is made by the partner to the task leader, to perform the needed activity. Fulfillment of a promise made as the result of the agreement described above shall correspond to the activity-related norms in that VO. Therefore, the activity-related norms are also in conformance with the functional norms at the VO.

In this paper, the presented examples target the fine-grained behavior of VO partners. In other words, while contract-based obligations of partners are reflected within responsibility template and can be checked against the functional norms in the VO, the presented examples focus mainly on detailed promises given by partners, in relation to their daily activities. Through the proposed framework, activity-related behavior of partners can be monitored and their possible violations against activityrelated norms are identified. The decision on how to deal with the violation of norms and which sanction to impose on violating partners is also usually specified in the consortium agreement document. But the decision on applying a sanction to a partner is typically made by the VO coordinator and the management team.

As a consequence of supporting the monitoring of activity-related behavior of VO partners, it is also possible to reason about partner's trustworthiness level, based on their past behavior. For the purpose of reasoning on trust level of partners, a fuzzy norm is defined in the framework. We can also monitor and check for the violation of this defined fuzzy norm representing the partner's trustworthiness level. Using the information about partners' trustworthiness, it is possible to reason about the risk factors in the VO. For instance, considering the complete set of current promises at the VO, the least trustworthy promise(s) can be identified. Furthermore, establishing the trustworthiness of partners can also be used for making other decisions by the VO coordinator. For instance when and if an exception is raised for which VO partners need to volunteer to take over some tasks, the VO coordinator can select the most trustworthy among all volunteers.

The remaining structure of this paper is as follows: Section 2 addresses a high level formalization of behavior in Virtual Organization. Section 3 discusses monitoring the activity-related norms. Section 4 specifies how our tool enables the VO coordinators to monitor the trustworthiness of agents. Section 5 addresses some related research, and how our proposed framework compares against them, and Section 6 concludes the paper.

High Level Formalization of Behavior in Virtual Organizations

Virtual Organization is a temporary goal-oriented collaborative network, which is formed in response to the emergence of a business opportunity, e.g. a manufacturing project, and will be dissolved when its goals are achieved. To fulfill the VO's objectives, typically at its creation stage, a number of contracts and a VO Consortium agreement are prepared and signed. A Consortium agreement represents the base for socio-legal norms in the VO, consisting of authorizations, permissions, prohibitions, and obligations. Although socio-legal norms are very important to be defined, they do not directly relate to the operational goals of the VO, rather they support the collaboration atmosphere/infrastructure, which is required for fulfilling its operational goals. These norms include both the generic norms common to all VOs, as well as certain specific norms relevant only to each VO as a single virtual entity. The coworking norms, the norms for sharing data / knowledge / resource, and the prohibitive norms are some examples of these generic norms. The inheritance of the VO assets and responsibilities at the VO dissolution phase, among others are examples of domain specific norms. Socio-legal norms can be categorized using the approach proposed in [START_REF] Tinnemeier | Programming normative artifacts with declarative obligations and prohibitions[END_REF], and are not the main focus of this paper.

As mentioned in the Introduction section, the general responsibilities of VO partners can be extracted from their contracts, which are established during the VO creation stage, and presented in a responsibility template. For example, Fig. 1 shows the responsibility template in the VO established for an R&D project.

Fig. 1. Example of responsibility template for R&D projects

However, usually a task involves several partners, and pre-defining all details of the sub-tasks cannot be effectively done during the VO creation stage. It is rather during the VO operation stage when the responsibility template constituting the functional norms is further instantiated with the definition of more detailed activities for each subtask, with their interdependencies and specific partner assignments.

We consider that all agreements made among agents for performing their day-to-day activities (sub-tasks) are specified as promises. As such, the promises made in a VO provide the definition of activity-related norms. One important and challenging issue in Virtual Organizations is how to deal with joint-responsibilities. Usually, there are activities that should be performed by a group of agents, for which all agents are jointly responsible. In VOSAT framework, these kinds of day-to-day activities are referred to as joint-promises [START_REF] Shadi | Agent Behaviour Monitoring in Virtual Organizations[END_REF]. Making a joint-promise by several agents leads to each of them obliging itself to performing its own responsibilities as well as contributing to the fulfillment of parts for which other partners are responsible. This is due to the fact that

Instantiation of Responsibility Template at time P1:

• Details of task/sub-task (e.g. their interdependencies, deadlines, etc.) are not clearly specified at VO creation phase with joint responsibilities, the reputation and financial interests of all involved partners are at risk. To support fairness in keeping joint-promises, the framework requires that agents involved in a joint-promise also rank their collaborators on the level of cooperativeness and performance toward the joint-responsibility.

The supervisory function of VOSAT provides an enforcement mechanism to detect when a norm is active as well as when and if it gets violated. In other words, to support the VO supervision, it is needed to monitor agents' behavior. This is done partially through checking the compliance of agents' behavior with the norms of the VO, and imposing corresponding sanctions on agents that violate norms. Additionally, since functional norms are in conformance with the activity-related norms, it is sufficient to monitor only the activity-related norms. Besides the activity-related norms, as a part of functionality for monitoring partners' behavior, the level of partners' trustworthiness is also monitored and analyzed against a fuzzy norm defined in the VO.

In a normative environment like a VO, norms can have different levels, norms at level zero are triggered by the external events, whereas a level k + 1 norm, with k > 0, is triggered in case of a violation of some norm(s) defined at level k [START_REF] Tinnemeier | Programming normative artifacts with declarative obligations and prohibitions[END_REF]. In VOSAT framework, trust level is defined as a fuzzy norm for each agent. Activity-related norms are at level 0, because these norms are triggered by environment-related facts. However, the trust(worthiness) level, which is typically triggered by the violation of activity-related norms, is at level 1.

Imposing related sanctions against the norms' violations is very important in Virtual Organizations. For instance, if a promisor notifies the VO coordinator before reaching the deadline that it cannot fulfill its promise on time, it should then be punished less than if it were in the situation in which the deadline is passed and the promise if not fulfilled. But clearly, the sanction policies are not the same in different VOs. Usually, there are two kinds of sanctions that can be applied in order to incentivize the norm compliance and to discourage deviation from norms, one affects agent's resources (e.g. financial punishment), and the other one affects agent's reputation (e.g. black listing), and both leading to the need of re-assignment of the agent's tasks to others. Sanction rules are either mentioned in the consortium agreement or specified by the VO coordinator, and can be defined as response to the violation of norms at each of the mentioned levels.

Monitoring Activity-related Norms

In VOSAT framework, as originally introduced in [START_REF] Shadi | Agent Behaviour Monitoring in Virtual Organizations[END_REF] and further extended in this paper, a promise is defined as a tuple <x, y, p, d, q, d′> where x is the promisor agent, y is the promisee agent, p is the proposition which a promisor should bring about before deadline d, q is a pre-condition for realizing p by x, and d′, is the deadline before which q should hold.

Please note that the VOSAT system considers the notion of time, and can decide when and if a deadline is reached. In this framework, as shown in Fig. 2, different states are considered for a promise. If the pre-condition of a promise is fulfilled on time, the promise's state is Conditional, but if it is not fulfilled before reaching its deadline, the promise's state is Unconditional. However, if the deadline of pre-condition is passed and its pre-condition is not fulfilled then the promise is Dissolved. If the deadline of a promise is passed and the promised proposition is fulfilled then the state of the promise is Kept, but if it is not fulfilled by the deadline, the promise's state is Not Kept. The Invalidated promise is the one that has not been fulfilled due to some reasons beyond the promisor's control. If the promisee cancels its promise its state is Withdrawn, while if the promisor cancels it, its state is Released. For example Pr , as it appears in Fig. 3, represents a conditional promise.

Promise States Description Conditional (C)

There are some conditions that need to be fulfilled first.

Unconditional (UC) All conditions are fulfilled before their deadlines Kept (K) The promise is assessed to have been kept.

Withdrawn (W)

The promise is withdrawn by the promisor. Invalidated (In)

The promise has not been fulfilled due to some reasons beyond the promisor's control.

Released (R)

The promise is not needed any more, so it is cancelled by the promisee. Not Kept (NK)

The promise is assessed to have not been kept. Dissolved (Dis) When conditions are not fulfilled before their specified deadlines.

Fig. 2. Different states of a promise

Furthermore, in VOSAT, the state of promises made by each partner is monitored. For this purpose, a set of rules are defined that apply to promises during their life cycle, and represent how the facts from the environment, and actions taken by the promisor potentially cause the state transition in given promises. Fig. 3 represents a set of rules, which are further explained below.

Fig. 3.

Rules for state transition of a promise during its life cycle [START_REF] Shadi | Agent Behaviour Monitoring in Virtual Organizations[END_REF] The rules primarily express how agents' interactions influence the state of promises. In these definitions, we use "T" for true and "nop" for no-action operation. A rule is represented as ρ, φ, α ⇒ ψ where ρ , φ, α respectively represent a promise-related fact, an environment-related fact and an action, and ψ represents a promise-related fact.

Promise-related facts describe the state of a promise as addressed above, e.g., Pr x, y, p, d, q, d′ denotes the fact that this promise is in conditional state.

Environment-related facts describe the state of the environment e.g. if 9 is d, then it represents that a deadline is reached, and if 9 is T, it represents that the environment facts are irrelevant to this rule.

We further define a specific set of actions that influence the state the promise as shown below. For instance, the creation of a new promise is achieved through an "Agree" action.

• Agree x, y, p, d, q, d′ : x agrees with y to make the proposition p true, before the deadline d, if the proposition q is true before deadline d = .

• Withdraw x, y, p : x informs y that he withdraws his promise to make the proposition p true in the environment. • Release y, x, p : y tells x that it is no longer needed to keep his promise to make the proposition p true in the environment. • Fulfill x, p : x fulfills its promise and thus the proposition p is now true in the environment. • Fail p : proposition p can no longer become true in the environment, due to an external failure. This is considered as an environmental action rather than an agent's action. The state of our proposed behavior supervisory system makes a transition either when an agent performs an action, as mentioned above, or when a deadline is reached. Agents' actions may also cause some environment-related facts to become true, which in turn may trigger some rules applied to the life cycle of a promise. Consequently, in time both the sets of promise-related facts and the environment-related facts will be changed, and new facts are derived.

It should be noticed that for each promise, at most one of the mentioned states is true at any point in time and that some states including kept, not kept, withdrawn, invalidated and dissolved will in principle remain true in the VOSAT framework, once they are true. Not kept and withdrawn states are considered as violation states, and may be decided in a VO to remove them once the sanctions (e.g. charging some damage costs to an agent or adding the agent to some blacklists) are applied. Other states except for conditional and unconditional will remain in the promise-related facts forever.

The derived promise-related facts, such as the withdrawn and not kept states of promises, may in turn also trigger some sanction rules, and result in some new facts, which should then be transmitted to the VO coordinator. For instance ," ,,,L ,,M ⇒ N& OP 3$ is a kind of sanction rule, relating promiserelated facts to environment-related facts. This sanction rule adds the promisor of a not kept promise to a specific black list, for example to be used later for making decisions by the VO coordinator, such as in the case of selecting suitable VO partners for creation of a new VO.

We have used Organization Oriented Programming Language (2OPL) [START_REF] Dastani | Normative multi-agent programs and their logics[END_REF] as the organizational setting to implement our supervisory assistance tool. Some details about our implemented tool are addressed in [START_REF] Shadi | Agent Behaviour Monitoring in Virtual Organizations[END_REF].

Agents Trustworthiness Level as a Fuzzy Norm

The violation of activity-related norms may only trigger sanction rules but also trigger some new norms, such as the trust(worthiness) level norm related to involved agents. In other words, the trustworthiness level of an agent may increase/decrease depending respectively on its fulfillment or violation of its activity-related norms. Therefore, as explained earlier, the activity-related norms are norms of level 0, while the trustworthiness level norms are norms of level 1.

Trust Modeling

There are a large number of approaches introduced in the literature for an agent to build a model of trustworthiness for other agents in an environment. In [START_REF]Social knowledge for e-governance (eRep)[END_REF], a survey of trust models and approaches is presented and two categories of techniques, i.e. objective external evaluation agencies [START_REF] Msanjila | Trust analysis and assessment in virtual organization breeding environments[END_REF] and subjective external evaluation agencies are introduced. Our approach applies a combination of these two general approaches, i.e. a VOSAT's normative artifact collects on one hand the information related directly to an agent's behavior norm abidance containing certain pre-defined criteria, and on the other hand collects the ranking by others about each agent's collaboration, as provided by other agents when together performing joint-responsibilities. These two factors are then combined for calculating an overall trust value of each agent, applying a fuzzy comprehensive evaluation method. Our approach is flexible and different factors can also be added to it if needed for evaluating agents' trustworthiness. The fuzzy comprehensive evaluation method [START_REF] Li | An improved multilevel fuzzy comprehensive evaluation algorithm for security performance[END_REF], which we introduce for trust evaluation in VOs, considers various factors each indicated as f S that influence a certain element, and it applies fuzzy mathematical methods to evaluate the merits and demerits of that element [START_REF] Li | An improved multilevel fuzzy comprehensive evaluation algorithm for security performance[END_REF]. At the first stage, the fuzzy factor set F = Uf L , f M , … , f W X and the evaluation set E = Ue L , e M , … , e Z X are established. In VOSAT approach, we have considered two fuzzy factors of individual norm abidance -evaluated in the interval of [0,2], and collective norm abidance -evaluated in the interval of [0,2]; thus f L denotes individual norm abidance and f M denotes collective norm abidance. To evaluate the individual norm abidance for an agent A, the interaction/collaboration experiences of agent A with all other agents are considered, namely the number of all kept promises made by A to other agents, and the number of all violated promises. To evaluate the collective norm abidance for an agent A, all received ranking recommendations from other agents about A are aggregated.

Our proposed evaluation set for trustworthiness, i.e. Ue L = high distrust, e M = medium distrust, e \ = low distrust, e ^= low trust, e _ = medium trust, e `= high trustX is defined in the interval of [0,2]. For the defuzzification process, we directly apply the center of gravity method, as introduced in [START_REF] Patel | Some numerical aspects of center of area defuzzification method[END_REF]. As a result of defuzzification, the result of B will transfer to a single value, denoting the overall trustworthiness of each agent. For the mentioned example, the n0 0 0 0.3 0.7 0o is then defuzzified to 1.49, showing the overall trust value of agent A. If in a specific VO, the minimum accepted level of trustworthiness is "medium trust" then the violation of this agent (with the overall trust value 1.49) is zero.

In our approach we also emphasize the importance of having sufficient information about an agent for evaluating its trustworthiness level. Therefore, for fairness purposes, a confidence level should also be considered for each factor related to the agents in the VO. In other words, if the confidence level for a factor is above a predefined threshold, then it has a direct effect on the trust evaluation results. For example, if an agent's involvement in the VO is either for longer than T period of time or in more than C number of activities, his trustworthiness level norm is active and it will be monitored if any activity-related norm of his is violated. Trustworthiness level norm can also be treated differently based on the type of the VO. For example in one VO it may be sufficient to have a medium trust level for agents, while in another one it may be necessary to fulfill the high trust level for all agents.

One advantage of monitoring this fuzzy norm for trustworthiness of agents is to enable the VO coordinator with finding the best potential candidate for handling the exceptions that require re-assignment of tasks. Another advantage is to assist the coordinator with identifying which one of the running tasks (current promises) might involve risks, through identifying which agents' trustworthiness level norm are violated.

Related Works

In relation to agents formal commitments, a number of research in the multi-agents community address the area of agents' formal contracting, the concept of leveled commitment contract [START_REF] Sandholm | Levelled Commitment Contracts and Strategic Breach[END_REF], and reasoning about commitments and penalties [START_REF] Excelente-Toledo | Reasoning about commitments and penalties for coordination between autonomous agents[END_REF]. The authors in [START_REF] Sallé | Electronic Contract Framework for Contractual Agents[END_REF] propose a contract fulfillment protocol based on the normative statements' lifecycle. Our approach however differs from the above approaches due to targeting the specificities of the VO environments, e.g. the aspects of continuous evolution, joint responsibilities, etc., for which we introduce and apply the concept of promises that are not necessarily bilateral.

Related to categorization of norms in agent communities, in [START_REF] Dignum | Modelling agent societies: co-ordination frameworks and institutions[END_REF] a two-level normative agent interactions is proposed for a society of agents including an institutional level, and an operational level. The institutional, constitutional, and operational levels are also addressed as a hierarchical organization of norms in [START_REF] Cardoso | Virtual Enterprise Normative Framework Within Electronic[END_REF]. Although our proposed approach has some aspects in common with these approaches, it addresses the VO dynamism as activity-related norms, defined as promises, which do not directly represent contractual obligations. Furthermore in our approach, such dynamic aspects are specified gradually during the VO operation phase.

In relation to research on the formalization of promises and norms, in [START_REF] Burgess | An Approach to Understanding Policy Based on Autonomy and Voluntary Cooperation[END_REF] and [START_REF] Zhao | Modeling belief, capability and promise for cognitive agents-A Modal Logic Approach[END_REF] some definition of promises are represented by Modal logic. However this logic does not allow for reasoning about the complex life cycle of promises, which is needed in our proposed operational framework for VOs. In [START_REF] Vasconcelos | Normative conflict resolution in multi-agent systems[END_REF] norm conflicts and inconsistencies in Virtual Organizations of software agents are addressed. Dynamic nature of a VO results in changing the agents' normative position, and consequently conflicts may occur in an agent's norms. In their model of norm-governed agency inspired by the BDI model, agents can independently decide either to obey their norms or to violate them. However, in VOSAT framework, the internal states and operations of individual agents are not considered and only the external actions of agents are monitored against the given set of norms. Moreover, agents' actions are not limited to the two types of actions -obedience and violation-rather a number of different states are considered for promises.

According to the theorem of "duality of structure" [START_REF] Giddens | The constitution of society: Outline of the theory of structuration[END_REF], in a VO where agents repeatedly refer to the social structures (norms) to do their actions, trust is a medium of structuration. In relation to computational reputation and trust models, in [START_REF] Msanjila | Trust analysis and assessment in virtual organization breeding environments[END_REF] four different categories are classified, which are explained below. In the so called category of Agent-Oriented Solitary Approaches [START_REF] Herzig | Prolegomena for a logic of trust and reputation[END_REF], the evaluations are calculated by the agent itself according to its own previous experiences without any exchange of information. In the category of Agent-Oriented Social Approaches [START_REF] Carbo | Trust management through fuzzy reputation[END_REF], agents calculate the evaluations considering both their own experiences as well as the third-party information. Trust modeling in social networks is usually categorized in agent-oriented approaches [START_REF] Yu | A: social mechanism of reputation management in electronic communities[END_REF]. In the categories of Objective External Evaluation Agencies [START_REF] Msanjila | Trust analysis and assessment in virtual organization breeding environments[END_REF] and Subjective External Evaluation Agencies [START_REF] Josang | survey of trust and reputation systems for online service provision[END_REF] instead of agents, external agencies collect the information. The former computes evaluations according to certain objective criteria, while the latter aggregates the subjective agents' evaluations that are collected by the system. In proposed approach, we combine elements from the last two approaches above, to make the trust model for VO partners.

Conclusions

This paper addresses a framework and tool called VOSAT for virtual organizations to assist with controlling the behaviors of agents involved in VOs, through monitoring their activity-related norms and imposing appropriate sanctions when agents fail and norms are violated. To perform day-to-day activities a number of individual and joint promises are made by the involved agents, which in turn define the activity-related norms in the VOs. The main focus of the paper is on the definition of the needed framework as well as the extension of the tool to define and monitor trustworthiness level of agents as a fuzzy norm. Consequently, the VOSAT enables the VO coordinator with both finding suitable candidate partners to replace a failing partners and handle such exceptions during the VO operation phase, as well as identifying the weakest points or the high risk tasks in the VO's planned operations. These in turn assist with improving the success rate of VOs. The proposed tool is prototypically implemented using the Organization Oriented Programming Language (2OPL) [START_REF] Dastani | Normative multi-agent programs and their logics[END_REF], and more details about the tool implementation are addressed in [START_REF] Shadi | Agent Behaviour Monitoring in Virtual Organizations[END_REF].

Fig. 4 .

 4 Fig. 4. The proposed trust evaluation setAs Fig.4shows, membership functions from left to right correspond to Ue L , e M , … , e `X. At the second stage, we establish the fuzzy evaluation matrix R. So far, we have defined how to collect/calculate the value for each factor. Then according to the value of factor f S , we can determine its grade of membership in each e a , which is expressed as r Sa . For example, if for agent A we have Uf L = 1.6, f M = 1.2X then the fuzzy evaluation matrix R to calculate its trust level is R = e 0 0 0 0 0 0 0 1 1 0 0 0 g.At the third stage, we introduce different weights for each introduced factor, i.e. W = Uw L , w M , … , w W X, where ∑ w S = 1 W SiL. Depending on the type of VO the importance of one factor may be more than another factor. Assuming the W = U0.7, 0.3X relating to the factor set of Uf L = 1.6, f M = 1.2X, the result of the comprehensive fuzzy evaluation is calculated as B = W • R = n0.7,0.3o • e 0 0 0 0 0 0 0 1 1 0 0 0 g = n0 0 0 0.3 0.7 0o.

Acknowledgments

The work on this paper is partially supported by the FP7 project GLONET.


Mohammad Shafahi
email: m.shafahi@uva.nl

Hamideh Afsarmanesh
email: h.afsarmanesh@uva.nl

Mahdi Sargolzaei
email: m.sargolzaei1@uva.nl

A Coopetition Space for Complex Product Specification

Keywords: Complex Products, Product Specifications, Virtual organizations Breeding Environments (VBE), Service-enhanced Products, Coopetition

Due to peculiarities and complexities embedded in complex service-enhanced products, e.g. automated buildings, these products are one-ofa-kind, largely customized, and may involve a large number of competitive / cooperative multi-stakeholders. Life cycle of complex products typically includes a substantially long creation phase, followed by its operation and evolution phases that last over decades. Although, the majority of complex product components (e.g. equipment and services) are specified gradually and by varied stakeholders during its creation stage, further specifications are also provided later on to support its evolution. This paper addresses challenges in both specification of varied and numerous components, and managing these specifications thought-out the complex product life cycle. We address reusability, modularity, and federated sharing requirements in the coopetition space of complex product specification, and within the context of Virtual organizations Breeding Environments (VBEs). Our developed product specification system, which is already alpha tested, addresses these identified requirements, and is described and exemplified.

Introduction

Complex products (e.g. solar power plant and intelligent buildings) are one of a kind in their design specification and massively customized in their production. Furthermore, the Product Life Cycle (PLC) of such complex products runs over several decades. The specification of complex products is therefore typically not performed in one session, rather iteratively during its life cycle, and potentially involving a number of different stakeholders, from equipment manufacturers and service providers, to experts at an EPC (Engineering, Procurement, and Construction) company. These stakeholders need to collaborate within a coopetitive environment, in order to gradually and incrementally specify different components and sub-components related to the complex product.

Additionally, based on our findings in the area of solar plants and intelligent buildings, which are relatively young industries, the design and engineering of these complex products cannot be resulted through the mere searching and identification of the needed components among the existing products in the market. In other words, although familiarity with the existing related product/service details, as provided by different manufacturers and suppliers in the market, are the necessary starting point for the complex product designer, the mere existence of these product details are not sufficient to fully specify the Project Design of the complex product. Rather, the nature of our targeted complex products mandates detailed and concise design and customization processes for its sub-products, including the equipment, devices, and enhancing services, as well as involving different stakeholders in these processes.

We propose an environment for complex product specification, to provide the coopetition space needed through different PLC phases. A number of earlier research works address collaborative environments for product specification and design, e.g. for collaborative CAD systems [START_REF] Li | An Internet-enabled integrated system for codesign and concurrent engineering[END_REF] [START_REF] Li | Collaborative computer-aided design-research and development status[END_REF]. In this paper however, we investigate requirements for a product specification environment that can support collaboration among competing companies (the so called Coopetition), within the context of VBEs and goal oriented Virtual Organizations (VOs). Considering the coopetition environment that is supported in the complex product VBEs, a main aim in this environment is to support the reusability, modularity, and sharing of the generated assets. As mentioned above, the addressed complex products are young industries and therefore their stakeholders can very much benefit from sharing the specification of sub-products that are designed by others. Therefore, supporting both the reusability of sub-product specifications and the possibility of granting access privileges on them to other stakeholders are important requirements. Furthermore, considering that these complex products are one-of-a-kind, their designed sub-products can be reused only in the case where sub-product's specifications follow a modular design approach, so that the pieces of their specification can be accessed and copied for reuse.

Besides the specification of various equipment and devices needed for complex products, we also address the specification of variety of needed business services, that can range from software systems to human-provided (the so called manual) services, and which in one way or another enhance the complex product.

In the knowledge-based economy, services have an increasingly important role in manufacturing industries, which use functionality provided by services to differentiate their products [START_REF] Hertog | Knowledge-intensive business services as co-producers of innovation[END_REF]. In fact, by adding business services, while it also increases the value of the products, a higher level of differentiation can be realized [START_REF] Bitner | The evolution and discovery of services science in business schools[END_REF]. Therefore, in our design of the specification framework for complex products, we consider that subproducts typically come with a set of business services that offer some beneficial enhancement to the customers of these products. Capturing different aspects of these business services as well as the inter-relationships and links between these services and other sub-products of the complex product (e.g. devices), are main requirements for our proposed complex product specification framework and system. Many approaches and standards have been developed by the research community in the area of Service Oriented Architecture (SOA) to specify and formalize business services [START_REF] Afsarmanesh | Semi-automated Software Service Integration in Virtual Organizations[END_REF]. There are however still challenging and open questions related to how make services interoperable, so that they can be shared and reused, as well as how to assist authorized service providers with composing other services, thus producing value-added service to support complex products. Furthermore, there are still gaps in correlation between services and products in the context of complex products.

Please note that this research on product specification framework is performed within the GloNet1 [START_REF] Camarinha-Matos | Collaborative networks in support of service-enhanced products[END_REF] project, and constitutes one of its subsystems.

The remaining sections of this paper are structured as follows. In Section 2 we address the role of product specification in different phases of our target complex products' life cycle. In Sections 3 and 4 we will focus on how to realize the main requirements (non-functional and functional) for complex product specification framework and provide some details related to the implementation. Finally in Section 5, some concluding remarks are provided.

Product Specification in Different Phases of the PLC

The PLC of a complex product can be divided into the following three main phases [START_REF] Afsarmanesh | ICT requirements analysis for enterprise networks supporting solar power plants[END_REF], each having its own peculiar features:

(i) design and engineering, (ii) construction and commissioning, and (iii) long term operation and maintenance. In this section we address these three phases, primarily in relation to the specific product specification needs of stakeholders that are involved in the phases. But before focusing on each phase, we should point out that the product specification is also needed before the PLC of the complex product starts. This is mainly due to the need for preparation of the bid for the targeted complex product, for instance in response to a call for tender. Figure 1 indicates the product specification process during different phases of the complex product's PLC, as well as during the pre-phase of bidding for the complex product, in order to preform cost estimation and initial partner selection. Design and Engineering phase: Being the first phase in the PLC of the complex products, the design and engineering phase plays an important role in the success of the later phases. Activities during this phase are typically divided into the three steps of: project assessment, project design, and project implementation. Project Assessment step includes the complete analysis of the site and the technical assessment of the entire project, at this step a high-level specification of the complex product is made in order to assess the feasibility of the project. After the Project Assessment has been successfully preformed, during the Project Design step the early engineering and selection of technology takes place. These include the following activities, which are reflected in some detailed specification of complex product:

(i) Pre-engineering -e.g. achieving initial specifications of the complex-product, (ii) Evaluation/selection of technology or equipment -e.g. evaluating for selection or extension of existing devices and equipment suitable for complex product), and

(iii) Selection of sub-product specifications -e.g. adding sub-product specifications as components of complex-product specification.

Finally after the Project design step has been successfully preformed, during the Project Implementation step, the planned specification of the complex product is finalized and the product specification is used for selecting the relevant organizations and for sub-product procurement.

Construction and Commissioning phase:

Typically during this phase, no new product specification is made; rather the existing ones might be accessed to retrieve some detailed design information. Operation and Maintenance phase: Although as discussed above, the product specification is fundamentally required during the entire design and engineering phase of the product life cycle, it is also usually needed to be used later during the long-term operation and maintenance, but rather infrequently. This occurs mostly due to the continuous need for evolution of the complex product and/or to innovate and provide new products either in response to "newly identified" needs or some problems emerged during the operation phase. Example cases of such requirements vary from enhancement or upgrading a control box in a solar plant, to replacing the panels damaged in an earthquake.

Realization of Non-functional Requirements

At its base, system requirements address why a system is needed, what are the functions it must provide, how the system must be constructed and implemented, and what conditions must be satisfied by the system. The two main types of requirements are the non-functional and the functional requirements [START_REF] Abran | Guide to the software engineering body of knowledge-SWEBOK[END_REF]. This section addresses the most important non-functional requirements for our product specification space, namely the: security, integrity, scalability, and portability.

Security

Security plays a very important role in systems. This is due to the fact that improper access to a system might bring loss and even bankruptcy to the organization using the system. Proper prevention of threats via competitors, both from the outside world (enforcing authentication) and from the inside of the system (enforcing authorization), is a must. The main steps in this process are addressed below.

Authentication

There are three different main techniques that can be used for authentication, including [START_REF] Kaufman | Network security: private communication in a public world[END_REF]: what you are, what you have, and what you know.

Among the above, and considering the usage/user of the product specification space, we have selected the "what you know" technique. In this approach the product specification sub-system (developed on top of the cloud-based GLONET platform) receives a token about each user's authenticity. This token is generated through the "Single Sign-On" mechanism implemented within in the GloNet platform [START_REF] Surajbali | A Cloud-Based Approach for Collaborative Networks Supporting Serviced-Enhanced Products[END_REF].

Authorization

A very important requirement for any system that deals with multiple stakeholders (specifically within a coopetitive environment) is its secure and proper information sharing as well as mechanisms for granting access privileges to authorize users. This is due to the fact that although different stakeholders in VBEs may cooperate to achieve some specific common goals, they are potential competitors on many others.

To preserve users of the product specification space, against unwanted data access to their private information, we have designed and implemented three different data spaces (levels of access) for users of this system, that limit who can access what. As also illustrated in figure 2, these spaces include: Private -only for personal use of the user, Restricted -specified by the user to be shared only with the partners of certain VO or one specific project, and Public -to be shared with all in the VBE.

Please note that the user who defines a product specification within the system is the owner of that specification. Therefore, only that user can with some condition move such specification from one data space to another, e.g. from private either to restricted or public, in order to share it with others. Private data space: The first step in the process of product specification is to specify sub-products of the complex product. To accomplish this task, designers should have a private space to do their specifications before making them available to other stakeholders involved in specification process of the complex product. This space is called private space and specifications in this space are only accessible by its owner. Public data space: After one has specified a product he/she might wish to share the specification with the public, meaning within the VBE. This can be exemplified by a sub-product manufacturer or provider who wishes to promote the use of its already built product (e.g. an equipment), to be used as a sub-product for building other complex products. However, a number of users nowadays may be involved and interested to participate in open access movements. To enable this possibility, system provides a VBE public space for users, to provide access to owned specifications. Restricted data spaces: Within the process of specifying one complex product, multiple stakeholders are typically involved. This usually happens within a VO, when users would be interested to share certain specifications only with the other VO partners. To enable this feature, one user can indicate the restricted space for its product specification. Consequently, every time a VO is created a restricted data space is created for it. We shall now address how the users can view and/or move their owned specifications from one data space to other data spaces. Once a product is specified, it can be viewed by its owner. The screenshot in Figure 3 illustrates how product specifications can be viewed by a user. Depending on the selected VO-name or projectname (as indicated in the upper right corner of the screen), a list of associated specifications for which the user is authorized to view will appear, sorted by their product names. Please note the symbols that appear in front of the product names, where (-) represents private and (#) represents restricted. Also note that the semantics of projects and VOs are very different, and while the former indicates one optional userdefined folder, the latter is dedicated to all restricted specifications belonging to a specific VO. Please also note the following three cases: -If neither a specific project nor a specific VO is identified by the user (on top right of the screen), then all public product specifications in the system, further to all private specifications of that user, will be illustrated.

-If no project is mentioned by the user, but a VO is specified for which the user is authorized, then only restricted specifications related to that VO will be illustrated.

-If the user specifies no VO, but a project-name, then all the private, restricted, and public product specifications that the user has associated to that folder will be shown.

In the example of Figure 3, the user Prolon has selected/indicated the VO's name "Electrical Design". Consequently, all restricted product specifications that belong to this VO, as well as the all those public sub-products associated to this VO are illustrated. Please note that while Prolon might itself own some of these restricted products, other users (who are also partners of this VO) own the others. Other than viewing the product specifications, authorized users can also change the accessibility of these specifications by preforming the following set of actions: -Share action (shown with icon ), which provides the user with the option to change the access rights/sharing status of a certain product specification that he/she owns. The share options are available through existing products window, when the user clicks on its icon. Please note that when defining a new product specification, by default the access right to that specification is made private, that is if the user has not indicated a VO on the top right corner of the screen, in which case by default the specification becomes restricted to that VO. At any point in time, the owner of the product specification is allowed to only broaden the access to that specification. This means that if a specification is private, then the owner can change it either to restricted within a VO, or to public. In other words once the owner of a product specification grants certain access rights to others (e.g. to view the specification) he/she cannot withdraw that right later.

-Assign to Project action (shown with icon ), which provides the possibility to provide access to an already defined specification, to which user has access and is already indicated as private, public, or restricted, to an existing project folder of that user. This is mainly to assist the user with organizing his/her product specifications in different folders. This means that by default if a project is indicated on top right corner while specifying a product, then that product will be allocated to that project folder. Nevertheless, through this action, as provided in the Existing Specification window, specifications may be assigned and reassigned to different project folders.

-Delete action (shown with icon ), which allows hiding certain specification(s) from the users' screen, for instance if the user finds a sub-product useless for him/her to keep, its specification can be deleted from his/her view.

Scalability

During its PLC, a complex product might potentially deal with hundreds of users. To support such a user base, and to enable possible expansions to both the user base and the product specifications, we have leveraged the possibilities supported by the cloud environment that allows allocation of more resources on demand, when and if needed. This leveraging has been done through applying three different techniques. First, different components of the system (i.e. the executable building blocks of mainly the Controller layer and the DAO implementation layer) are decoupled from each other, which include decoupling: the web service controllers, web interface controllers, Hibernate DAO Implementations, GloNet DAO Implementations, etc. This means that none of these components depends on how another component is implemented or executed, which in turn enables the execution of different components on different physical and/or virtual machines. Second, the implemented product specification space is layer-based (e.g. having Application, Data, etc. layers), while existence of each layer is transparent to the other layers. Consequently, not only the components of our designed system are decoupled, but also the different layers are decoupled and can run on different physical/virtual machines. And third, the implemented system can take advantage of load balancing mechanisms for their data, supported through separation of data access to objects, and how it is implemented.

Portability

The product specification space has been developed as a web-based application, using Java programming language that enables the server side code to run independent of the platform. The server side program generates standard outputs (e.g. HTML 5 [START_REF] Lubbers | Pro HTML5 programming[END_REF]) that could be consistently and easily rendered by different browsers. The client side (Browser side) of the program is based on JavaScript and is written using jQuery framework [START_REF] Mccormick | JQuery: finding your way through tangled code[END_REF], to insure that JavaScript code is compatible with different browsers.

The combination of java as the programming language of the server side and the compatibilities of the client side, such as compatible JavaScript and standard HTML 5, makes both the client (browser) and the server side of the system highly portable.

Realization of Functional Requirements

The complex product specification space, addressed in this paper, needs to provide a set of functionalities to support: product and service specification and registration.

Within the context of the data level of the PLM (Product Lifecycle Management) framework [START_REF] Hvam | An approach for the development of visual configuration systems[END_REF] for complex products, three main product models need to be captured throughout its lifecycle. These include: its Geometric-oriented product models (e.g. through CAD system), the Structure-oriented product models (e.g. through DMS -Digital Manufacturing System), and the Meta-data-oriented product models (e.g. through a database). The product and service specification space primarily captures, handles, and manages the detailed meta-data about the complex product and all its subproducts, and assists users with their specification. Furthermore, the product specification space captures and stores links to a set of files that represent the other two product models, which are mainly produced in certain industry specific systems, e.g. CAD, CAM, and DMS software.

The main requirements for the functionality provided by the product and service specification space are three-fold. The first requirement is to support gradual specification of the complex products. This is needed to reflect the reality of complex products that are neither defined in one session, nor by one stakeholder. Therefore, detailed specifications that capture and transform customer requirements for a complex product into discrete sub-product specifications, can be gradually defined by the involved multi-stakeholders, using the developed product specification space. The second requirement is to properly capture the classification of all relevant sub-products in a granular and modular manner in the complex product environment, e.g. distinguishing and capturing both the electrical and mechanical aspects of a subproduct, as well as their inter-relationships. This will in turn support effective multiperspective retrieval/discovery of information related to sub-products, as well as creating their concise descriptions, as needed for common understanding among different related stakeholders. The third requirement is to capture all details related to sub-products in a reusable from. As such, the existing specifications of already introduced sub-products can be either fully or partially (e.g. at the level of certain detailed feature-kind) reused for the specification of other sub-products.

In the following subsections we address an approach and different steps involved in defining details of sub-products and services related to complex products, through the use of the product and service specification and registration space.

Supporting granular and customized specification of sub-products

Supporting different levels of granularity and customizability is a necessity for complex products, due to their dynamic and complex nature. At the lowest level of granularity, the features of a specific sub-product can be defined. Every feature is an instance of a feature-kind. Through the granular definition of feature-kinds and instantiating the features, the system enables the user to specify any sub-product from scratch, and without being limited to only defining sub-products as instances of already existing type of products, with a pre-defined set of fields/attributes.

Here the required functionality for the product specification space includes enabling the user to define feature-kinds, as needed for definition of classes of sub-products, as well as to specify the sub-products based on providing their features. Furthermore, the specification of feature-kinds makes them reusable, so that once they are defined; all users can use them both for the specification of new class of sub-products, as well as View action (shown with icon ), which takes the user to the view window of the product specification.

Complex product/sub-product Launch Request

After the designer has specified a product, its specification should be used for planning a VO that can configure and establish its realization. Figure 2 illustrates this functionality as the request for sub-product/complex product launch. This request can be issued by a sub-product designer, and must result in packaging of the product specification, and sending it through the cloud to the system that supports the VO formation for the sub-product. The product specification space needs to support this functionality to enable the user with requesting the initialization/launching of the process that can realize the targeted specification. Thus, this request triggers the process of planning a goal-oriented VO.

Service specification and registration

Each business service (BS) is materialized through some business sub-processes [START_REF] Camarinha-Matos | Collaborative Business Services Provision[END_REF]. These sub-processes represent how the services would be performed. The actions involved in the business service delivery can either be materialized automatically through some software (e.g. web services), manually through several human tasks, or even through a combination of these two kinds of activities. The automatic solutions are usually called software services, and the manual solutions are referred to as manual tasks. In order to develop a unified ICT-based business service specification environment, also for representing manual tasks we consider a simple software service that only indicates the start and end points of the corresponding task.

We consider four characterizing aspects of business services as being required to be provided during the service specification stage. These four aspects are required to improve functionalities supporting service interoperability, namely to support service discovery and service composition. These four aspects of the proposed service specification are described below, while the formalisms and standards that can be applied for representation of each aspect are also introduced. We have also adopted one specific notation for representation of each aspect, as also addressed below.

-Syntax: Typically, syntactic properties of a service are represented by XML-based standards and languages, such as the web service description language (WSDL) and Simple Object Access Protocol (SOAP) [START_REF] Curbera | Unraveling the Web services web: an introduction to SOAP, WSDL, and UDDI[END_REF]. Some examples of syntactic aspects of the BS specification include: service name, the name of operations contained in the service, as well as their needed arguments. WSDL is selected as the notation for syntax specification in our development.

-Semantics: Conceptual properties of services, here referred to as semantics, are typically defined with ontology, as an explicit specification of a conceptualization of the knowledge about the service. The service ontology definition encompasses a group of vocabularies that specify semantic attributes of services (e.g. goals and category) and their inter-relationships, which together present a meaningful concept about the service [START_REF] Afsarmanesh | The management of ontologies in the VO Breeding Environments domain[END_REF]. In fact, the semantics description of BSs would enrich the lack of information about the services, which cannot be specified by syntactical descriptions, including: goals, context, pre-conditions and post-conditions of the BS. Here, OWL-S [START_REF] Lara | A conceptual comparison of WSMO and OWL-S[END_REF] is used for capturing service semantics within the proposed service specification. OWL-S provides the rich description language needed for representing semantics related to services.

-Behavior: Besides semantics and syntactic description of the services, we also need to specify and formalize the externally observable behavior of each service, which shall represent the proper invocation order of its operations. These behavioral properties can be used later within the functions support service discovery and integration, for improving the accuracy of service matchmaking and facilitating the automation of integrated service execution [START_REF] Sargolzaei | A tool for behaviour-based discovery of approximately matching web services[END_REF], [START_REF] Afsarmanesh | A framework for automated service composition in collaborative networks[END_REF]. Furthermore, the behavioral aspects of the BS specification address its functionality, to the level that it can then be unambiguously implemented by software developers. We have proposed to formalize the behavior of the services in terms of Constraint Automata [START_REF] Baier | Modeling Component Connectors in Reo by Constraint Automata[END_REF], within which every state of a Constraint Automaton (CA) represents an externally observable internal configuration of a service, and every transition represents the exchange of one or more messages by this service. In fact, a CA allows the user to capture the behavioral specification of a service by a finite number of states and some labelled transitions, as well as enabling software developers to follow the sequences of executed operations, in order to decide and implement the behaviors of the service. This behavioral specification comprises essential information for automated service invocation in case of stateful services [START_REF] Jongmans | Automatic code generation for the orchestration of web services with Reo[END_REF]. Stateful services are defined where a client intends to keep either some data or some states during one invocation of the service, and then deploying those data and states during a subsequent invocation. In other words, the invocation of a stateful web service depends on its pervious invocations. To put it briefly, the formal specification of the stateful services' behavior provided by Constraint Automaton specifies the desired sequence for operations' invocation. The specification for stateless services consists of several single state CA, namely one Constraint Automaton for each operation in the service.

-Quality Criteria of Service (QCS): While the service discovery is usually done according to the functional properties of the BS specification (i.e. syntax, semantics and behavior of services), non-functional properties of services, i.e. Quality of Service (QoS) parameters also play an important role in customer's service selection. Therefore, we have also proposed to specify some QoS metrics as quality criteria of services to assist customers in service selection and to improve the accuracy and optimization in service matchmaking. The QoS values of services are usually claimed by service providers and ensured through a service level agreement (SLA) as a part of a contract between the service provider and the customers [START_REF] Dan | Web services on demand: Wsla-driven automated management[END_REF]. We have identified some quality criteria for assessment of offered services such as the execution duration, the maximum response time, and the service availability. The QCS agreements in SLAs are represented as promises among the involved partners in the VO. In [START_REF] Shadi | Agent Behavior Monitoring in Virtual Organizations[END_REF] different states of such promises are introduced, including: conditional, unconditional, kept, not kept, withdrawn, released, and invalidated.

Concluding Remarks

This paper addresses the area of service enhanced complex product specification within the context of VBEs and goal-oriented VOs, which involve collaborations among competing companies, the so called coopetition. We presented a set of functional and non-functional requirements for product and service specification within this context and in different phases of the complex products life cycle. Furthermore we have introduced and provided some design and implementation details for developing a coopetition space to support complex product specifications, while realizing its identified non-functional and functional requirements. The implementation of this system has been developed in Java programming language, using the Spring [START_REF] Johnson | Professional Java Development with the Spring Framework[END_REF] and Hibernate [START_REF] Bauer | Java Persistance with Hibernate[END_REF] frameworks. Its database is built using the GloNet platform [START_REF] Surajbali | A Cloud-Based Approach for Collaborative Networks Supporting Serviced-Enhanced Products[END_REF] and the MySQL [START_REF] Kofler | What Is MySQL?[END_REF] database management system. The general framework applied for development of the complex product specification space follows the layer-based MVC (Model-View-Controller) software design pattern [START_REF] Reenskaug | Models-views-controllers[END_REF]. This system is already beta tested by industrial partners within the GloNet project. Some more details over its design and implementation are presented in [START_REF] Afsarmanesh | Specification and Configuration of Customized Complex Products[END_REF].

Figure 1 -

 1 Figure 1-Product specification in different phases of complex product's PLC

Figure 2 -

 2 Figure 2 -Three Data spaces in relation to product specification framework

Figure 3 -

 3 Figure 3 -Existing Specifications Window (restricted to one VO)

http://www.glonet-fines.eu

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 the project.

for instantiating features related to specific sub-products. Example screen shots of the product specification space are presented in Figure 3 and Figure 4.

Capturing product specification perspectives using classification

When specifying a sub-product related to a complex product, due to the multidisciplinary nature of complex-products, it is important to enable the user by providing different perspectives of that sub-product, based on their related features. This can be supported through definition of classes in product specification. Furthermore, classes guide the users to provide proper feature information related to sub-products. For example one can define feature-kinds to be obligatory for a given class, so that if a user identifies a product as belonging to a certain class of products, then the user is warned to also provide features for its obligatory feature-kinds.

Supporting sub-product re-specification

When dealing with complex products, the user may wish to slightly re-specify a subproduct for its own design, or customize an existing sub-product specification in order to enhance, extend, revise, and finally perhaps assign it for restricted sharing. Several of the above needed functionality from the product specification space area already addressed in the paper, and represented in Figure 3. Two more functionality are required, as indicated in Figure 3 and described below. Duplication action (shown with icon ), which takes the user directly to a pre-filled "New Product" window. This simplifies the task of users, since in that window the specification information about the selected product is duplicated, which can be further modified/edited by the user to define a new but similar specification.


Gokula Vasantha
email: gokula.annamalai-vasantha@strath.ac.uk

Rajkumar Roy
email: r.roy@cranfield.ac.uk

Jonathan Corney
email: jonathan.corney@strath.ac.uk

Challenges and Opportunities in Transforming Laser System Industry to Deliver Integrated Product and Service Offers

Keywords: Servitisation, Product-Service System, Laser System, Stakeholders

Laser system industry is a complex network entity that includes laser component manufacturer, laser manufacturer, system integrator, laser job shop, laser process developer and end product manufacturer. Currently this market segment is predominately product-centric in which the common business model is to sell laser systems with two years warranty. However increasing competition within this segment is forcing some stakeholders to go further than the existing business model, and aim to build long-standing relationship between others. In this paper, the current structure and level of servitization in laser industries, the implications of higher levels of servitization for the various stakeholders of the industry, and the opportunities to develop and deliver higher levels of servitization are discussed. Analyses of semi-structured interviews with managers of laser system manufacturer and laser job shops reveal that any servitized solutions would primarily require the transfer of capabilities between various stakeholders.

Introduction

Globalized economic pressures and competitive business environments are forcing industries to look beyond product-centered business proposition. Many studies have point out that manufacturing industries in developed countries need to compete on the basis of value delivered rather than on the basis of cost [START_REF]OECD: Staying Competitive in the Global Economy: Moving up the Value Chain[END_REF]. Servitization can be considered as a shift from selling products to selling an integrated combination of products and services that deliver value in use [START_REF] Baines | State-of-the-art in product service systems[END_REF]. Product-Service Systems (PSS) are proven to add beneficial advantages in terms of increase in revenues, to establish closer relationship with customers, and act as a mechanism to understand interactions and product usages better [START_REF] Baines | Servitization impact study: How UK based manufacturing organisations are transforming themselves to compete through advanced services[END_REF]. Irrespective of these proven advantages, designing innovative servitized offerings is challenging, and the design process is often ad-hoc, and procedures are not well documented both in academia and industrial practices. This situation is due to obstacles in transferring lessons learnt across varying industrial environmental conditions, and different stages of maturity levels in offered products and services. Also difficulties raised due to many stakeholders and organizations involved in value co-creation of servitized offerings. To bring cross transformational knowledge exchanges, there is a need to benchmark critical parameters involved in designing servitized offerings.

In this paper, we aim to generate generalized critical parameters involved in designing servitized offerings through undertaking a study in the laser system network. These parameters are based upon the detailed analyses of literature reported case studies results. The rest of this paper is structured in four sections: detailed literature summary on the case studies results from designing servitized offerings, research questions and methodology used, presentation of results, and discussion and conclusion.

Related Literature

Reviewing the existing literature, Baines [START_REF] Baines | The servitization of manufacturing: A review of literature and reflection on future challenges[END_REF] noted that there is a paucity of previous work that provides guidance, tools or techniques, that can be used by companies to servitized. There are many descriptive studies are required to understand this domain in-depth. To provide a focused review, only latest descriptive studies on success factors and challenges involved in offering integrated product-service solutions are summarized in this section. Martinez et al. [START_REF] Martinez | Challenges in transforming manufacturing organisations into product-service providers[END_REF] categorize the following challenges faced by a company while moving from being a product oriented organization to a product-service oriented organization: embedded product-service culture, delivery of integrated offering, internal processes and capabilities, strategic alignment, and supplier relationships. In continuation with this list, Stargård and Hassan [START_REF] Stargård | The Success Factors of PSS Development: A Transformation of Traditional Manufacturing Companies[END_REF] have identified comprehensive list of success factors to be considered in PSS development.

The identified factors are senior management clarification of strategic intent, cultural change management, teamwork culture, internal communication mechanisms, external communication mechanism, customer relationship, motivating breakthrough ideas, project core competency, cross-functional collaboration, cross-functional development, allocation of resources, training and education, knowledge management, customer satisfaction data, risk management, product positioning, portfolio of product opportunities, product functional content, knowledge of market potential, product service processes, product environment, development process, responsibilities of team members, concurrent development, internal task coordination, organizational readiness for sales, internal marketing and external marketing.

Durugbo [START_REF] Durugbo | Competitive product-service systems: lessons from a multicase study[END_REF] finds that technical requirements of competitive PSSs are best fulfilled in work systems that emphasize individual timeliness/ buy-ins, synchronous communications managed by strategic roles and tie-ins offered by service contracts. Baines [START_REF] Baines | Servitization impact study: How UK based manufacturing organisations are transforming themselves to compete through advanced services[END_REF] summarized that a shift in culture, contracting structures, governance, risk management mechanisms and financing systems will allow companies to deliver services while building their capabilities to innovate technology along the way. They noted that initial cost savings, on-going cost reduction, transfer of fixed costs into predictable variable costs, improved asset security and improved asset reliability are the priority factors for customers to be attracted in product-service offers. Vasantha et al. [START_REF] Vasantha | A manufacturing framework for capability-based product-service systems design[END_REF] noted that the critical productivity factors that define industrial product-service systems are performance, availability and reliability.

Ng et al. [START_REF] Ng | Towards A Core Integrative Framework For Complex Engineering Service Systems[END_REF] proposed the three transformations needed for developing complex engineering service systems, namely: transform materials and equipment, transform information and transform people. For life cycle design, Masood et al. [START_REF] Masood | Integrating design attributes, knowledge and uncertainty in aerospace sector[END_REF] classify uncertainties into the dimensions of engineering uncertainty, operation uncertainty, affordability uncertainty, commercial uncertainty, performance uncertainty and training uncertainty. Nordin and Servadio [START_REF] Nordin | Critical issues during servitization: an in-depth case study[END_REF] identified critical issues during servitization using three main conceptual dimensions the organizational dimension (internal), the procedural dimension (hybrid), and the relational dimension (external). They studied these dimensions in terms of separating product unit from service units, shifting the manufacturer's mind-set, developing formal processes and procedures, generating new competences in terms of organizational and operational capabilities, creating strategic partnerships with suppliers, and to engaging with customer through learning interactions.

Although common themes such as internal processes, external processes, product and service characteristics and business elements are emerging as overlapped themes, the list of sub-factors within these themes are expanding and only few overlapping factors could be identified between studies. The primary reason for this divergence could be due to different market domains covered in every study. To bring convergence there is a need for comprehensive cross-sectorial case studies. However, many industrial sectors are not yet studied to undertake cross-sectorial case studies. One of the industries not yet covered is laser cutting manufacturing industry which is the focus of this paper. We aim to study the factors influencing to develop PSS offers in this industrial sector.

Research Questions and Methodology

In this paper, we aim to present answers for the following research questions:

• What is the current structure and level of servitization in laser industries?

• What are the implications of higher levels of servitization for the various stakeholders of the industry? • What are the opportunities to develop and deliver higher levels of servitization? These questions were answered by undertaking semi-structured interviews with managers of laser system manufacturer and laser job shops. Interviews were conducted with three laser job shop managers and two senior sales people of laser system manufacturers. In this paper, the core information collected from these interviews is summarized and presented. Figure 1 explains the network of three stakeholders, and their roles in the network. Primarily, Laser system integrator sells laser system to Laser job shop and End product manufacturer. End product manufacturer either outsource laser cutting jobs to Laser job shop or buy Laser system if the volume of laser cutting production is very high and have required capabilities to do laser cutting jobs themselves. End product manufacturer will post an open request for quotation across laser job shops if they decided to go with the outsourcing option.

The key criteria chosen in outsourcing laser cutting jobs are delivery time and price. So Laser job shop who proposes quicker time with lesser price will mostly likely to win the order. The next section answer the above mentioned research questions in the respective order.

Current structure and level of servitization in laser industries

Table 1 summarizes the current servitization level between Laser job shop and System integrator, and Laser job shop and End product manufacturer based on the criteria summarized by Martinez et al. [START_REF] Martinez | Challenges in transforming manufacturing organisations into product-service providers[END_REF]. Both these relationships have low level of servitization. The primary reason for this low level of servitization is that there is no relationship established between these stakeholders. This environment is primarily price-driven and there is no trust established between them. Although each outsourced job from End product manufacturer is driven by pay-perjob basis, and each job is different and manufacturing operation needs to be optimized for each setting, there is no relationship exist between Laser job shop and End product manufacturer. The reason for this scenario is that laser cutting operation is now commoditized and it is no longer considered novel to improve manufacturing efficiency through laser operations.

Implications of higher levels of servitization

The common business offering proposed by System integrator is selling laser system with two years warranty. System integrators have less competitive impetus to propose novel business offerings because this market segment is predominately dominated by only two integrators, and also laser job shops segment comprises only small percentage of their total business. System integrator also argues that since this market is price driven, there is no reward for faster service response time. However, System integrator do offers five year warranty replacement and buy-back option but without any uptime guarantee. Table 2 provides the rationale mentioned for choosing the particular business offerings than others. delayed and improper fault reporting.

Opportunities to develop and deliver higher levels of servitization

The primary question emerges from this laser system network study is that, how can price-driven scenarios could be changed to relationship and trust driven industry? To find answer for this question, strengths and weaknesses existing within this network are analyzed. The strengths of laser job shop are processing quickly on product design data, optimizing material usages, and efficient machine operation and material handling. The weaknesses are not having trained machine operators, lack resources to support data management for remote monitoring devices, and in remote location for some of their customers. The strengths of system integrator are services provided are generally excellent (e.g. next day service engineer visit along with well-equipped spare parts required, well networked service operations throughout the UK), and system failures are tracked well through error logs and failure causes identified 60% of the time. The weaknesses are less transparency in service operations leading to doubts for higher price for simple failure (e.g. replacing whole sub-system rather than repairing the particular component), and not well-versed with establishing suitable leasing contract.

End product manufacturer is a key stakeholder in this network and any system network modification should consider their business criteria as critical factors. Fast delivery time, less price, high quality, and local and friendly stakeholders are the critical requirements for End product manufacturer. Although End product manufacturer needs are important, the proposed solution should be win-win for all stakeholders. A new business model could be developed considering the three forms of customer engagement noted by Baines [START_REF] Baines | Servitization impact study: How UK based manufacturing organisations are transforming themselves to compete through advanced services[END_REF]: customers who want to do it themselves; customers who want us to do it with them; and customers who want us to do it for them. Considering these factors and engagement modes, a new business model is proposed which intends to build relationships between stakeholders. The proposed higher level of business model intends to build on strengths of each stakeholder and eliminate weakness though transfer of capabilities and resources. In this scenario the engagement mode "customers who want us to do it with them" is chosen because it avoids elimination of stakeholders in the network. Figure 2 illustrates the proposed higher level of servitization solution.

In the proposed model, Laser job shop move closer to a large and valued customer and provide the operators to run the surrounding laser cutting processes. The infrastructure and space could be provided by End product manufacturer. The laser system could be supplied by System integrator on a pay-per-use basis provided that a minimum payment is guaranteed and that risks can be finely calculated and shared between stakeholders. In this way, each stakeholder would share its expertise and resources. This servitized business model would cultivate long term relationships and ensure very competitive rates and immediacy of delivery for guaranteed volume of business. The strengths of this proposed business model are it takes into account the core capabilities of each stakeholder, and eliminates the drawbacks in the current laser system network. Similar kind of business model is noted by Baines [START_REF] Baines | Servitization impact study: How UK based manufacturing organisations are transforming themselves to compete through advanced services[END_REF] for emergent facilities practice where facilities are located in close physically proximity to the customers operations. However, the limitations of this model are it could lead to monopoly in Laser job shops and whiplash reduction in job shops, and also unassured whether service transparency (knowledge know-how) could be established by this network.

Discussion and Conclusion

The foremost observation from this study is that "Pay-per-Use" business model and customization should not be considered as de-facto standards for higher level servitization model. The de-facto factor for higher level servitization model should be establishing long lasting relationships with stakeholders and delivering value-in-use to end customers. The list of factors that primarily influences to downgrade pay-per-use business model is tabulated in Table 3.

Fig. 1 .

 1 Fig. 1. Illustration of network between three stakeholders

Fig. 2 .

 2 Fig. 2. A proposed new servitization model for the laser system network

Table 1 .

 1 Identification of Laser Network's servitization level

	Level of Servitization	Laser job shop and	Laser job shop and End
		System integrator	product manufacturer
	Value Basis of	Mostly transactional based Completely transactional
	Activity		based
	Primary Role of	Primarily asset ownership Pay-per-use basis
	Assets
	Offering Type	Offered as Laser system	Price driven environment
		plus peripheral services
	Production strategy	Mass production	Mass customization
	Offering type Low Servitization	Low Servitization

Table 2 .

 2 Rationale for (not) choosing the particular level of Product-Service offers

	Product-oriented	Use-Oriented	Result-oriented
	Most of Laser job	Only one of the four laser job	Pay-per-use laser system
	shops prefer to buy	shops interviewed mentioned	model is not currently
	and	own	laser	that they are leasing the	offered	by	System
	system		with	machine rather than purchasing.	integrator. It was used
	specific period of		initially only for market
	warranty.			penetration.
	Although	good	Good residual value of the	This offering is avoided
	residual value of	machine provides accuracy, less	by Laser job shops itself
	laser system is	downtime, reliable, updated	because they perceived
	expected only up to	technology if any, and most	that although it reduces
	5-7 years, it can be	importantly provides predicable	initial investment, it has
	used as long as 10-	running cost.	high financial risk and
	12 years.			could be more expensive
					in longer run.
	No		major	Reduce initial major investment	Also Laser job shops are
	technology change	cost and ensure smooth cash	nervous about this offering
	is expected in near	flow. Upgrading old system is	because they believe that
	future.			not a cost effective solution.	System integrator could
					directly interact with their
					customers leading to their
					elimination	in	the
					network.
	No restriction on	But placing a proper leasing	System	integrator
	Laser		system	contract is a challenge. Various	apprehension	about
	usages		and	terms and conditions did not	operator's misuse, and

Table 3 .

 3 Critical factors influencing to develop higher level of servitization Performance levels are achieved to required needs and drastic technology changes not expected soon. Product life is longer. Product upgrades are considered infeasible.Service maturityServices are advanced with immediate fault registration and causes identification. Advanced services are not appropriately rewarded. However transparency is a critical issue.

	Characteristics	Situation
	Value definition	Price driven environment and not trust
	Interrelationships	Transactional basis rather than relationship
	Product maturity

Market competition

Contradiction of competition between stakeholders. Laser job shops environment is highly competitive whereas System integrator environment is dominated by two key players.

Consumables usage

Many restrictions imposed on laser system consumables usage such as to use only premium gases. Business contract Establishing suitable terms and conditions between stakeholders are challenging.

Capabilities

Mismatch perceived with skills and resources such as operator's skills.

Although with above mentioned difficulties, it is possible to develop higher servitization model if focus placed on predictable cost and enables smooth cash flow for all stakeholders. The following servitization study on this sector will focus on possible influences of technology substitution on laser system by additive manufacturing.