Majid Sorouri
email: majidsorouri@srbiau.ac.ir

Valeriy Vyatkin
email: vyatkin@ieee.org

Intelligent Product and Mechatronic Software Components Facilitating Mass Customization in Collaborative Manufacturing Systems

Keywords: IEC 61499, mass customization, collaborative production systems

The intention of this research is to propose a uniform architecture for control software design of collaborative manufacturing systems. It introduces software components known as Modular, Intelligent, and Real-time Agents (MIRAs) that represent both products (C-MIRA) and mechatronic components (O-MIRAs) in a production system. C-MIRAs are in constant interaction with customers and operators through human machine interfaces (HMIs), and are responsible for transforming products from concepts up to full realization of them. It is demonstrated that desired services of a number of machines and mechatronic components can be dynamically allocated to a C-MIRA using a fully decentralized scheduling and operation control. This architecture also envisages the machines' control to be composed of a set of modular software components, with standardized interfaces. This makes them intuitive and easy to install, to create the desired behavior for collaborative manufacturing systems. A simplified food production case study, whose control is synthesized using the proposed approach, is chosen as an illustrative example for the proposed methodology.

Introduction

Mass customization is exceedingly beneficial for both customers and manufacturers, as on the one hand, customers can personalize products according to their preferences. On the other hand, manufacturers can enhance their customer satisfaction, and worry less about relying on marketing predictions and dealing with a large amount of stock. Up to the present day, manufacturing factories have been using fixed production lines; as a result, any change in the plant layout poses significant costs and efforts for adoption of the existing production system into the desired condition. Therefore, with the current need for individual product customization, the achievement of the ability to rapidly design, control and reconfigure manufacturing systems is inevitable, and manufacturing enterprises are continuously striving to address this need by implementing collaborative manufacturing systems.

Research Background

In the past two decades various research approaches have promoted the notion of production through collaboration among main role players in manufacturing industries such as a wide range of devices, resources, machines and robots. In this section, a number of recent practices are mentioned.

Merdan et al. [START_REF] Merdan | Application of a communication interface between agents and the low level control[END_REF], look at the possibility of matching a Machine Agent (MA) to each physical component and applying it in a production line where, for instance, each conveyor, diverter and pallet is represented by an agent and transportation of a product will be achieved through collaboration of the agents. Gouyon et al. [START_REF] Gouyon | A product-driven reconfigurable control for shop floor systems[END_REF] proposed a product-driven approach in which product plays a pivotal role in manufacturing rationale. This method is mainly based on the collaboration between product controllers and resource controllers, through exchanging requests (by product controllers) and reports (by resource controllers). Simao et al. present a holonic control solution in which causal knowledge is embedded as individual rules in Rule holons. They receive facts from Resource holons and decide on the appropriate actions to be taken. This method also resembles the product-driven approach, in that the Rule holons are in charge of regulating the collaboration between Product holons and Resource holons [START_REF] Simao | Holonic Control Metamodel[END_REF].

A comprehensive review of the previous implementations of collaborative manufacturing systems, along with some of the future challenges ahead of their implementation is provided in [START_REF] Vrba | Rockwell Automation's Holonic and Multiagent Control Systems Compendium[END_REF][START_REF] Leitao | Past, Present, and Future of Industrial Agent Applications[END_REF][START_REF] Shen | Applications of agent-based systems in intelligent manufacturing: An updated review[END_REF][START_REF] Leitão | Agent-based distributed manufacturing control: A state-of-the-art survey[END_REF]. Although these methods have overcome many of the industrial concerns such as decentralization of control as well as increasing intelligence and flexibility that are essential for mass customization, due to the inherent complexity of such systems their industrial applications are still very limited.

The IEC 61499 Standard Facilitating Distributed Control of Production Systems

The IEC 61499 is an open standard for design of distributed control systems [START_REF] Vyatkin | IEC 61499 as Enabler of Distributed and Intelligent Automation: Stateof-the-Art Review[END_REF]. This architecture allows encapsulating intelligence into structured and modularized control logic blocks known as Function Blocks (FB) and distributing them into various control devices. The IEC 61499 FB software architecture is used as an implementation platform for this research and the key features of the proposed approach are: reusability, compatibility and autonomy of modular software components, which require limited dependence on human intervention. The results of this research add design flexibility to collaborative manufacturing systems while minimizing their costs and efforts.

IMC Concept

The IMC architecture was originally proposed in [START_REF] Vyatkin | Intelligent mechatronic components: control system engineering using an open distributed architecture[END_REF] and then formally defined in [START_REF] Pang | Model-Driven Development of Distributed Automation Intelligence with IEC 61499[END_REF] to facilitate developing modular and reusable control software for industrial automation systems. The concept of IMC is to encapsulate hardware and software models of mechatronic devices into a single-design artefact. Similar to FB concept, an IMC can be viewed as a black box that is only accessible by its interface [START_REF] Zoitl | Real-time execusion for IEC 61499[END_REF]. Simple IMCs can be hierarchically composed to form more complex ones. The final automation system is thereby a network of collaborating IMCs. By generalizing the IMC approach, the bottom-up control synthesis of machines, and at a higher level, production systems, becomes conceivable.

MIRA Design Approach

MIRA follows the concepts of IMCs along with Intelligent Product Software components (IPSC) and elaborates on three expected characteristics from them, namely Modularity, Intelligence and Real-Time behaviour in a collaborative network. It certainly inherits some of its features from current approaches. However, it enhances the simplicity of the control system design, and makes the solution more engineer/operator friendly. This design approach is applicable to a wide range of production systems, regardless of their size: from a small automated shop which receives its orders directly from customers, to large manufacturing systems, where all the information, regarding production rules and equipment, is provided from the enterprise level. The MIRA approach for control software design of customized production system has been described in [START_REF] Sorouri | MIRA: Enabler of Mass Customization through Agent-Based Development of Intelligent Manufacturing Systems[END_REF][START_REF] Sorouri | Software Composition and Distributed Operation Scheduling in Modular Automated Machines[END_REF] ,and in this paper the collaboration aspect of MIRAs is elaborated. MIRA considers a trio of main role players in a collaborative manufacturing system: Human, Operator (O) and Client (C) MIRA, and particular tasks are allocated to each of them. MIRAs can either participate individually or as a group in a manufacturing system. Figure 1 shows an example of a bottom-up approach that is applied in a simple food production system.

Human

Humans can provide a deeper knowledge of the problem domain that is not already captured by the agents. They adapt the system if problem specifications alter over time [START_REF] Rachlin | A-Teams: An Agent Architecture for Optimization and Decision-Support[END_REF]. Humans can also play a supervisory role, and, whenever needed, overrule MIRAs' decisions, as they are given a higher priority. In addition to the above roles, a human can act as an operator/technician supporting the system with different activities (i.e. collaboration, maintenance, supplying raw material, and so on).

O-MIRA

O-MIRA represents a machine/robot in a manufacturing system and consists of one or a group of IMCs in a bottom-up approach. An O-MIRA includes sensors, actuators, software components, controllers and power sources. The layout of a manufacturing plant follows the physical structure of its constituent O-MIRAs. Each O-MIRA it is able to be rapidly plugged into an existing manufacturing system. However, it is vital for every two or more cooperating O-MIRAs to ensure that both their physical and software components are compatible with each other. The compatibility check between two O-MIRAs can be either done manually or determined through their communication and decision-making. O-MIRAs receive tasks from Client MIRAs (described below) and in return, inform them about their availability and task fulfilment. An O-MIRA may be capable of serving several C-MIRAs simultaneously and also can respond to their requests differently based on its operation capacity. For instance, a machine may be available to handle a few C-MIRA requests and send a "Ready" message to them, but as it reaches its operation capacity, it may temporarily reject other requests.

A task that is received by an O-MIRA is normally deconstructed into numerous subtasks and is performed through collaboration with the constituent IMCs. An O-MIRA is also responsible for maintaining human safety according to its predefined vendor specifications. If an O-MIRA is considered hazardous, then sensors to detect human presence, and procedures on safety maintenance, must be provided.

C-MIRA

C-MIRA is an intelligent product software component that has a thorough knowledge of a product including: raw materials; cost; due date; order quantity; recipe (manufacturing process); machinery that is capable of producing its components, and so forth. C-MIRA receives an order from a customer interface and breaks it down into a sequence of operations. Then it requests those operations from O-MIRAs. When a C-MIRA receives information about the available O-MIRAs, if there is more than one O-MIRA capable of performing a task, then the C-MIRA selects one among others, based on different criteria which are either directly identified by customers or have been received from the enterprise level. Some of the criteria by which O-MIRAs can be distinguished and the manufacturing process can be optimised include: operation cost; transportation distance; operation performance, and bottleneck avoidance. In cases where there are multiple criteria that must be considered for determining the optimum O-MIRAs, then multi-variable optimization techniques as described in [START_REF] Lim | An integrated agent-based approach for responsive control of manufacturing resources[END_REF] can be applied by a C-MIRA to precisely determine the best solution. After the production is completed, C-MIRA sends a completion report to the customer interface.

Direct communication between C and O-MIRAs is a convenient solution for relatively small manufacturing systems. However, in larger applications, O-MIRAs with similar functionalities can be grouped together and managed by a Coordinator O-MIRAs to minimize the number of interactions among MIRAs. Coordinators can receive requests from C-MIRAs instead of individual O-MIRAs, and manage operations among them.

Knowledge Representation of MIRAs

The way MIRAs' knowledge is shaped for manufacturing is similar to IMCs and is based on the STEP method [START_REF] Sorouri | MIRA: Enabler of Mass Customization through Agent-Based Development of Intelligent Manufacturing Systems[END_REF] as illustrated in Figure 2. Sc is provided to a C-MIRA by product designers who define a detailed specification of the production by an orderly set of operations (or recipe) that a product has to undergo to be produced [START_REF] Gouyon | A product-driven reconfigurable control for shop floor systems[END_REF]. Tc consists of the knowledge that specifies which task (order) is to be managed by an O-MIRA. Tc is provided to C-MIRA by the enterprise level or through a customer interface. Ec includes the information that C-MIRAs receive from O-MIRAs regarding their capabilities, availabilities and locations to be able to navigate the physical product through several production stations. Furthermore, a C-MIRA has to negotiate with other C-MIRAs to sort out order priorities. For instance, if a production strategy is on a first-come, first-served basis, the second C-MIRA has to communicate (i.e. through a Block-Permit approach) with the first O-MIRA to be able to access resources for production.

So is an integration of the characteristics and functionalities of the IMCs that construct an O-MIRA. To is provided by a C-MIRA and identifies which task an O-MIRA has to perform for an order. Next, the O-MIRAs' constituent IMCs will break it down into detailed tasks to be accomplished in a distributed way. For example, if a "placing work piece" task is assigned to a pick-and-place robot, it creates a set of detailed tasks (for example, extend/retract cylinder and turn vacuum on/off) to be performed by its horizontal and vertical cylinders and vacuum unit. For a Transport O-MIRA, To will be the source and destination of the product at each stage, and the constituent conveyors will collaborate to transport the product. During the manufacturing process, if an interruption occurs because of machinery failure, a C-MIRA will allocate the task to the next available O-MIRA. If no alternative O-MIRA is available, the C-MIRA will halt the operation to avoid product waste. Eo includes: O-MIRAs' location; raw materials status; safety (e.g. whether a human is present); the other MIRAs it is collaborating with, and so forth. Some of this information (such as positions) has to be provided manually by the process control engineer because they are specific to a manufacturing environment; others will be gathered through negotiation with other O-MIRAs.

A Case Study

To demonstrate MIRAs' collaboration in a manufacturing environment, a simplified case study of an automated and customized Ice Cream Production System (ICPS) is selected for implementation at a laboratory scale, using available equipment in the Industrial Informatics lab at the University of Auckland. The list of raw materials used to make customised ICs includes:

-Two IC flavours: vanilla and chocolate IC cups (IC makers and cup fillers are not included in the case study); -IC lid; -White cream; -Two sprinkle colours, and -Six types of IC sauces represented by six colours.

Ice Cream Controller (C-MIRA)

A variety of toppings enables customers to choose their desired IC among various combinations. Customers' choices range from the simplest (and the cheapest) IC, which consists of an IC cup, to the most expensive IC, which includes three toppings (that is, cream and a choice of sauce and sprinkle). A customer order is received through a graphic user interface and is fed into a C-MIRA as an IC production controller. A C-MIRA acts as an intelligent product, in the sense that it contains a thorough representation of the IC recipe. It negotiates with the available devices that perform the required production operations. This negotiation will result in the creation of specific solution/s (routings and sequences) for the production of each IC order, based on various production conditions, such as particular order requirements, the availability of certain devices, and their locations (Figure 3).

Mechatronic Devices (O-MIRAs)

O-MIRAs intermittently advertise their operation status via a Boolean variable "Ready" (true when it is ready, false when it is not ready), to the C-MIRA, operator interface and the O-MIRAs with which they are collaborating.

There are two types of devices: Stationary and Portable. Stationary devices, which are assumed to be permanently available in the production process, include:

-Two sprinkle dispensers; -A rotary sauce dispenser; -A cream dispenser; -A rotary table, and -A group of conveyors for transportation (C), comprising four bi-directional conveyors (C1-C4) and two one-way conveyors (C5 and C6). There are six positions on the conveyors (identified with blue squares P1-P6 in Figure 6 a) that have optical sensors, allowing them to be used in any order as entry or exit connection points for the other portable devices that are depicted in Figure 6 including: -A storing station : to store ready ICs to be delivered to customers (last production stage); -A pick-and-place device to place lids on IC cups; -Two semi-rotary loaders with stack magazines, each of which supplies an IC flavour. In this case study it is assumed that these two IC loaders have priority over the dual IC loader in supplying IC. If they are unavailable (that is, either. faulty or out of IC cups), the C-MIRA will send a request to the handling station, and -A handling station that has a pick-and-place robot, along with two sliders, to supply both IC flavours.

Transport System

Conveyors allow IC cups, as raw materials for this production system, to be transferred from one station to another to receive the desired IC dressings, and finally to guide them to the storing station. Although each conveyor operates independently, communication between them is necessary to direct the IC to the right station. Each conveyor is equipped with one or more photo eye sensors (PS) to identify the presence of ICs at particular locations. It is assumed that the travel time for ICs between every two adjacent photo eye sensors is measured in advance by the control engineer and provided to the conveyor O-MIRA. In addition, some conveyors are equipped with diverters (D) to pass ICs to their attached conveyor.

Apart from the inherent flexibility of choice that is provided to customers in selecting ICs on the production side, the intended reconfigurability of the system allows the five portable devices to be freely located in any order around the fixed conveyor network and be connected to any of the entry/exit points. The through beam (photo eye) sensors mounted underneath the connection points allows the transport system to detect a portable device that is connected to its connection point. Providing the source and destination locations of an IC to the Transport O-MIRA enables it to calculate the travel time between two stations through possible routes and chose the fastest (and the shortest) path.

Customer and Operator HMIs

The customer interface gives customers multiple options to customize the IC to their preference. The customer has the choice to select between two flavours and a number of dressings (Figure 5). This information is then sent to the C-MIRA and based on that, the O-MIRAs will operate. The operator interface displays all the related production information to the operator. All HMI FBs are executed on a virtual PLC on a PC. Similar to other controllers, a virtual PLC communicates with other controllers through standard TCP/IP communication.

Control Design of O-MIRAs

In this case study, C-MIRAs are served on a first-come, first-served basis; however, in general, C-MIRAs may compete for resources based on their predefined priorities. In this approach, as is expected in agent-based manufacturing systems, each mechatronic component has only a minimal understanding of the whole system operations. For instance, an IC loader has no information about how many topping dispensers are available at the plant, or a conveyor does not know about the toppings that the IC may receive. The type of object (e.g. an IC or a metal work piece) that a conveyor is carrying is not important, so long as that object does not violate its predefined self-perception (the capability of carrying objects up to a certain size and weight). Therefore, decision making is systematically distributed across all IC production devices,' and each of the devices will behave autonomously.

Figure 6 shows a configuration of an ICPS and an example of how C-and O-MIRAs exchange messages in order to make a vanilla IC with cream topping. First, the user places their order through the user HMI, and all O-MIRAs inform the C-MIRA of their positions and readiness for operation. Next, C-MIRA sends a set of separate requests to O-MIRAs according to its recipe, and receives their report (through Merger FBs) after each task's completion. Meanwhile the adjacent O-MIRAs, whose concurrent operation is not allowed, exchange Block-Permit messages to avoid conflict. For example, once an IC loader is placing an IC on a conveyor, it blocks the conveyor operation to avoid it being used by other C-MIRAs. Similarly once the cream dispenser is operating, the rotary table must not rotate. Finally once the last O-MIRA (storing station) has accomplished its task and reported to the C-MIRA, the C-MIRA will report on the IC production to the user interface.

As it is illustrated in Figure 6 b, the total time taken for production of the IC order can be calculated as:

TTot= OM where TTot= Total production time of an IC order t(i)OM= Operation time of an O-MIRA n= Number of O-MIRAs in the production including transport system i= 1, 2… n Therefore, the total production time for the IC with cream topping will be: t ( PT) t= t (VL) + t (CD) + t (LL) + t (SS) + t (TS) + t (RT) where Total Transport Time: t (TS) = t (TS1) + t (TS2) + t (TS3) Total Rotary Table Operation time: t (RT) = t (RT1) + t (RT2) In general, communication among O-MIRAs results in increasing the throughput of the system. For, instance, while the first IC is receiving cream topping at the cream station, the second IC can be loaded on the C4 conveyor and transferred to the turntable. However, handling multiple IC orders simultaneously introduces the risk of collision. This situation is avoided by the conveyor system, through a permit-block communication technique between O-MIRAs. To this end, the conveyor controllers (as well as other devices) periodically advertise their availability (with a Ready or Not Ready message), and, based on their availability, issue permit-block messages among themselves to prevent others from overloading them. Through this method, each device will only handle one IC (or other objects) at a time.

Apart from O-MIRAs' autonomous behaviour, their other characteristic is that devices with similar components and functionalities will have identical control modules. For instance, the two single IC loaders use two instances of an identical FB, regardless of being placed in different locations within the production system. Conveyors are another example of the use of modular and identical software components.

The ICs can be observed and tracked by 14 photo eye sensors at various positions on the transport system. Distributed scheduling among conveyors is similar to the methodology reported in [START_REF] Sorouri | Software Composition and Distributed Operation Scheduling in Modular Automated Machines[END_REF] for scheduling in modular automated machines. At first, the cylinder which contains the source node will start the scheduling procedure by searching for destination node. If destination node also exists in the same conveyor, then completion task will be sent to other conveyors and depending on the position of destination node with respect to the source node, the conveyor may chose forward (FW) or Backward (BW) movement to transfer an IC. However, if the destination node is located in other conveyors, the conveyor which has the source node firstly assumes its direction to be FW and based on that, sends requests (one at a time) to the output nodes along the way. The output node can be the conveyor which is connected to the end of this conveyor, or the one which is attached to its middle nodes and receive IC by diverter's actuations. Such algorithm will be followed by the consequent conveyors until the destination becomes reachable and then the "Scheduling Success" message will be broadcasted from the last conveyor which contains the destination node to the previous conveyor and cascaded to the first conveyor. If FW assumption for the first conveyor does not lead to a successful transportation path, the conveyor will again assume its movement direction to be BW and asks upstream output nodes to find a path to destination node. This procedure will enable the conveyors to find a solution to transfer an IC between two of the eight locations identified on the conveyors (i.e. positions 1-6). After the scheduling process is completed and the required actuators (conveyors and diverters) for IC transportation are identified, the conveyors involved in operation will become unavailable to other C-MIRA's and each conveyor will enable its actuators for operation. When the photo eye sensor at the destination node detects the IC, the operation is complete and conveyors will be ready for the next transportation task.

Control Hardware and Software Design Tool

The control hardware utilized for control of the production system consists of 12 Adam PLCs from Advantech Company. The PLCs control every conveyor, portable and stationary device used in the ICPS (Figure 7). The whole software, including control and visualization, is implemented in IDC Builder environment by NxtControl company as one of the compliant tools to the IEC 61499 standard [16]. The entire control software was distributed and deployed to various hardware configurations, and in each case, the production system had identical performance.

Fault Tolerance

One of the notable benefits of the collaborative decision making when using MIRA is that it eliminates any unnecessary critical point and the system can cope with faults without human intervention. If an O-MIRA is unavailable, the C-MIRA will send a request to the next available O-MIRA.

The ICPS implementation was tested under the following fault scenarios:

-The vanilla IC loader was unplugged (representing a fault condition) and became unavailable, while the dual loader station (VC) received the command from the IC-Order FB and took charge of loading an IC. -The cream dispenser was unplugged. Since there was no counterpart for that in the ICPS, the operation did not proceed, to avoid wasting IC. -Conveyor 3 was unplugged (representing a fault condition) while the IC was supposed to be transferred from the position 5to the position No.2. The rerouted transportation path is illustrated in Figure 8. Among the three examined fault scenarios, in the first and the third cases, because the ICPS had other production alternatives, was able to successfully maintain its operation and produce the desired ICs.

Discussion

Before the design and implementation of ICPS, the same machinery had been used in a similar production application and for the control software development; the IEC 61499 FBs had been used. However, because of code's centralized nature, it was not feasible to reconfigure the production layout and add more components to it. Considering the shortcomings of the previous development, the ICPS control design was undertaken, based on the MIRA approach, which allowed reuse of devices in ICPS and thorough reconfiguration of the system. The new collaborative approach resulted in a significant reduction in control development time when compared with the previous implementation and the achievements will be more meaningful, bearing in mind that this method eliminates further development time in future expansions.

Conclusions

Future manufacturing will not just be concerned with satisfying a customer's straightforward requirements, but rather making their more ambitious aspirations come true. As an extension of the IMC design concept, MIRA was introduced at the manufacturing level, which represented intelligent products and machine controllers that can cooperate with one another without human intervention to achieve mass customization in manufacturing systems. Furthermore, MIRA architecture was studied and evaluated on a simulated food production case study in a laboratory environment.

Figure 1 .

 1 Figure 1. An example of a bottom-up approach for the design and implementation of a food production system.

Figure 2 .

 2 Figure 2. Knowledge representation of C-MIRA and O-MIRA based on STEP approach in manufacturing systems. The Knowledge of C-MIRAs and O-MIRAs can be defined as: Pc: {Sc, Tc, Ec} and Po:{So, To, Eo}, where Pc: C-MIRA's knowledge perception; Sc: C-MIRA's self-perception; Tc: C-MIRA's task-perception; Ec: C-MIRA's environment-perception;

Figure 3 .

 3 Figure 3. IC production FB (C-MIRA) and IC production flowchart.

Figure 4

 4 Figure 4 shows four C-MIRAs (each representing one IC production controller) that are populated in the IC control application. IC controllers receive orders from the customer HMI and communicate with O-MIRAs through Merger FBs. Each Merger FB acts as a medium between the C and O-MIRAs. It is associated with one O-MIRA and receives commands from C-MIRAs, then passes them to an O-MIRA and after the task completion, forwards the O-MIRA's feedback to the C-MIRA which had sent the command.

Figure 4 .

 4 Figure 4. Operator HMI, IC Controller FBs and Merger FBs populated in IC production control application.

Figure 5 .

 5 Figure 5. Customer FB and HMI by which customers can select the desired IC flavours and dressings and be informed about the production progress.

Figure 6 .

 6 Figure 6. a) A configuration of O-MIRAs in ICPS, b) message exchange among C and O MIRAs for producing a vanilla IC with cream topping

Figure 7 .

 7 Figure 7. Collaboration among Adam Controllers through the network.

Figure 8 .

 8 Figure 8. Transportation paths explored in distributed scheduling between conveyors to move an IC from position 5 to position 2 while conveyor 3 is unplugged.


Sebastian Scholze
email: scholze@atb-bremen.de

Ana Correia
email: correia@atb-bremen.de

Dragan Stokic
email: dragan@atb-bremen.de

Kevin Nagorny
email: nagorny@atb-bremen.de

Philipp Spindler
email: spindler@atb-bremen.de

Tools for Human-Product Collaborative Development of Intelligent Product Service Systems

Keywords: Intelligent Products, Collaborative Development, Product Service System, Cyber Physical Features, Collaborative Network

Intelligent products, having cyber physical features, are best candidates for building Intelligent Product Service Systems (IPSS), in which integrated products and services provide a higher level of intelligence. Such IPSS may actively provide feedback on their use, which in turn may support the development of new IPSS. The objective is to develop a set of tools to establish a Collaborative Network, where both human actors and products themselves can collaborate and contribute to the development of such IPSS. The tools support involvement of various stakeholders within the Collaborative Networks. Several tools, such as a tool to select sensors and intelligent features at the products, a tool to model context under which IPSS is used, as well as tools to provide feedback on the IPSS use are defined. The paper presents as well the application of the proposed concept in machine industry.

Introduction

Modern products include more and more cyber physical features as a basis for their intelligence. Cyber physical features allow to build various intelligent services encompassing such products to build for example Intelligent Product Service Systems (IPSS). IPSS provide a new quality of offers to customers as the products and services are integrated and built with a higher level of intelligence. Such systems can communicate and provide information within Collaborative Networks. Many Cyber Physical Products in manufacturing industry, such as vehicles, home appliances etc., are already used or can be used to build such IPSS. Modern machines are probably one of the most promising products to build IPSS.

Such IPSS are innovative results of the fourth industrial revolution [START_REF] Schwab | The Fourth Industrial Revolution: World Economic Forum[END_REF][START_REF] Nagorny | An Approach for Implementing ISA 95-Compliant Big Data Observation, Analysis and Diagnosis Features in Industry 4.0 Vision Following Manufacturing Systems[END_REF], as a collective term covering a number of modern technologies in manufacturing, automation and data exchange. The forth industrial revolution is 'a collective term for technologies and concepts of value chain organization' consisting of loosely coupled Cyber-Physical Systems (CPS) in an Internet of Things and Internet of Services [START_REF] Hermann | Design principles for Industrie 4.0 scenarios: a literature review[END_REF][START_REF]Was hinter Begriffen wie Industrie 4.0 steckt[END_REF][START_REF] Kagermann | Recommendations for Implementing the Strategic Initiative INDUSTRIE 4.0: Securing the Future of German Manufacturing Industry[END_REF][START_REF] Wermann | Impact of new ICT trends for the educational curriculum in the area of Industrial Automation and engineering[END_REF], it includes all resources needed for developing IPSS.

IPSS is an evolutionary step to smart manufacturing. Loosely coupled cyberphysical systems realize comprehensive cross-level and cross-domain collaboration and analyzation possibilities. Furthermore, in manufacturing environments such services improve the volatile and dynamic. This continuously rising ramification generates also a demand on Collaborative Development approaches to manage those future highly complex IPSS and to exploit new potentials.

IPSS, having the ability to communicate within Collaborative Networks, may actively contribute to the development of new IPSS or re-design of the existing ones. The objective of the research shown in this paper is to develop Collaborative Networks, comprising both humans and IPSS, whose aim is to (re-)develop IPSS. Within such networks, besides different stakeholders normally involved in the development of IPSS (product designer, process designers and shop-floor experts, service providers, various suppliers, as well as business customers, consumers etc.), IPSS can play an active role. They may pro-actively provide information about the product use and by this support the development of intelligent products and/or services. Such an approach requires new organization and definition of processes for IPSS development. However, collaborative environments and tools to support such Collaborative Networks in which human stakeholders and IPSS collaboratively "work" together on the development of IPSS are currently missing, based on the literature review carried out for this research.

The paper presents the vision of the human-product Collaborative Network and Environment, which shall support the operation of such Network and focuses upon three tools.. The paper also discusses the application of the approach in machine industry where development of IPSS is specifically complex. The paper focuses on the environment and tools while organizational aspects will be implicitly addressed

Overview of State of the Art

Cyber Physical Systems/Products: CPS are systems that include seamlessly integrated and closely interacting hardware (physical) and software (cyber) components sensing and to controlling (in real-time) the state of them and their environment. A high degree of complexity of such systems at a numerous spatial and temporal scale generate highly networked communications for integrating with their computational and physical components. As such CPS refer to information and communication systems (computing, communicating, actuating, sensing, etc.) seamless integrated in physical objects, interconnected through a unified network technology including the (Industrial) Internet (of Things/Services), providing several innovative applications based on digitized data and virtualized models, services and information. Therefore, CPS can also be referred to as emerging ubiquitous computing embedded cyber-physical applications that is bridging the physical and virtual worlds and share all kind of collaborative networks [START_REF] Colombo | Industrial Cloud-based Cyber-Physical Systems: The IMC-AESOP Approach[END_REF][START_REF] Sundmaeker | Vision and challenges for realising the Internet of Things[END_REF][START_REF]The Emerging Domain of Cooperating Objects[END_REF][START_REF]Road2CPS project[END_REF][START_REF] Colombo | A system of systems view on collaborative industrial automation[END_REF]. Product/Service-System (PSS): PSS has evolved in different geographic locations and has different motivations, e.g., one of the most spread concept is closely coupled sustainability and the reduction of environmental impact [START_REF] Pezzotta | A Service Engineering framework to design and assess an integrated product-service[END_REF]. There are many research communities that deal with similar concepts, e.g. services sciences [START_REF] Chesbrough | Open Business Models[END_REF].

Product-service bundles enable to extend the product's life-cycle. The concept of extended products [START_REF] Thoben | Emerging concepts in E-business and Extended Products[END_REF] provides a suitable model to conjunct products, product related services and the needs of users. The meta-product plays a decisive role in this process. The more a manufacturing enterprise is getting closer to a highest level of servitisation, the more the meta-product has knowledge about a service embedded in itself and the more it is becoming "service-aware", thus smarter. Products based on CPS are especially appropriate for building PSS, because they allow to combine the intelligence of the cyber physical products themselves with the intelligence of services built using sensors and intelligent features of the product, which in turn build higher level of system intelligence, namely Intelligent PSS (IPSS). Collaborative Development Environment: Collaborative Networks and Environments for complex service-enhanced products are subject of intensive research activities [START_REF] Camarinha-Matos | Cloud-based Collaboration Spaces for Enterprise Networks[END_REF], [START_REF] Camarinha-Matos | Supporting Collaborative Networks for Complex Service-Enhanced Products[END_REF]. One of the most important topics in research relevant for IPSS is related to generic software frameworks allowing developers to integrate services for products to create specific improved/extended industry solutions. Still promising approaches in this area are the "Common Object Request Broker Architecture (CORBA)", the Grid computing infrastructure (e.g. Globus, Legion and SNIPE) and the Common Component Architecture (CCA). This work has now led to the concept of Service Oriented Architecture, Cloud Computing etc. Some commercial collaborative systems are coming from CAD/CAM/PLM vendors which are more specific for the manufacturing industry and others are more tailored towards more general forms of collaboration (Webex, GoToMeeting, MS Messenger). Similarly, much research work has been done to develop virtual distributed environments resulting in advances in the area of collaborative virtual environment. Still a lot of work is needed to realize in real engineering settings collaborative workspaces covering the whole view of a product life cycle and intensive collaborative engagement of all the stakeholders that could lead to services, ecological products and related processes in production.

Many leading industries related to CAD are now offering in some form features for collaboration into their CAD / PLM products/services. The fundamental motivation for this evolution is to enable CAD / PLM products and services using remote teams to come together for their own product to work collaboratively to improve productivity (reduce costs and time consumption in product design and development while increasing quality). This indicates that major CAD/PLM vendors currently providing some forms of collaboration capabilities focused on collaboration related to their products so that one of the key limitations of their systems is the collaborative restriction on detailed CAD design but less on PSS. Although these systems tend to support some form of distant collaboration, they lack the ability to integrate various contributions from both humans and products that can expand the IPSS life cycle analysis involving multi-functional teams. Context Sensitivity: With recent advances in context-aware computing, an increasing demand for formal context modelling and reasoning techniques arises. To enable the development of context-aware applications in first step a well-designed Context Model (CM) is necessary. As context merges different sources of knowledge and associates knowledge to a user to guarantee a consistent understanding, context modelling is extensively studied within research of Knowledge Management.

Research related to context can be categorized in two areas: (1 st ) proactive contextbased delivery of knowledge, and (2 nd ) capturing and utilization of contextual knowledge. CMs enable the understanding of user's activities in relation to situational conditions for applications. Traditional techniques for context modelling include object oriented and key-value models, as well as ontological methods [START_REF] Strang | A Context Modeling Survey[END_REF]. Ontologies as base for the modelling of context is the most suitable approach for realizing context sensitive IPSS; context reasoning and context provisioning are some of the main topics for context extraction: how to inference high-level context information from low-level raw context data [START_REF] Stokic | Generic Self-Learning Context Sensitive Solution for Adaptive Manufacturing and Decision Making Systems[END_REF], [START_REF] Scholze | Context Awareness for Flexible Manufacturing Systems using Cyber Physical Approaches[END_REF]. Using context awareness in IPSS has not yet researched in a sufficient magnitude. In the case of IPSS the notion of context is related to capabilities of the equipment, process preferences of products and process features of devices and also environmental conditions. In this case the modelling of context shows a further challenge, as IPSS solutions are highly dynamic and working in environments which are distributed and often in a continuous change.

Vision of an IPSS Collaborative Environment

As the development of IPSS around products with CPS features requires involvement of all stakeholders from the whole value chain, there is a need for building innovative Collaborative Networks where collaboration paths can be extremely complex. The main idea of the research presented in this paper is to build Collaborative Networks, where besides human stakeholders, IPSS can be actively involved and where IPSS are able to actively provide information on use in real-time and conditions under which the products and services are used. By this, they actively support building new IPSS or extending/re-development existing ones.

Such human-product Collaborative Networks require an ICT Environment to support effective and collaborative development of IPSS as shown in Fig. 1. The Environment includes a range of engineering tools covering various life cycle phases of the IPSS development process starting from idea generation and conceptual phase up to the deployment and re-design phases based on the feedback obtained from customers and consumers [20]. The tools that may be included are e.g. simulation tool to simulate/predict the behavior on new IPSS and by this investigate different design options, Product Data Management/Product Lifecycle Management (PDM/PLM) tools for IPSS (i.e. IPSSDM/IPSSLM) which may in real time monitor the configuration of IPSS and allow for real-time reconfigurations of IPSS [START_REF] Müller | Tracing require-ments in PLM environments from use cases to design verification tasks[END_REF], tools for idea generation, tools for engineering of data mining algorithms for various services etc These tools allow for collaborative work of various human stakeholders in the network such as product designer, manufacturing process designer and shop floor leaders, service designer and providers, marketing experts, component designer from various suppliers (both hardware and software components), management from all stakeholders, as well as business customers, consumers etc. The main innovative characteristics of these tools are that they allow for active participation of the IPSS themselves. In many of these tools, IPSS actively provide data needed for the engineering tasks covered by the tools. The key rational behind the environment is that the IPSS may provide the inputs needed for the engineering tasks based on the requests from human actors involved in the development of IPSS. Furthermore, IPSS may pro-actively provide inputs whenever they observe that the engineering is dealing with tasks for which the IPSS products may provide additional data/knowledge. In the text to follow three tools typical for human-product collaboration in the Network, are briefly described. The key approach to integrate information flowing from various sources (IPSS products, human actors, different systems in supply chain, etc.) is semantical enrichment of all data using the agreed ontology for IPSS. This allows to effectively correlate data/knowledge from various sources. The visual analytics approach is planned to be applied for delivery of such integrated knowledge to various actors in the environment.

Tool to Select Sensors and Intelligent Features

The objective of this engineering tool is to support the design/development of IPSS by allowing a selection of sensors and diverse intelligent features, or propose to the designer which sensorial and smart feature/technology could be used in the product to allow for building of IPSS and which information on the designed product one could obtain from such smart systems/sensors. The sensors and intelligent features integrated in IPSS are sources of information which can be effectively (re-)used to build various services and/or new intelligent features. The tool offers to the designing team the list of sensors /features which are currently available at the product and which may be used for building diverse services. The selection may involve several stakeholders: product and service designer but also sensors suppliers etc. The tool uses a structured methodology for sensorial solutions for production industry based on a so-called Ambience Intelligence solutions reference model integrated in products with cyber-physical features [START_REF] Stokic | Ambient Intelligence in Manufacturing Industry: Control System Point of View[END_REF].

IPSS may provide in real time information on sensors and available smart features used in various configurations of the products and services and by this supports the designer to select the most appropriate ones to build new IPSS or extend the existing IPSS with the new services. It also may provide sets of data obtained by these sensors allowing to design new services and features.

The tool and method support the designing team in designing/selecting of sensors and other kinds of measurement systems and extended monitoring and services for decision support, may also support to improve eco efficiency during life cycle operation and product manufacturing, as well as to provide useful knowledge to enhance the design of processes and products in an ecological point of view. One critical RTD issue is for example, how to select the mentioned measurement systems or sensors with potential information on ecological impact relevant for (further) design of a product and which potentially support an optimum for eco-impact in life cycle operation and manufacturing of a product. The tool proposes to the designer which sensorial system/technology could be used in the product under design and which information on ecological impact of the designed product one could obtain from such sensorial systems.

Tool to Model Context of IPSS Use

IPSS offer to users' diverse opportunities to use products and services aiming to adjust both product and services to the specific customers' needs and specific conditions under which a user is using IPSS. In other words, the use of IPSS is context sensitive, i.e. the IPSS adjust its offer to the specific current context of the user. On the other hand, sensors integrated in IPSS provide information usable to extract context under which the products and services are currently used and by this allow for making IPSS context sensitive. Context sensitivity requires a definition of context model (CM). One of the tools in the IPSS Development Environment enables the user to model the context of the user and use of IPSS.

In most cases, the user uses this tool in a combination with the Sensors Selection tool, starting by selecting the sensors/signals (signals related to the Products) and using the Context Modelling tool to add signals to identify the user behavior and needs and user environment. In order to be able to extract the context of IPSS use, CM has to be created using the context modelling tool. The full description of context of an IPPS use is not provided by a CM, but the indexing of context to support the identification of the current context. Essentially, CM defines three models: generic, sector-specific and company specific CM. All three CMs exist to model the knowledge by the use of context (including information of user, product, resource, activity, goal, etc.).

As shown in Figure Fig. 2., the tool is a web based application for defining context models (ontologies). The free software solution Protégé is applied. The tool allows to define/select concepts which will be included in CM as well as their mutual relations. The tool allows for an effective maintenance of CM .

Fig.2. Context Modelling Tool

Once the model is defined and deployed in IPSS environment, it can be updated based on the feedback on IPSS use. IPSS provide, based on sensorial system, information on CM use: e.g., by detecting how the user accepts the product and/or services under different context, one may conclude whether the context models is appropriate or has to be updated. Therefore, IPSS may actively provide inputs on CM use and by this contribute to definition of new CMs (for new IPSS) or to update of the already deployed models

Feedback Tool

The tool includes three basic functionalities: (1) feedback from business customers, (2) feedback from consumers, (3) feedback provided by the IPSS themselves. 1. The customers of many IPSS are business organizations: e.g. machine industry normally sells their IPSS to various manufactures with whom they build various business partnerships. From such customers the companies get either direct feedback (e.g. on problems with the products, etc.) or get feedback about various joint activities. In the proposed tool, the feedback from business customers is captured via social software which serves as a platform for cooperation of the manufacturers, service providers and their business customers. As IPSS have to exhibit very high flexibility and require multidisciplinary expertise, experience in using and building services. Collecting feedback is a very difficult task, when using classical PDM/PLM solutions. Social software such as wikis etc. allows for very flexible capturing and presentation of knowledge/experience of different actors and provision of feedback from the business customers. Social software, however, often suffers from missing structures limiting reuse of these experiences and feedback. These solutions allow non-IT experts to provide their experience/feedback in any form it fits them. For example, problems in manufacturing of parts or assembly can be documented by the shop floor in a form which best suits specific manufacturing line/machine (each group can define its own 'form'). The feedback from customers on the IPSS use can be also provided in any form which suits specific customer and/or service experts. 2. Social media networks allow the gathering off feedback in very "free" form.

Feedback is thereby often indirectly expressed by opinions/experiences of consumers. The tool analyses such feedback from social media networks, such as LinkedIn, Facebook, Twitter, Pinterest, Instagram, etc., by applying various data mining algorithms, and provides it in the form re-usable by the actors. 3. As explained above, IPSS can directly provide feedback on their use as well as other information which can be used for (re-) development of IPSS. For example, IPSS may provide feedback serving for continuous ecological impact improvement (including monitoring of ecological impact patterns using sensors based information). Feedback could also be used for "eco-optimal condition based maintenance" of products (including e.g. setting observers to predict possible negative ecological impact patterns etc.), or design recommendations based on "eco-knowledge" as feedback for continuous "eco-improvement" of the products itself, in a form of so-called feedback or monitoring services integrated in IPSS. In order to have an accurate measure and monitoring mechanism to gather feedback from IPSS e.g., on the environmental impact, the tool for the selection of sensors, as explained above, supports the definition of appropriate sensors on the products. Special attention is e.g., paid to monitoring the resources (energy and water) consumption during the use stages. This ensures a critical component performance to optimize IPSS operation and improving sustainability by extending product life. One of the most critical questions is how the monitoring services identify feedback patterns within use and provide design recommendations in appropriate form that can be effectively used in the future design. The tool applies a method (under development) for modelling such feedback patterns, which is continuously improved based on self-learning approach using measurement data and data obtained from the selected sensors. As self-learning approach genetic algorithms, Reinforcement Learning methods (adequate to support adaptation based on experience) or Supervised Learning techniques (require a set of training samples to start with) are under consideration [START_REF] Scholze | Reliable Self-Learning Production Systems Based on Context Aware Services[END_REF]. In this way, the selected sensors are embedded within the product during the use in order to collect the required data and feed them back to the Development Environment. In addition, the tool includes the mechanisms to capture the behavior of the users to provide a feedback loop to the Environment to provide the Network with the ability to conceive and understand the needs of the market to provide solutions to these unexpressed new requirements and evolving needs. The data mining algorithms are under consideration to capture the behaviors of the users and by this provide feedback to the Development Environment in a form which can be effectively used by various actors in the Collaborative Network. It is assumed that IPSS may provide such feedback proactively: whenever the Network starts to deal with the services and products which are same or 'similar' the IPSS may 'offer' the available data/knowledge to the Network.

Potential Applications

Machine industry is the most typical sector in a need for new methods and tools for development of innovative IPSS, as machines are the most typical products with cyber physical features and this industrial sector is rapidly turning from solely manufacturing to servitisation. The manufacturing companies in the machine sector, producing machines and equipment for various sector, to be delivered to the global market require new solutions for effective collaboration and knowledge exchange among various stakeholders within IPSS Collaboration Networks. For such companies the design of IPSS is even a more complex process than for mass product manufacturers. Manufacturing companies are today facing a new paradigm, called "Mass Customization". This new paradigm intends to move from classical production to production of highly customized products in large numbers. Companies can interact with customers, following different approaches, to determine the features of a product/service that they really need or firms can produce a standardized product that will be customizable by consumers. One of the most distinctive features to achieve mass customization is to provide customizer the ability to involve customer in the design of products and services. However, to meet requirements of mass customization, the manufacturers of machines for production of mass customized products need feedback from their business customers to whom they sell their equipment as well as from the final-product users/consumers. For example, the German company producing machines for shoe industry, involved in the research on IPSS development environment, needs to combine feedback from their business partners (shoe manufacturers) and feedback from the shoe buyers in order to improve their machines and various services around machines and allow for mass customization of shoes, which is one of the key requirement in today's global shoe market [START_REF] Stokic | Engineering Methods and Tools for Collaborative Development of Industrial Cyber-Physical Based Products and Services[END_REF].

This company aims at both products performance/usability improvements as well as a reduction of the lifecycle CO2 footprint of new/enhanced machines-services within IPSS. They intend also to use the services (e.g., remote diagnostics and predictive maintenance) to automatically collect the overall equipment efficiency of their machines, used at their customers. Goal is thereby enhancement of the design of the machines and services. On the other hand, in order to improve the design of the machines and reduce CO2 footprint in manufacturing of machines, they feedback along the whole machine life-cycle (from design to machine usage). Their machines have cyber physical features and a number of services collect high volume of data on the machines usage, which allow to establish direct feedback from the IPSS to the Development Environment.

Besides data which is collected by automatic measuring overall equipment efficiency (hardware and software), especially the knowledge of people involved in these processes is of key importance. For example, the knowledge of service teams as well as business customers (shoe manufacturers), which are distributed all over the world (mostly Far East, South America etc.) is of key interest. In order to allow the people involved in these value chain, taking into account diverse aspects, such as cultural differences, education level of operators and highly variable machine usage conditions, they need a support system allowing for easy documentation of actors experience. Therefore, they intend to build a unique system where machines and services are delivering automatically feedback over the tools described in Section 4 and knowledge/experience from both machine designers, process designers, shopfloor experts and customers from different world regions. The feedback is collected and structured to be re-used for optimization of IPSS design. However, as explained above, in order to cope of mass customization requirements in shoe market, and upgrade their machines and services to achieve flexibility required by such approach (but in the same time reducing prices of machines, assuring their reliability), the company needs to obtain feedback from 'shoe consumer'. This will allow for better identification of mid-term customization requirements of consumers in different parts of the world. To achieve the upcoming trend for consumer driven customization, they intend to build shops (both physical and internet based) where the consumers may design/customize their own shoes and by this implicitly and automatically provide knowledge on their needs. Therefore, feedback from own manufacturing, business customers and shoe consumers will be collected in real time and provided to machine and service designers within the new Development Environment. On mid-term, it is expected that also the final products (shoes) will include sensors and cyber physical features which may be used to gather feedback to the Environment.

The company is currently testing several services built within the new IPSS Development Environment and using the tools described in Section 3 and 4, and investigate the feedback from the machines in order to establish continuous improvement of IPSS and especially address environmental aspects. The senor data as a feedback from machines is automatically flowing in the environment and used to identify potentials for improvements. The feedback from the business customers is obtained over wiki and semantically enriched to be correlated with the products knowledge. Based on the current testing by this company, as well as by several other companies involved in the research, it is expected that the environment and tools will allow for a reduction of time and efforts needed for development/update of IPSS by 25-35%, and allow for an increase in number of innovative personalized services by more than 40%. It is expected that the proposed solution will contribute to reduction of time to market of IPSS for products with cyber physical features by at least 10%.

Conclusions

The paper introduces the new concept of Intelligent PSS (IPSS), i.e., PSS developed around products with cyber physical features. The research presented in this paper is one of the first attempts to establish the Development Environment and set of tools for human -product cooperation on the development of IPSS. The three tools presented are typical examples of novel engineering functionalities needed for the development of IPSS, which allow for effective collaboration among various stakeholders in the IPSS values chains and IPSS themselves. Such tools, together with a set of other tools for engineering of IPSS, may facilitate building of new forms of Collaborative Networks within which humans and products may effectively collaborate on (re-)development of IPSS.

The Development Environment and the tools are currently under development and they are tested by several companies both in machine industry (as presented in Section 5) and by several mass product manufacturers (automotive and home appliance industries). The current version of the Environment and of the tools is limited to active provision of data/knowledge by IPSS. This means that the Collaborative Environment and the tools "inform" IPSS distributed over the world that a new IPSS is under development and IPSS then may provide appropriate knowledge. Future research it will be investigated how IPSS may more proactively take part in the development process: e.g., they may initiate re-development of certain services or components. For example, based on the identification of the needs of the customers, new services to improve the use of the product may be proposed etc.

The benefits of the proposed concept and tools are expected in terms of more effective building of intelligent product-services which better fit to the users' needs.

Fig. 1 .

 1 Fig. 1. Development Environment for IPSS Human-Product Collaborative Network

Acknowledgment

This work is partly supported by the PROSECO (Collaborative Environment for Eco-Design of Product-Services and Production Processes Integrating Highly Personalized Innovative Functions) project of European Union's 7th Framework Program, under the grant agreement no. NMP2-2013-609143 and DIVERSITY (Cloud Manufacturing and Social Software Based Context Sensitive Product-Service Engineering Environment for Globally Distributed Enterprise) project of EU's H2020 framework, under the grant agreement no. 636692. This document does not represent the opinion of the European Community, and the Community is not responsible for any use that might be made of its content.


Paula Graça
email: mgraca@deetc.isel.pt

Luís M Camarinha-Matos

A Proposal of Performance Indicators for Collaborative Business Ecosystems

Keywords: Collaborative Network, Business Ecosystem, Digital Business Ecosystem, Performance Indicators

Business ecosystems enabled by the increasing use and improvement of communication networks, offer nowadays a powerful competitive advantage to business players and entrepreneurs. They form a collaborative new mean of economic and social value creation, addressing customers' needs, overcoming constraints of individual firms, increasing capabilities for new business opportunities, and accelerating learning and innovation. This paper proposes a set of performance indicators to measure some of these collaboration benefits, therefore motivating the sustainability and resilience of the business ecosystem. The presented results are based on simulation models, which intend to characterize the roles and interactions of a real life collaborative business ecosystem.

Introduction

The increasing progress and use of information and communication technologies, namely computer networks, and collaboration platforms, have changed the ways of making business, which have moved from traditional industrial sectors to business ecosystems supported by collaborative platforms. The term Business Ecosystem was introduced by Moore [START_REF] Moore | Predators and prey: a new ecology of competition[END_REF], which used natural ecosystems as a metaphor to describe business environments. According to this author, a business ecosystem is "an economic community supported by a foundation of interacting organizations and individuals -the organisms of the business world. This economic community produces goods and services of value to customers, who themselves are members of the ecosystem". The players of the ecosystem "coevolve their capabilities and roles" [START_REF] Moore | The death of competition: leadership and strategy in the age of business ecosystems[END_REF] in a symbiotic business environment.

A recent business trends report [START_REF] Kelly | Introduction: Business ecosystems come of age[END_REF] denotes the continued rise of business ecosystems as a highly relevant transition with substantial implications for the society, economy, and businesses. In fact, as argued by the author, a business ecosystem captures three main generic characteristics of any ecosystem: 1) Variety for a healthy ecosystem, due to the encouragement for participation of a diversity of organizations, that together can overcome the capabilities of any one of them; 2) Potential for ever more productive development of the ecosystem, due to the increasingly advanced ways of collaboration, boosted by high-tech tools of connectivity and interaction; and 3) Longevity and durability of the ecosystem, due to a collective awareness of its members to protect, foster, and sustain the ecosystem, motivated by common goals, benefits, and values. These characteristics of an ecosystem highlight and reinforce the purpose of this paper, which is driven by the following research question:

"What is a reasonable set of key performance indicators to measure and assess collaboration benefits in a collaborative business ecosystem (CBE)?" [START_REF] Graça | The Need of Performance Indicators for Collaborative Business Ecosystems[END_REF] In order to address the above presented research question, the following hypothesis is considered: "Collaboration benefits can be evaluated and made explicit if a set of indicators is established through a holistic combination of concepts of value and benefit, derived from a number of research areas such as value systems, social networks analysis, supply chain performance, and complex adaptive systems". This hypothesis guides this research, which proposes a set of performance indicators and related metrics to assess benefits in a CBE, promoting its sustainability and resilience.

The remaining sections of this paper are organized as follow: section two presents a brief literature review, highlighting contributions from a number of related research fields, section three proposes a set of performance indicators to assess CBEs, and section four shows results of some metrics based on simulation data, to assess the coherence of the models. The last section discusses the contributions and future work.

Literature Review

The research area of collaborative networks [START_REF] Camarinha-Matos | Collaborative networks: A new scientific discipline[END_REF], in particular their established reference models and taxonomies [START_REF] Camarinha-Matos | Collaborative networks: Reference Modeling[END_REF], provide a significant contribution to understand the structure and dynamics of a business ecosystem. A business ecosystem, as described in [START_REF] Camarinha-Matos | Collaborative networks: Reference Modeling[END_REF], is a sub-class of a Virtual Organizations Breeding Environment (VBE), i.e. a source network of organizations founded as a long-term strategic alliance. As such, a CBE is modeled as a community of organizations, whose connections are created during a given period (for instance one year), resulting in the formation of Virtual Organizations (VOs), according to collaborative business opportunities.

In order to propose performance indicators for a CBE, a literature research shows that there are already well-established indicators for individual organizations, of which the balanced scorecard (BSC) [START_REF] Kaplan | The balanced scorecard: translating strategy into action[END_REF] is the most common example. However, to measure collaboration benefits in a network of organizations, or more specifically in a CBE, there is still a lack of solutions, despite some efforts made in a number of research areas. One example is a conceptual model for VBEs value systems using a BSC to monitor the VBE performance [START_REF] Romero | A conceptual model for virtual breeding environments value systems[END_REF]. Another example is the value systems proposed in [START_REF] Camarinha-Matos | A conceptual model of value systems in collaborative networks[END_REF], [START_REF] Macedo | A qualitative approach to assess the alignment of Value Systems in collaborative enterprises networks[END_REF], which identify collaborative social and economic core values, suggesting mechanisms to assess the alignment of the value systems of the network members. These mechanisms allow identifying conflicts that may affect the performance of a CBE, although not suitable for performance measurement purposes. More concerned with collaboration benefits, an example presented in [START_REF] Abreu | A benefit analysis model for collaborative networks[END_REF], identifies and characterizes benefits, such as innovation capacity, flexibility, agility, costs, and risks, among others, which constitute an important input for the establishment of the proposed metrics and associated performance indicators.

The research area of traditional supply chains, which have evolved to more collaborative platforms, known as supply chain collaboration (SCC), provides a wide number of performance models and metrics. For instance in [START_REF] Gopal | A review on supply chain performance measures and metrics: 2000-2011[END_REF], the authors made a comprehensive review of supply chain performance measurement methods comprising the period from 2000 to 2011, and found several techniques and models that were used, namely, AHP (Analytic Hierarchy Process), SCOR (Supply-chain Operations Reference Model), SEM (Structural Equation Model), BSC (Balanced Scorecard), Six Sigma, and combinations of two of them. In [START_REF] Ramanathan | Performance of supply chain collaboration-A simulation study[END_REF], more concerned with collaboration (SCC), the author conducted a survey in which he identified a number of mathematical and simulation models focused mainly on the performance evaluation. Some of these techniques and models can be adapted to CBEs; in particular, simulation models to characterize the business environment, and a subset of statistic models from SEM, widely used in the field of behavioral and social sciences.

Another related area is the social network analysis (SNA), which is currently a subject of much research work due to the growth of social networks. In SNA, the social structures are analyzed using network and graph theory, which provides measures of centrality (degree, betweenness, closeness, etc.), and cohesion (reciprocity, density, clustering, etc.). Inspired by SNA, several attempts have been made to apply these indicators to collaborative networks. For instance, a set of indicators to measure the value of social capital of a VBE [START_REF] Abreu | An Approach to Measure Social Capital in Collaborative Networks[END_REF], and a methodology for a network analysis of a business ecosystem [START_REF] Battistella | Methodology of business ecosystems network analysis: A case study in Telecom Italia Future Centre[END_REF], among others. However, the structural analysis of the network is limited when it comes to capture the value of the economic or social exchanges represented by the connections. To overcome these limitations, a value network analysis (VNA) model is proposed in [START_REF] Allee | Value Networks and the true nature of collaboration[END_REF], providing metrics to evaluate the complex dynamic exchanges of tangible and intangible values in the network. Even though these contributions, a solution to measure the performance of a CBE is not yet established.

The proposed performance indicators for CBEs described in the next section, are inspired mostly by these last presented approaches.

Metrics and Measures for Collaborative Business Ecosystems

The adopted research approach at this stage uses models with simulated data to assess the consistency and make a preliminary calibration of the measurement scale of the metrics and performance indicators proposed in this section. The approach is represented by the process depicted in Fig. 1. The analysis of the literature in a number of related research areas, such as enterprise performance indicators, value systems, collaboration benefits, social network analysis, and supply chain collaboration, inspired a set of metrics and measures with a potential applicability in CBEs. Then, several simulation models of CBEs are used to assess the metrics and calibrate the scales using ratios and standard normalization methods.

A CBE model is represented by a weighted direct graph, where nodes stand for organizations, and arcs correspond to the collaborative transactions between them. The weights of the arcs stand for the number of times the collaborative transactions were performed in a given period (by the creation of VOs in the CBE). In the used models, random series of data were also considered, to simulate existing (e.g. portfolio of competencies) or new value created by the organizations (e.g. products, services, or patents), resulting or not from the collaboration, therefore not directly characterized by the graph. Finally, the last step resulted in a first proposal of a set of performance indicators to assess CBEs. The performance indicators for CBEs introduced in this work and described in the following tables are: 1) Innovation Indicator (II), to measure the innovation potential of a CBE; 2) Contribution Indicator (CI), to evaluate the value creation of a CBE; 3) Prestige Indicator (PI), to assess the influence/prominence of each organization in the CBE; and 4) Resilience Indicator (RI), to assess the resilience of a CBE.

The choice of the above indicators is based on the performed literature analysis and mainly driven by societal, economic, and business concerns. The potential for innovation of a CBE reflects its health level, therefore contributing for social and economic value creation. On the other hand, in a business environment, the economic value is a strong argument for collaboration. As such, the contribution indicator is proposed to show the economic value of the collaboration, i.e. the value that an organization brought in the CBE, and the value that is gained by an organization from the CBE. The prestige indicator shows the distribution of collaboration among organizations in the CBE, revealing eventual prominence of one or more organizations, or even isolated organizations. A strong collaboration level enhances a common network identity, reinforcing collaboration trust, and increasing collaborative knowledge. At last, the resilience indicator in a business context assesses "the capacity for an enterprise to survive, adapt, and grow in face of turbulent change" [START_REF] Fiksel | Sustainability and resilience: toward a systems approach[END_REF]. Table 1 presents a brief description of these indicators, explaining their meaning for individual organizations Oi in the CBE, and for the CBE as a whole. Considering these performance indicators, a set of appropriate metrics had to be found in order to identify key measurable characteristics of each indicator. The suggested metrics are shown in Table 2, including mainly counting measurements (e.g. number of new products, services, or patents created by each organization or by the CBE as a whole), as well as measurements related to the network structure, such as centrality, which is a measure of the activity or level of influence in terms of relationships among the organizations of the CBE.

The metrics shown in Table 2 to assess the resilience of a CBE were inspired by the four fundamental characteristics of resilient living ecosystems considered in [START_REF] Fiksel | Designing resilient, sustainable systems[END_REF]: Diversity, Efficiency, Adaptability, and Cohesion, and were tailored to business ecosystems. In fact, the resilience of the CBE can be calculated as a function of these factors, if each of them can be translated in terms of one or more quantified metrics.

PIi

At this stage, the performance indicators can then be formulated as a function of the presented metrics. The suggested formulas described in Table 3, are calculated in terms of ratios (case of II), or measures of degree centrality (case of CI), and betweenness centrality (case of PI).

Is measured by the ratio between the two variables #NewPd i and PortPd i

The ratio of the totals is weighed by the correlation r between the two variables: (#VO, #NewPd)

Resilience Indicator (RI)

Performance Indicators for CBEs Contribution Indicator (CI) The measures of centrality are adopted from [START_REF] Freeman | Centrality in social networks conceptual clarification[END_REF], but they will have to be reformulated in order to incorporate the weights of the connections, which represent collaborative opportunities and contacts towards potential collaborative opportunities. Then, the resulting indicators are normalized in relation to the size of the CBE (number of organizations). Finally, RI is calculated as a function of the factors (Di, Ef, Ad, and Co), in which the evaluating metrics are weighted by a value according to their relevance in the context of the CBE.

# # ∑ # ∑ # * # , # ∑ # ∑ # ! * " ! # ! ∑ "! # ! $ % &', (%, , (% ∑ # )*+ ! * " ! # ! ∑ # )*+ ! # # * " ! ∑ #, )*+ ! * " ! # ! ∑ # )*+ ! * " ! # ! - ∑ # )*+ ! * " ! # ! ∑ #. )*+ ! * " ! # ! &' ∑ #.)/ .0 ! * " ! # ! ∑ " ! # ! - ∑ #.)/ + ! * " ! # ! ∑ " ! # ! '1, 2 ) ( , 3 ∑ 3 * 4 3 # 1 4 2

Assessment and Calibration of the Performance Indicators

Among the performance indicators introduced in the previous section: Innovation Indicator (II), Contribution Indicator (CI), Prestige Indicator (PI), and Resilience Indicator (RI), II is chosen for the illustrative examples presented below. The II for a given organization Oi (IIi), measures the ratio between the new products, services, or patents created by that organization (#NewPdi) during a given period, and its portfolio (#PortPdi). The same indicator for the whole CBE, measures the ratio between the number of total products, services, or patents created in the CBE (∑i #NewPdi), and the total portfolio of the (∑i #PortPdi). However, this ratio does not give any indication about collaboration, i.e., the indicator does not reflect a measure of the improvement of innovation due to collaboration. Thus, the ratio II for the whole CBE (IICBE) is weighted by a correlation coefficient (Spearman's or Pearson's) [START_REF] Myers | Research design and statistical analysis[END_REF], denoted by r, between the number of VOs in which the organizations have participated (#VO), and the new products, services, or patents that they have created (#NewPd).

Pearson's correlation coefficient is a of the extent to which two quantitative variables (in this case #VO and #NewPd) are linearly related. It measures the strength of the association between the two variables, giving a value between +1 and -1 inclusive, where 1 is total positive correlation, 0 is no correlation, and -1 is total negative correlation. The Spearman correlation coefficient, is the usual Person r applied to data in the form of ranks, measuring how well the relationship between two variables can be described using a monotonic function. The process to rank data in order to calculate the Spearman correlation, consists of replacing each element of a set, by its ranking position according to its relative value (the lowest is rated one, and the higher the number of elements of the set). For instance, considering the set of data S1={9, 2, 8, 5}, the resulting rank set is RkS1={4, 1, 3, 2}. When the set contains repeating elements, for instance the set S2={9, 2, 5, 5}, the repeated elements are rated with the mean of their raking positions, e.g., the mean for the element 5 is (2 + 3)/2 = 2.5), resulting in the rank set RkS2={4, 1, 2.5, 2.5}.

To assess the metrics and coherence of the performance indicator II, as stated above, three simulated scenarios were created (CBE1, CBE2, and CBE3), and described in Table 4, Table 5, and Table 6. The three scenarios represent the same CBE composed of ten organizations, but showing different indexes of innovation, and collaboration performances. The goal of the first two scenarios is to show the influence of the correlation coefficient over the same value of the ratio II of the CBE as a whole, i.e., the smaller the correlation coefficient, the smaller the value of the IICBE. The third scenario shows how a high ratio II is pushed down caused by a very low correlation coefficient, meaning that the innovation capacity of the ecosystem was not due to collaboration. Table 4 represents the simulated scenario CBE1 exhibiting hypothetical series of data for the metrics #PortPd, #VO, and #NewPd, and the calculated ratio IIi, between 0 and 1, using linear normalization. The values of the IICBE (0.64 and 0.58), are calculated by multiplying the ratio II (0.77) by the Pearson (0.84) and Spearman (0.75) correlation coefficients, respectively. Table 5 depicts another scenario (CBE2) showing the same ratio II for the whole ecosystem (0.77). However, the collaboration coefficients are lower (0.51 and 0.50), resulting in a lower value (0.39) for the IICBE. The last scenario (CBE3), depicted in Table 6, exhibits a high ratio II (0.92), but a very low collaboration coefficients (0.13 and 0.10), resulting in equally low IICBE values (0.12 and 0.09), meaning that the high improvement of innovation is not due to the collaboration in the CBE. Considering the boundary conditions of the correlation coefficient (r = 1 and r = 0), the value r = 1 maximizes the result of the IICBE, meaning that the innovation capacity is all up to collaboration. The value r = 0, pushes the resulting IICBE down to 0, meaning that the innovation is not related to collaboration. A negative correlation coefficient is not considered, as it is not assumed that collaboration could influence negatively the innovation capability of the organizations.

The above analysis is based on simulated scenarios. For a further assessment of the proposed indicators, the ongoing work involves capturing real data from a concrete business ecosystem. This is being done for the ports area, a collaborative community offering integrated logistics and freight services. A port area is an interesting use case, as it offers a wide diversity of players and services, such as port authorities, customs, freight forwarders, multi-modal transport entities (rail, road, and maritime), suppliers, and customers, collaborating through increasingly integrated technological platforms, effectively contributing to the growth of the local economy and social value.

Conclusions and Further Work

The metrics and associated performance indicators presented along this paper, contribute as a first approach to accomplish the research question and related hypothesis stated in the first section, by proposing a set of indicators to assess collaboration benefits. A set of metrics were also suggested to quantify those benefits, and different scenarios of CBEs represented by models with hypothetical data were used in order to assess the validity of the measures associated to the indicators. The ongoing work, as mentioned above, encompasses the continuation of the assessment of the proposed indicators, but capturing real data from concrete businesses ecosystems.

The future work is aimed at finding an answer to address the second research question, which consists of:

"How to promote collaboration sustainability and resilience within a business ecosystem?" [START_REF] Graça | The Need of Performance Indicators for Collaborative Business Ecosystems[END_REF] In order to respond to this question, the following hypothesis is considered: "Sustainability and resilience of collaboration in business ecosystems can be promoted if a system of incentives, combined with transparent assessment methods, is implemented at the ecosystem level". This hypothesis will guide the next steps of this research, which will be mostly supported by models using system dynamics (SD) combined with agent based (AB) simulation. The AnyLogic Multimethod Simulation Software [START_REF]Multimethod Simulation Software and Solutions[END_REF], will provide the methods and simulation tools to create and explore these models. SD is a method to improve learning in complex systems, somewhat a method to develop computer models, to help learning about dynamic complexity, understand the sources of policy resistance, and design more effective policies [START_REF] Sterman | Business dynamics: systems thinking and modeling for a complex world[END_REF].

The goal of applying SD at this stage of the research is first to capture and represent the organization of a CBE, considered as a complex system, which, along with stocks and flows structures, feedback processes, time delays, and other structures, determine its dynamic behavior. In a second phase, the performance indicators should be introduced to affect the dynamic behavior of the agents. Finally, a third phase will be dedicated to simulation to observe the agents' behavior, playing with the introduction of incentives/penalizations, resulting from the decisions of the managers.

The explained research approach, aims to specify, validate and make accepted by experts and the scientific community, a set of indicators for CBEs, which not only allow to evaluate the performance of the system, but also contribute to motivate its sustainability and resilience.

Fig. 1 .

 1 Fig. 1. Process representing the used methodology to develop a set of PIs for CBEs.

  rP and rS denote Pearson and Spearman correlation coefficient, respectively Rk(#VO, #NewPd) stands for rank data of #VO and #NewPd, used to find Spearman correlation coefficient

Table 1 .

 1 A short description of the proposed performance indicators.

		Performance Indicators for CBEs
	Indicator	Definition (for each Oi)	Definition (for the CBE)
	Innovation	IIi -M easures the	IICBE -M easures the innovation potential of the CBE as a
	Indicator	innovation potential of a	whole
	(II)	member of the CBE
	Contribution	CIi -M easures contribution	CICBE = (CICBEt , CICBEd)
	Indicator	for value creation of a	M easures the total value creation of the collaboration in the
	(CI)	member of the CBE	CBE as a whole (CICBEt ), and the degree to which the most
			active member exceeds the contribution of the others (CICBEt)
	Prestige	PIi -M easures the	PICBE -M easures the average difference between the most
	Indicator	influence/proeminence of a	influent member and that of all members of the CBE
	(PI)	member of the CBE
	Resilience		RICBE = f (Di, Ef, Ad, Co)
	Indicator (RI)	______	Assesses the resilience of the CBE, evaluating four main components: Diversity (Di), Efficiency (Ef), Adaptability
			(Ad), and Cohesion (Co)

Table 2 .

 2 A proposal of metrics to establish the proposed performance indicators for CBEs.

			Metrics for Performance Indicators for CBEs
	PIs	Org. Oi / CBE		Metrics
			#PortPd i	-Portfolio of products, services, or patents of the member
	Innovation Indicator (II)	IICBE IIi	O i -No. of new products, services, or patents generated by the member O i -No. of VOs in which the members O 1 , …, O n participated -Total portfolio of products, services, or patents of the CBE {#NewPd 1 , …, #NewPd n } -No. of new products, services, or patents generated by #NewPd i {#VO 1 , …, #VO n } ∑ i #PortPd i the members O 1 , …, O n
			∑i #NewPd i	-Total no. of new products generated in the CBE
	Contribution Indicator (CI)	CICBE = (CICBEt , CICBEd) CIi = (CIi in, CIi out)	#CoOp i in, #CoOp i out Act in(O i ), Act out(O i ) ∑ i #CoOp i {#CoOp 1 , …, #CoOp n } ∑ i [Act(O*) -Act(O i )]	-No. of collaborative opportunities the member O i gained from or brought in the CBE -Activity in/out of the member O i in the CBE -Total no. of collaborative opportunities created in the CBE -No. of collaborative opportunities in which the members O 1 , …, O n participated -Sum of the differences between the activity of the most active member (O*) and that of all members of the CBE
				Act(O*) = #CoOp of the most active member
			#CCoOp i	-No. of received contacts towards potential collaborative
	Prestige Indicator (PI)	PICBE	opportunities of the member O i -Influence of the member Oi, i.e., the likelihood of O i to be contacted towards potential collaborative opportunities {#CCoOp 1 , …, #CCoOp n } -No. of receiving contacts towards potential collaborative Inf(O i ) opportunities of the members O 1 , …, O n ∑ i [Inf(O*) -Inf(O i )]/(n-1) -Average of the differences between the influence of the most influent member and that of all members of the CBE
				Inf(O*) = influence of the most influent member
		__		______
			∑ i #CoOp i	-Total no. of collaborative opportunities created in the
	Resilience Indicator (RI)	RICBE = f (Di, Ef, Ad, Co)	∑ i #PortPd i ∑ i #PortCp i ∑ i #ShIntgAs i ∑ i #CCoOp i ∑ i #RCCoOp i	CBE -Total portfolio of products, services, or patents of the CBE -Total portfolio of competences of the CBE -Total of shared intangible assets (documents, processes, knowledge, etc.) in the CBE -Total no. of contacts towards potential collaborative opportunities in the CBE -Total no. of reciprocated contacts towards potential
				collaborative opportunities in the CBE
			∑ i #PCCoOp i	-Total no. of possible contacts between all pairs of
				members of the CBE

Table 3 .

 3 Proposed calculation formulas for the performance indicators to assess CBEs.

	PIs	Calculation	Remarks
	Innovation I. (II)
		Act in/out (O i ) can be measured by the weighted
		indegree/outdegree centrality (C D ) of the member O i
		in the CBE, which stands for the sum of direct
		connections in/out of the member O i to the n
		members O j with weight #CoOp ij
		where
		CI CBE d can be measured by the weighted degree
		centrality (C D ) of the CBE as a whole
		where
		Can be measured by the weighted betweenness
		centrality (C B ) of the member O i in the CBE,
	Prestige Indicator (PI)	assuming that connections between any member O k and any other O j have weight of #CCoOp kj where Can be measured by the weighted betweenness centrality (C B ) of the CBE as a whole, assuming that connections between any member O k and any other O j have weight of #CCoOp kj
		where
		______	______
		Can be measured in function of the factors: Di, Ef,
		Ad, and Co:
		(Di)versity = Port. Products + Port. Competences
		(Ef)ficiency = ratio of C. Opportunities over the
		Contacts towards potential C. Opportunities
		(Ad)aptability = Intangible Assets
		(Co)hesion = Reciprocity + Density
		where W i is the weight of each metric according to
		its relevance in the CBE (which can be evaluated by
		questionnaires, interviews, literature, etc.)

Table 4 .

 4 Simulated scenario of the CBE1 to assess the Innovation Indicator (II).

	#N #PortPd #VO #NewPd II
	O 1	1	2	2 0,22	3	6
	O 2	2	2	2 0,11	3	6
	O 3	3	3	1 0,04	5,5	2
	O 4	2	4	2 0,11	7,5	6
	O 5	3	5	3 0,11	9	9
	O 6	4	3	2 0,06	5,5	6
	O 7	5	6	4 0,09	10	10
	O 8	1	2	1 0,11	3	2
	O 9	2	4	2 0,11	7,5	6

Table 5 .

 5 Simulated scenario of the CBE2 to assess the Innovation Indicator (II).

#N

#PortPd #VO #NewPd II

					Rk(#VO,#NewPd)
	O 1 O 2 O 3	1 2 3	2 2 3	1 0,11 2 0,11 2 0,07	3 3 5	1,5 5,5 5,5		4	Correlation (#VO, #NewPd)
	O 4	2	5	2 0,11	8,5	5,5		3
	O 5 O 6 O 7	3 4 5	5 6 4	2 0,07 2 0,05 3 0,06	8,5 10 6,5	5,5 9,5 5,5	#VO	1 2
	O 8	1	2	2 0,22	3	5,5		0
	O 9	2	4	3 0,16	6,5	9,5		0	1	2	3 #NewPd 4	5	6	7
	O 10	3	1	1 0,04	1	1,5
	10	26		20 0,77 r P: 0,51 r S: 0,50
				IICBE:	0,39	0,39

Table 6 .

 6 Simulated scenario of the CBE3 to assess the Innovation Indicator (II).

	#N #PortPd #VO #NewPd II	Rk(#VO,#NewPd)
	O 1 O 3 O 2	1 3 2	5 2 6	3 0,25 2 0,06 1 0,04	8,5 2,5 10	7 5 2,5		5 6	Correlation (#VO, #NewPd)
	O 4	2	4	1 0,04	6	2,5		4
	O 5 O 6	3 4	4 5	1 0,03 5 0,11	6 8,5	2,5 10	#VO	2 3
	O 7	5	3	4 0,07	4	9		1
	O 8	1	2	3 0,25	2,5	7		0
	O 9	2	4	3 0,13	6	7		0	1	2	3 #NewPd 4	5	6	7
	O 10	3	1	1 0,03	1	2,5
	10	26		24 0,92 r P: 0,13 r S: 0,10
				IICBE:	0,12	0,09

Acknowledgment. This work benefited from the ongoing research within the CoDIS (Collaborative Networks and Distributed Industrial Systems Group) which is part of both the New University of Lisbon (UNL) -Faculty of Sciences and Technology, and the UNINOVA -Institute for the Development of New Technologies. Partial support also comes from Fundação para a Ciência e Tecnologia through the PEST program UID/EEA/00066/2013.