Giulia Bruno
email: giulia.bruno@polito.it

Emiliano Traini
email: emiliano.traini@polito.it

Franco Lombardi
email: franco.lombardi@polito.it

A Knowledge-based System for Collecting and Integrating Production Information

Keywords: Industry 4.0, PLM, MES, knowledge management

Design and production departments are scarcely integrated in manufacturing companies. This fact, especially for companies with a highly customized production, is very critical, since the collaboration between the two departments is essential to reduce the trial-and-errors cycles to design new products and process. It is therefore necessary to collect data from the shop floor, especially the ones related to anomalies or critical situations, and make them at disposal to be used to improve the design of the next products and processes. The aim of this paper is to develop a knowledge-based system to digitalize and collect data regarding anomalies at the shop floor, and to integrate them with data coming from the design phase, in order to reduce the time for finalizing a new product. A case study has been developed for a car prototyping company to illustrate the potentiality of the proposed solution.

Introduction

Today market is characterized by a by high volatility and quick dynamics. To compete in such market, small and medium sized manufacturing companies focus on product innovation and customization [START_REF] Wortmann | Customer-Driven Manufacturing[END_REF][START_REF] Tu | Production planning and control in a virtual one-of-a-kind production company[END_REF][START_REF] Dean | An Information System for One-of-a-Kind Production[END_REF]. Effective collaboration and knowledge sharing among experts and technicians is the winning strategy for such manufacturing systems. In fact, decision making mainly relies on the human learning process based on product case-histories, which enables operators to react autonomously to improve the manufacturability. In addition, companies are addressing a digital transformation, by using data to improve their production processes and achieve greater consistency.

Several commercial software applications are already available for product lifecycle management (PLM) and manufacturing execution control (MES). PLM systems make at disposal of designers shared product databases. The fact that PLM systems are accessible by different people and departments allows the collaborative development of products, enabling sharing and reuse of information. However, PLM systems are not integrated with the manufacturing execution systems (MES), which took control of the factory operations, from production order release testing of the finished product. MES systems are used to control in real time the progress of orders and to associate to each production order the information about the parameters and results of the operations. Through the real-time monitoring, it is therefore possible to control the progression of tasks and compare it with the production planning. In case of delays, the planning can be readjusted accordingly.

However, without a connection between PLM and MES, it is difficult for a designer to find data related to the anomalies occurred during the manufacturing process in the shop floor. This data could be of great importance at the design stage of a new product, especially for companies that realize prototypes, since, to design a new process, they usually need several trial-and-errors cycles before find the final one. For such companies, the knowledge of the trial-and-errors cycles that contribute to develop past products and processes, without the presence of a formalized and structured system, remains in the minds of the people, or, at best, transferred verbally, and then, over time, inevitably lost [START_REF] Bruno | Exploitation of a Semantic Platform to Store and Reuse PLM Knowledge[END_REF][START_REF] Bruno | An approach to support SMEs in manufacturing knowledge organization[END_REF]. Similarly, it is also difficult for a production manager to find information related to the checks to perform before and after the execution of an operation on a machine, and for an operator to report in a structured way the occurrence of problems and anomalies during the production.

Based on such needs, the aim of the paper is to develop a framework able to: (i) collect data regarding anomalies at the shop floor, in addition to the other data regarding the production monitoring typical of MES systems, (ii) integrate data coming from PLM and MES to reduce the number of trial-and-errors cycles to find the final production process of a new product.

The rest of the paper is organized as follows. Section 2 summarizes the relevant literature available on the topic. Section 3 describes the proposed method and the definition of the data model to structure the knowledge-based system. Section 4 presents the application of the framework in the use case of an Italian company producing car prototypes. Finally, Section 5 draws conclusions and states future work perspectives.

Related Works

Previous works addressed the issue of structuring and formalising product-related knowledge [START_REF] Chungoora | A model-driven ontology approach for manufacturing interoperability and knowledge sharing[END_REF][START_REF] David | What does PLMS (product lifecycle management systems) manage: Data or documents? Complementarity and contingency for SMEs[END_REF][START_REF] Efthymiou | On knowledge reuse for manufacturing systems design and planning: A semantic technology approach[END_REF][START_REF] Igba | A framework for optimizing product performance through feedback and reuse of in-service experience[END_REF], while several international research projects addressed the development of industrial knowledge sharing systems (e.g., amePLM [START_REF] Bruno | Efficient management of product lifecycle information through a semantic platform[END_REF], ICP4Life [START_REF] Elgamma | Design for Customization: A New Paradigm for Product-Service System Development[END_REF], Know4car [START_REF] Ebrahimi | Managing Product and Production Variety -A Language Workbench Approach[END_REF], Manutelligence [START_REF] Petrucciani | A Platform for Product-Service Design and Manufacturing Intelligence[END_REF]). The importance of collaboration between design and manufacturing is highlighted in several papers [START_REF] Ming | Mass production of tooling product families via modular feature-based design to manufacturing collaboration in PLM[END_REF][START_REF] Pouchard | Ontology engineering for distributed collaboration in manufacturing[END_REF]. However, the practical use of tools for supporting knowledge management is still very low. The GeCo Observatory (http://www.homeappliancesworld .com/2015/06/01/italianmanufacturing-innovation-is-possible) found, on a sample of more than 100 Italian manufacturing companies, that the most used methods to explicit knowledge remain the traditional verbal or written communication, while the use of more structured software systems is severely limited.

Two lacks can be identified in both current scientific literature and research projects. The first one is that they did not address specifically the highly customized/prototypal production, where the presence of many alternative routings and operations makes very difficult to manage all the manufacturing variables together, in an efficient way, without increasing wastes of time and costs. The second one is that they did not address the problem of collecting data related to failures and anomalies occurring at the shop floor, and make them available for the designers, to allow them learning from past problems when designing new products and processes.

The main technical innovations proposed by our work are the following: (i) open source architecture for PLM, KBS and MES, (ii) advanced data model to relate data from PLM and MES, and (iii) possibility of storing data related to anomalies occurred during the production.

Method

Three systems are used to manage manufacturing information: PLM, MES and Enterprise Resource Planning (ERP). The integration of ERP and MES allows the organization an efficient management of the inventory. In fact, an ERP systems can more efficiently manage the purchase functions if it knows the consumption of raw materials in real time. The integration between ERP and MES is based on the IEC 62264 standard, a model that standardizes the exchange of information between business systems and production control systems. In order to guarantee a consistent flow of information in the company, the integration between PLM-ERP has also to be implemented. The most significant improvement is the integration of the organizational data, ensuring that all areas can access the updated product data.

These two integrations are not capable of guaranteeing the right flow of information between PLM and MES, because the ERP does not have an adequate structure to accept and store detailed data of the product. Therefore, the PLM-MES integration is necessary.

Knowledge-based System

The method we propose is to develop a central Knowledge based System (KBS), acting as integrator of the ERP, PLM and MES. The proposed system will allow (i) to collect all the information regarding the critical realizations of new components in a structured way, so that the added values of the experience breakthrough, as well as other useful tips, could be provided to the users, and (ii) to reuse the knowledge, i.e. help designers to define more reliable processes for new products, reducing the "trialand-error" cycles in the development of forming processes.

In fact, when a customer makes an order, it means that the company must define the sequence of activities to obtain the required product. If the historical data regarding previous products are stored in the KBS, it can be used to find the closest product already produced in the past that needs less changes to be adapted to the new shop order. The chosen product is then found in the PLM platform where the needed changes can be done. The information associated to the new product is sent to the KBS and made accessible to the MES. The MES uses the product information to manage the production and, when the production is finished, it reports in the KBS the information related to the execution of each activity and the success or failure of the product. In case of failure, the company can check the intermediate results reported for each activity and decide how to proceed to obtain a better solution.

KBS Data Model

The KBS contains the subset of data relevant for all the three systems and acting as a bridge among them. In the following, we focus in particular on the integration between PLM and MES. Fig. 1 shows the structure of the KBS through an entityrelationship model. The product entity contains information about the classification, the CAD file, the BOM and other general characteristics of the products. The amount of the semifinished product is connected to it, which identifies the status of the semi-finished products specifying the next activity to be carried out. This is the reason why there is also the activity entity that characterizes the particular activity, explaining the check start, the check-ends and the machines necessary to carry it out. To each type of machine are then associated the physical machines available in the company. These entities are provided by the PLM and are subsequently used by the MES.

To the entities associated with the PLM activity are added entities that model the data provided by the MES, i.e. the data coming from the production. The fundamental entity is the one related to the shop order. In the KBS all the shop orders taken in charge and on which the company has worked are stored. This entity is connected to the product, as each shop order concerns a single and specific product, so a single and specific product lifecycle. The shop order is also connected to the activity carried out, connected itself to the verification checks. It models the data structure from which we can extract the history of all the activities divided by shop order and consequently by product and results obtained.

KBS Implementation

The KBS was implemented as a PostgreSQL database (www.postgresql.org), with the set of tables needed to represent the UML diagram of Fig. 1. The open source PLM software ARAS (www.aras.com) was exploited to digitalise and store the information related to the resources of the company and the production process of each product. Through an automatic procedure, the information related to the entities of Product, Semi-finished products, Activity, Check start, Check end, and Type of machine, together with their relationships, are periodically extracted from the PLM system and inserted in the KBS, to make them available to the MES and ERP systems.

The MES platform JPiano (https://www.aecsoluzioni.it/wp/en/jpianopanoramica/jpiano-prodotti) was used to implement the MES system. As for PLM, also from the MES the information related to the entities of Activities done and Physical machine, and their relationships and the ones with the Check start and Check end are periodically extracted and inserted in the KBS.

Further details on the implementation in a use case are reported in the following section.

Use Case

The framework was applied in an Italian company that operates in the automotive sector, producing prototype bodywork components for passenger cars and other kinds of vehicles. Currently, all the information generated during the production process is only written on paper.

The process for the realization of a prototype bodywork component starts with the delivery, by the costumer, of the CAD model of the requested piece. The CAD model is received by the technical office that defines the production process, the design of the dies and the material to be used. Once the dies have been constructed, the metal sheets used to make the body part are sent to the Laser office where the metal sheet is trimmed using a two-dimensional laser to obtain the appropriate shape outline. After the sheets have been cut, they are transported to the presses area where they undergo the first press operation. The semi-finished items are then returned to the laser section where 3D lasers cut the metal sheet according to specific laser paths obtaining the final measures of the piece and creating slots and holes.

We started the development of our framework with the implementation in ARAS of several graphic user interfaces in order to allow the users to store the data corresponding to the structure represented in Fig. 1. As an example, Fig. 2 presents the user interface to insert the information related the Type of machine entity. Similar interfaces were created for Activities, Product, Check start and Check end. For each activity, the corresponding machine, check starts and check ends can be added by selecting them from the drop down menus created. One of the main potentialities of our framework is the capability of inserting Check start and Check ends related to an activity. Examples of Check starts created for the use case are reported in Table 1. The Check starts represent the controls that the operators have to do before starting the execution of an activity on a machine. The list of Check starts for each Activity are set in the PLM and then transmitted to the KBS, so that they are accessible by the MES. In this way, the MES can show to the operators the Check starts when they start the execution of an activity. The results of the Check starts are inserted by the operators in the MES, which transmit them to the KBS, so they are accessible from the PLM. Similarly, also for the Check ends, for each activity it is possible to specify which are the controls to do at the end of the operation. In the current version of the framework, the Check end is a free text where the operator can write if something went wrong during the operation. A more complex data collection, including the possibility of uploading a photo or a video of the anomalous results, is under development.

In ARAS, it is also possible to define a production process (i.e., the relationship between Activities and Product) by using the Process Plan module. In order to populate a process plan, a designer/planner can easily add the activities by selecting the activities from 'list of Activities' created before. The execution of each activity is then recorded by the MES, which insert the actual start and end date for each activity, so that a comparison between the planned dates and the actual ones can be performed.

To replicate data from ARAS to the KBS, a merge replication [START_REF] Pouchard | Ontology engineering for distributed collaboration in manufacturing[END_REF] was implemented. Merge replication starts with a snapshot of the source database objects and data. Subsequent data changes and schema modifications made at the source database and at the destination database are tracked with triggers. The source synchronizes with the destination when connected to the network and exchanges all rows that have changed since the last time synchronization occurred. In this way, the content of the PLM and the KBS are continuously updated and synchronized.

Conclusions

The objective of this paper is to propose a framework to integrate design and production data, since, especially in small manufacturing companies, they often remain separated and stored in two different systems: PLM and MES. The framework is based on a knowledge based system, which collects and integrates two subsets of data, one from PLM and one from MES, making such data accessible by both the systems. In this way, anomalies that occur at the shop floor during the production can be easily found by designers, who can use them to improve the process in order to improve the design of the following products. Furthermore, the proposed framework allows the data retrieval of previous products and its re-usage to define variants and changes to them.

Future works will consider on the one hand data analysis techniques for using the stored data in the KBS, and on the other hand a more comprehensive integration considering also the ERP system. Furthermore, a set of key performance indicators to evaluate the efficacy of the proposed framework in terms of reduction of time to finalize the process development will be studied.

Fig. 1 .

 1 Fig. 1. UML class diagram of the data model of the KBS.

Fig. 2 .

 2 Fig. 2. Screenshot of Aras PLM implementation: Machine.

Table 1 .

 1 Examples of Check starts related to the Activities of the use case.

	Activity	Check start
	3D Laser welding	Presence of a dedicated head
		Presence of pincers for fixing the piece on the stand
		Set of self-learning programming mode of welding path
	Press punching	Presence of the mold
		Presence of mold mounting brackets
		Presence of supports for handling sheet metal
	Deep drawing	Presence of the mold


Agostino Villa
email: agostino.villa@polito.it

Teresa Taurino
email: teresa.taurino@polito.it

Crowd Engineering: Manage Crowd Contributions for Design and Manufacture of Innovative Products

Keywords:

The increasing complexity of designing and manufacturing products as well as the growing speed required for their innovation is pushing large and medium-small companies to an ever-broader search for new ideas and for a wide availability of experts, able to provide timely contributions. Existing approaches mainly address the early phases of the product lifecycle in the frame of "open innovation". The crowd engineering approach is to organize an efficient and effective utilization of the "crowd", i.e. a wide set of persons, from students to private experts, and to start-ups and smart SMEs, which could be involved in the creation of innovative products. The first purpose of the paper is to give a presentation of Crowd Engineering in terms of a logical frame where crowd-workers will contribute into an informal collaborative network to fulfill technical and social needs. Then a schematic model based on an analogy between Crowd Engineering and Supply Relationship Management, will be outlined thus offering, on one hand, suggestions for a real implementation, on the other, some hints for a research agenda.

Introduction

A collaborative network is a network consisting of a variety of entities (e.g. organizations and people) that are largely autonomous, geographically distributed, and heterogeneous in terms of their operating environment, culture, social capital and goals, but that collaborate to better achieve common or compatible goals, and whose interactions are supported by computer networks [START_REF] Luis | A Comprehensive Modeling Framework for Collaborative Networked Organizations[END_REF]. In the last decades, the growing complexity of the design of new products, the increasingly shorter time-to-market required to market new products, and the spread of the so-called "augmented products" [START_REF] Browne | RFID in product lifecycle management: a case in the automotive industry[END_REF], i.e. products with constantly increasing services, is pushing companies, both large and medium-small, to an ever-broader search for ideas and innovations, through a wide availability of experts, able to provide timely contributions.

Consequently, companies need to re-engineer the design and production process, since many experts, companies, interested persons, associations, etc., which provide them with the many contributions that are usable, form a real "crowd". The Crowd Engineering builds social solutions of design and production of innovative products, by "empowering companies to turn the force of their crowds (suppliers, customers, partners and also employees) into business advantage" (https://www.definitions.net/definition/crowdengineering).

It is evident that such a re-engineering problem involves a careful selection of both the "Contributors" and the contributions themselves for the new product creation or production. This problem has been tackled with multi-criteria decision analysis approaches (MCDA), such as Analytic Hierarchy Process [START_REF] Seminathan | Analysis of Supplier Relationship Management Model using AHP[END_REF][START_REF] Schniederjans | Using the analytic hierarchy process and multiobjective programming for the selection of cost drivers in activity-based costing[END_REF] Analytic Network Process [START_REF] Laura | R&D Project Selection Using the Analytic Network Process[END_REF], Goal and Mixed-Integer Programming [6], Data Envelopment Analysis [START_REF] Cooper | Data Envelopment Analysis[END_REF], and the Fuzzy Set theory [START_REF] Glad | On the relationship between some extensions of fuzzy set theory[END_REF]. However, little information is given about some feedback from practitioners and from implementations of such approaches, which are still few. In practice, as recently observed in some particularly innovative Mid-Small Enterprises (SME) registered in the PMInnova Program [START_REF]agremento Politecnico di Torino -Gruppo Bnca di Asti, A. Villa Responsible[END_REF], the ongoing trend toward the individualization and even personalization of products results in new additional challenges for industrial enterprises in the frame of "open innovation" [START_REF] Gassmann | The future of open innovation[END_REF], i.e. with wide supports from externals.

To this scope, Crowd Engineering must set the following objectives:

• Establish new design approaches, strategies, methods and tools for the cocreation of innovative, individualized products by opening the product creation to the "crowd"; Realize an efficient procedure to collect, select, integrate contributions, such to obtain a good overlapping of the set of collaborative selected contributions and the desired scheme of the innovative product. These three objectives can be achieved by developing the Crowd Engineering approach in a user-centric way, i.e. with a strong direction of the multi-dimensional design process implemented by an institution, institute or company, having a clear idea of the innovative product to be obtained and a considerable ability to define a "call for innovation creation" to a set of potential contributors.

The organization of the paper will be as follows. Section 2 is dedicated to give a preliminary logical overview of the Crowd Engineering concept and an outline of its structure. Section 3 first describes a schematic model of Crowd Engineering, based on the analysis of its analogy with the Supplier Relationship Management. Section 3 will present a schematic model of Crowd Engineering, by outlining the theoretical methods for supporting the multi-dimensional selection. Finally, Section 4 will present some hints of a research agenda, based on a Crowd Engineering work-flow scheme.

Preliminary Logical Overviews of Crowd Engineering

The Crowd Engineering procedure aims to focus, structure and translate into practice new ideas dedicated to collaborative co-creation. It is obtained from a process of collecting contributions from various sources (people, associations, SMEs, etc.), their selection and their integration for the purpose of conceptual and detailed design, the development of the necessary production operations, the production of new products oriented to the user. Crowd Engineering is based on the advancement of the wellknown triple helix towards a quadruple helix for innovation systems (see Fig. 1). The classic triple-helix from 1995 knows only three actors. But emerging innovations do not necessarily match consumer demand, so the helix has to be extended by a by a »user« component, involving end users/consumers in the innovation process. Therefore, additional attention has to be paid to community-based approaches, originated by "collaborative network", that appears to be powerful social frames for value creation [START_REF] Camarinha-Matos | A Comprehensive Modeling Framework for Collaborative Networked Organizations[END_REF].

Fig. 1. Quadruple helix for innovation systems

Therefore, the Crowd Engineering project is stated by a "call for innovation creation" with the scope of searching and collecting contributions from many "Contributors" in order to integrate them so as to obtain a product (system or object) with characteristics of total novelty, structure and forms that allow production, all set by the Crowd Engineering Project Management (named in the following simply as "Manager"). The goal of the Crowd Engineering problem, as defined above, is advertised by the Manager in a broad way, in order to be able to receive contributions from many Contributors. Each Contributor proposes his own contribution, without knowing the contributions of the others or their participation in the research launched by the above mentioned "call". Therefore, the Contributors are potentially competitive. The Manager must have a "measure of usefulness" in order to verify if a contribution provided by an actor can be useful for the solution of the Crowd Engineering problem, in the sense that it can contribute to the achievement of the Crowd Engineering project objective. To this end, the Manager must evaluate each individual contribution obtained by each Contributors, and perform a multidimensional selection such as to collect only contributions with the following characters:

• A contribution must be "active" i.e. such to give rise to information/data that are coherent with some part of the innovative product or some operations that can contribute to the innovative product creation; this first attribute of a contribution can be evaluated according to the adopted measure of usefulness, above mentioned; • Two or more contributions must be "collaborative", i.e. such to be usable in collaboration with other contributions, thus generating a more effective and active action in the design and production process; this further attribute of a pair of contributions can be evaluated by adopting a

Private actors

User Public Actors

Knowledge institute

Innovation object

"measure of similarity" between the two contributions, with respect to the result of the "problem", that is to some part of the innovative product or to some innovative operation necessary to produce it. From a simplified point of view, the Manager, once evaluated as useful the contribution will be, could consider a second different contribution to understand if the two contributions are collaborative: their joint use facilitates the achievement of the Crowd Engineering goal in a more efficient and effective way with respect to the individual ones. Once recognized a pair of collaborative contributions, the Manager will evaluate to support the couple with a third contribution, by estimating the joint use of the three in terms of an increasing -if any -of the measure of collaborative utility. Progressively, the Manager can reach a complete set of contributions, all complementary, such as to express an admissible solution for the Crowd Engineering project. The logical Crowd Engineering overview briefly described above, has the sole purpose of illustrating in a simplified way the concepts and methodology of the problem. Indeed, it makes evidence of the combinatorial nature of the contributions' selection problem.

Schematic Model of Crowd Engineering

A schematic model of the Crowd Engineering approach can be obtained by the analogy between the Crowd Engineering and the Supply Relationship Management (Section 3.1). This first analogy suggests taking also into account the evident links between Crowd Engineering and Crowdsourcing, as well as with "Collaborative Networks" (Section 3.2).

Analogy between Crowd Engineering and Supply Relationship Management

An enterprise performance, especially of small and medium-sized, largely depends on the relations with its suppliers, often belonging to different value chains, as in several industrial districts analyzed in [START_REF] Teresa | Using collaboration management in industrial clusters -case study of Italian energy cluster[END_REF][START_REF] Agostino | From industrial districts to SME collaboration frames[END_REF]. Then, a good enterprise-suppliers relationship is a necessity for any industrial organization, to be able to respond to dynamic and unpredictable chains of the final products demand [START_REF] Antonelli | Conditions for Effective Collaboration in SME Networks Based on Graph Model[END_REF][START_REF] Antonelli | Graph-based models to classify effective collaboration in SME networks[END_REF]. Therefore, a Supplier Relationship Management (SRM) is a methodology that organizes all the interactions of the enterprise with third-party organizations, which supply goods and services in order to allow the best possible product creation [START_REF] Chandra | Supply chain management in theory and practice: a passing fad or a fundamental change?[END_REF]. The evaluation of a supplier is then the process of measuring the performance of the suppliers itself, as well as of its capability to meet the buyer (i.e. the enterprise) demands. Tacking now into account the above logical description of the Crowd Engineering approach, it is possible to identify a strong analogy between the two processes, as shown in Table 1. Therefore, it is to use the SRM approach to give a schematic illustration of the Crowd Engineering procedure.

Relations of Crowd Engineering with Crowd-sourcing and Collaborative Networks

In order to make evidence of the strict relation between Crowd Engineering and Crowd-souring, the definition of the latter as reported in [START_REF] Buecheler | Crowdsourcing, open innovation and collective intelligence in scientific method: a research agenda and operational framework[END_REF] is here referred to: "Crowdsourcing is the act of taking a job traditionally performed by a designated agent (usually an employee) and outsourcing it to an undefined, generally large group of people in the form of an open call." [START_REF] Howe | Crowdsourcing. Why the power of the crowd is driving the future of business[END_REF].

In practice, Crowdsourcing is a powerful tool because it describes collaborations both in research and in design actions which can significantly enlarge both the group of (potential) scientific partners, and the team of designers. With regards to the scientific context, Crowd sourcing implies to fist clearly identify the problem to be solved by the crowd, and then to plan a reasonable balance between natural antagonisms of contributors. Therefore, Crowdsourcing makes evidence of some important, and also critical aspects, of Crowd Engineering that, with respect to the former, now it appears to be the operative practical version. Referring now to relations between Crowd Engineering and Collaborative networks, among the different variety that the latter assumes in industry and services (see [START_REF] Camarinha | Collaborative networks in industry and services: research scope and challenges[END_REF]), its aspect of "collaborative engineering" is concerning teams of technicians and engineers belonging to different companies and cooperating together on a common significant project, thus sharing skills and experiences, thus moving towards the creation of a "virtual community".

Therefore, the existence of a collaborative network is a very useful prerequisite for a company intending to start a Crowd Engineering project. In fact, the Collaborative network can become the area of first and fundamental diffusion of the "call for innovation creation", providing the most favorable environmental conditions for the launch of the Crowd Engineering project itself. A verification of this occurs in the next Session, where the operational scheme of a Crowd Engineering project is outlined, especially in the selection phase of the contributions and acceptance of the new ideas, two key phases of such a project.

Crowd Engineering Operational Scheme

As for SRM, also in case of Crowd Engineering, for an effective collaboration, Manager and contributors (i.e., suppliers of contributions for the innovation required by the Manager) need to share profits in order to achieve a win-win situation. To come to an effective and profitable collaboration/integration of contributions, a Crowd Engineering operational scheme is mandatory [START_REF] Viroli | Efficient Engineering of Complex Self-Organising Systems by Self-Stabilising Fields[END_REF][START_REF] Groen | Towards Crowd-Based Requirements Engineering A Research Preview[END_REF][START_REF] Snijders | Crowd-centric Requirements Engineering[END_REF]. Such a scheme is illustrated in Fig. 2. It is just the representation of the Table of correspondences, being derived by SRM scheme illustrated in [START_REF] Seminathan | Analysis of Supplier Relationship Management Model using AHP[END_REF], but specifically adapted to the Crowd Engineering concept. The scheme is self-explanatory. The scheme inputs are the contributions sent by the "crowd", that is from the various types of suppliers of innovative ideas, in large numbers. The "heart" of the Crowd Engineering scheme is the Selector which, in accordance with the steps shown in the previous table, consists of the following parts:

(1) evaluation of each contribution and selection of each one useful among them by evaluating an associated "measure of usefulness" that represents the coherence of the contribution with the project goal and a "measure of complementarity" for each couple of contributions, as defined in Section 2;

(2) integration of each selected contribution within the description of the parts (components) and operations (of production) of the innovative product to be created; (3) evaluation of the overall correspondence among the selected contributions and all the parts and all the operations of the innovative product. The Manager is operating in the final block of the scheme, with the following aim:

(4) verifying the problem result, that is an admissible global correspondence among the selected contributions and all the parts and all the operations of the innovative product;

(5) evaluate the real feasibility of the hypothesis of an innovative product obtainable from the integration, bearing in mind that different additions (with different uses of the contributions) are possible even though they obtain the same final product. ( 6) evaluate costs and revenues in each case produces an innovative product among the feasible ones; (7) evaluate the usefulness and the cost of every useful contribution received, to offer a profit to those who have helpfully responded to his call. To implement its functions, the Manager receives as input:

• selected useful contributions;

• proposals for innovative products developed by the Selector. It also interacts with the Warehouse Management System, for the needs of components, and with the Quality Management System, to estimate the performance of the resulting innovative products.

Some Hints for a Research Agenda

The development of the Crowd Engineering approach to select the best possible set of contributions from the "crowd" for innovative products creation, is one of the more challenging lines of evolution for smart enterprises.

To offer some considerations that could be utilized by experts when the needs for innovation become so important and critical for the survival of the enterprise, some ideas for the application of the Crowd Engineering approach is now presented, as a sequence of Work Phases (i.e. a Work-flow), summarized in the following Table 2. Indeed, a Manager needs to have a detailed description of the sequence of phases to be applied, starting from the definition and description of the innovative product desired, up to the Crowd Engineering organization and use. This simplified workflow suggests some hints for future research lines in which a comprehensive view of the Crowd Engineering, Crowd-sourcing and Collaborative network could contribute to a real innovation of the creation process of new products.

According to [START_REF] Buecheler | Crowdsourcing, open innovation and collective intelligence in scientific method: a research agenda and operational framework[END_REF], some main research lines can be envisaged, for assuring a useful and significant development of Crowd Engineering and its practical implementation in industrial and service frames: a) identification of robust methods to identify and select fruitful contributions for a given innovation project goal, such to be clearly transferred to the crowd and understood by each potential contributors; this will characterize the communication power from the innovation project Manager and the wide range of individuals and entities that could give really new ideas, in a form to be recognized and integrated by the Manager itself; b) selection and clear communication of incentives (or earnings) for the individual contributors, clearly related to the usefulness of the contribution and its integration with the rest, and finalization to the goal of the project; c) promotion of healthy competition among contributors, while preserving the anonymity of contributions and guaranteeing their ownership, especially as the project takes shape and the integration of contributions will become increasingly evident (as is the exclusion of contributions of little value or not useful); d) the correct evaluation (above all in economic terms) of the theoretical contributions and their validation, especially in the case of particularly innovative contents; similar considerations apply to the evaluation of contributions with a rapid practical impact; e) Finally, the organization of a structure for managing the interactions of the Manager (or project team) with the crowd, through a structure that manages the center-contributor relations clearly but preserving the privacy of each one.

Fig. 2 .

 2 Fig. 2. The SRM-based scheme of the platform specifically adopted to the Crowd Engineering model.

Table 1 .

 1 Correspondences between Crowd Engineering and Supply Relationship Management.

	Phases

and Actors of Crowd Engineering Phages and Actors of Supply Relationship Management

	Actors:					Actors:
	Contributors				Suppliers
	Manager (with clear view of the	Producer (with clear view of the final
	innovation)					product)
	Phase1. Identify contributions		Phase 1. Specify the purchase strategy
	Phase	2.	Select	the	useful	Phase 2. Evaluate the supplier
	contributions				performance
	Phase 3. Integrate the selected	Phase	3.	Make	collaborative-
	contributions into the innovative product	integrated the Suppliers with respect to
	description					the final product
	Phase 4. Evaluate the global set of	Phase 4. Evaluate the feedback from
	contributions.				the producer
		IF necessary, iterate			IF necessary, iterate

Table 2 .

 2 Outline of the Crowd Engineering workflow.

	N°	Scope			Description	Documentation
	Work	Call-for-			Definition	of	a	Document with
	Phase 1	contributions,		descriptive framework of	clear unambiguous
		referred to the a-priori	the	a-priori	selected	presentation of the
		selected	consumer	consumer goods type,	consumer goods
		goods type.			to be used as a reference	type.
					by: potential contributors,
					i.e. people or organizations
					-as above -who intend to
					participate in the call,
					sending their contributions.
	Work	Strategies	to	Policies, strategies and	(A)Communicati
	Phase 2	manage the crowd of	initiatives in order to	on	protocols,
		contributors,	by	leverage the crowd, that	managed by Crowd
		creating		a	means to gradually create	Engineering

Acknowledgments. This research has been developed in the context of the PMInnova Program (www.pminnova.eu).


Günther Schuh

Violett Zeller

Max-Ferdinand Stroh

Philipp Harder
email: philipp.harder@fir.rwth-aachen.de

Finding the Right Way Towards a CPS -A Methodology for Individually Selecting Development Processes for Cyber-Physical Systems

Keywords: CPS, Development Process, Agile Development

Numerous traditional, agile and hybrid development approaches have been proposed for the development of CPS. As the choice of development process is crucial to the success of development projects, it has become a major challenge to identify the best-suited process. This paper introduces a methodology for identifying the best-suited CPS development process, based on the individual boundary conditions for a certain development project within a company. The authors used a set of eight indicators to assess a CPS-development project. The results of the assessment were matched with CPS-development approaches. Based on the matching results a best-suited development process was selected. The application is shown for a use case in the German manufacturing industry. The developed method aims to reduce the risk of project failure due to the wrong choice of development process.

Introduction

Industry 4.0 and digitalization are transforming our companies. In order to keep pace with this development, companies are forced to transform their products and systems from mecha(tro)nical into Cyber-Physical Systems (CPS) [START_REF] Schuh | Industrie 4.0 Maturity Index. Managing the Digital Transformation of Companies[END_REF]. CPS connect the (real) physical world with the (virtual) cyber world. They are connected and consist of actuators and sensors, as well as a human machine interface to interact between the physical and the cyber world. They are empowered to assist humans in their decision making process and may even act autonomously. Therefore a CPS may span from a single machine to a whole (connected) production site. [START_REF] Jordan | Requirements-Based Matching Approach to Configurate Cyber-Physical Systems for SMEs[END_REF] Different development processes from conventional, hybrid to agile have been proposed in the past. However, there is no best suited process for the development for all types of CPS [START_REF] Eigner | Modellbasierter Entwicklungsprozess cybertronischer Systeme[END_REF][START_REF]Handbuch Industrie 4.0. Geschäftsmodelle, Prozesse[END_REF]. It is more likely that for every development project one individual process will solve the trilemma of providing a solution with the best quality at the lowest cost with the shortest time to market [START_REF]Pahl/Beitz Konstruktionslehre[END_REF].

CPS are the backbone of Collaborative Networks as well as the drivers for Digital Transformation. Thus, the choice of development process is a crucial aspect within the realization of Collaborative Networks and Digital Transformation. As the right choice of development processes is also crucial to the success of a development project, it is very important for a company to select a process that will fit to their individual boundary conditions [START_REF]Handbuch Industrie 4.0. Geschäftsmodelle, Prozesse[END_REF]. Currently there is no methodology to select a development process for CPS based on the boundary conditions of the company. For this reason, the aim of this paper is to present a methodology to select the best-suited development process based on the individual boundary conditions in order to close the identified research gap.

To do so, a short introduction into the different development processes is given and a set of relevant CPS development processes is identified. Afterwards a set of indicators to define the level of agility for a project is selected. The set of indicators is used as a means of assessment for a development project in order to identify the best-suited development process. The application is demonstrated for a CPS-development use-case in the German manufacturing industry.

The overall goal of the paper is reflected in the research question: "How can the bestsuited development process for a CPS development, based on the structured assessment of the individual boundary conditions, be selected".

For the overall research, case-study research by EISENHARDT [START_REF] Eisenhardt | Building Theories from Case Study Research[END_REF] will be applied. The case-studies help selecting the relevant models for the development of CPS as well as determining the indicators for identifying the level of agility for the different models. Furthermore, they will be used to validate the results of the assessments. For this paper the focus was set on building a first prototype of the methodology in order to prove its relevance. Therefore the content of the methodology is based on literature research and own constructs. The methodology is applied to one case-study. Future research will then evaluate and enhance the indicators, the development processes and matching in detail, based on several case studies.

Background

Manufacturing companies generally use development processes in order to support their product development. The development processes describe the processes and activities within the development step by step. There is a variety of development processes, which are suitable for different purposes and boundary conditions. [START_REF]Handbuch Produktentwicklung[END_REF] In general, development processes can be divided into three groups: conventional, agile and hybrid. Fig. 1 shows the direction of progress within the three approaches.

Hybrid

In conventional development approaches, the product development process is split into different phases that strictly follow each other. Once a previous phase is completed, a subsequent phase begins. Hence, in conventional developments, the progress follows the four phases plan, conceptualize, design and develop sequentially, as shown in Fig. 1. [START_REF] Boehm | Balancing agility and discipline. A guide for the perplexed[END_REF] However, using the strictly sequential approach of conventional development processes in flexible development environments with volatile requirements can be quite challenging. In order to control flexible processes, agile concepts were introduced in the field of software development and have partially been transferred to physical product developments by now [START_REF] Gloger | Scrum in der Hardwareentwicklung[END_REF]. Compared to conventional development processes, agile development processes are less structured and aim to respond flexibly to new requirements, insights and customer feedback that may arise in the course of the development [START_REF]Projektmanagement und Vorgehensmodelle 2014[END_REF]. Thus the development progress in agile projects runs parallel in the four development phases (Fig. 1) [START_REF]Agile methods for design to customer[END_REF].

Besides conventional and agile approaches there is a third category called hybrid, which has evolved from combining these two [START_REF] Kuhrmann | Hybrid Software Development Approaches in Practice: A European Perspective[END_REF]. By combining the concepts, advances from both approaches, such as stability and flexibility, can be used simultaneously, leading to promising development processes especially for highly complex products, e.g. for the development of Cyber-Physical Systems [START_REF]Hybride Softwareentwicklung. Das Beste aus klassischen und agilen Methoden in einem Modell vereint[END_REF]. Combinations to form a hybrid development process are not limited, a wide variety of patterns can be created by combining any conventional with any agile process [START_REF] Kuhrmann | Software and system development in practice: Waterfall, Scrum, and beyond 15[END_REF]. Several procedures can be varied within a project structure according to the situation in order to implement the project-specific requirements in the most suitable way [15]. The direction of progress in hybrid projects is neither strictly sequential as in conventional projects, nor entirely parallel in all four phases as in agile concepts (Fig. 1).

Description of the Methodology

The developed methodology for individually selecting development processes for Cyber-Physical Systems is shown in Fig. 2. It is divided into four phases, which are executed in the displayed order. In phase one the given project is subdivided into several subprojects. The division into subprojects is done in order to reduce the complexity of the overall CPS development. The number of subprojects is not fixed but should be chosen appropriate to the project's size.

Decision on devel. process Matching

Phase two is the assessment of the project which is conducted during a workshop with the participants of the project. In detail, each of the subprojects defined in the first step is assessed by using a profile as means of assessment. The profile consists of different indicators, which indicate agility or conventionality depending on the assessment. The set of indicators is presented in the following chapter (Table 1).

In phase three the developed matching algorithm is applied to the assessed subprojects. The algorithm counts the number of matches of each subproject with each of the development processes in the system.

In phase four, the matching results are presented. The most suited model for the overall project is selected by comparing the matching results of the different subprojects. Besides selecting a single model, it is also possible to combine different development processes into a comprehensive one. Thus, universal hybrid concepts can be designed which are well suited for the given boundary conditions of the project.

Indicators for the Choice of Development Process

There are already several approaches presenting indicators to identify the level of agility for development projects. Some of them offer a quantitative analysis but are derived from experience (e.g. [START_REF] Boehm | Balancing agility and discipline. A guide for the perplexed[END_REF]). Other indicators are of a qualitative form and do not fit the use as an assessment methodology (e.g. [START_REF] Welge | Integration von agilen Methoden in der Systementwicklung[END_REF]). The set of indicators selected for this paper from DIELS were derived from a literature research, follow a quantifiable scale and cover internal and external indicators [START_REF] Schuh | Methodology for Determining Agile Product Scopes in Development Projects[END_REF]. DIELS developed a set of eight indicators for determining agile product scopes. The identified project-relevant indicators stand either for or against the use of agile methods in the product development, depending on their characteristics (see Table 1). The indicators are divided into (five) internal and (three) external ones, depending on whether they can be controlled by the company or not. All of the indicators of DIELS have four different characteristics, graded in three-steps from plan-driven (value 0) to agile development (value 9), which are shown in Table 1. [START_REF] Schuh | Methodology for Determining Agile Product Scopes in Development Projects[END_REF] Table 1. Indicators for determining agile product scopes by Diels [START_REF] Diels | Indikatoren für die Ermittlung agil zu entwickelnder Produktumfänge[END_REF] Indicators / Rating 0 (plan-driven) For the development of the methodology for individually selecting development processes for Cyber-Physical Systems the approach of DIELS was chosen as a basis. DIELS'S indicators were identified during a comprehensive literature research and a following systematic consolidation, thus they fully meet the demand for projectspecific boundary conditions. In addition, this approach distinguishes between plandriven, agile (and hybrid) approaches and allows a quantifiable evaluation. Furthermore, DIELS'S approach presents a set of indicators specifically designed for determining which product scopes can be developed using agile concepts. Transferring the agility indicators to characterize both development processes and subprojects can be accomplished without further modification.

Selected CPS-development Processes

For developing the methodology a total of nine conventional, hybrid and agile development processes were selected, which are listed and categorized in Table 2. The selection was carried out on the basis of statistics on distribution of the models [START_REF] Komus | Status Quo Agile. Studie zu Verbreitung und Nutzen agiler Methoden Eine empirische Untersuchung[END_REF][START_REF] Theocharis | Is Water-Scrum-Fall Reality? On the Use of Agile and Traditional Development Practices[END_REF]. The statistics on hybrid development processes were less clear, since in principle any combination of a conventional and an agile process would be possible. Hence, for the development of the methodology, hybrid models that have been described in literature or applied in practice were selected. Generally, further development processes can be added to the methodology independent of their nature (agile, hybrid, conventional).

For each development process the value of the characteristic, which describes it most accurately, was assigned according to the agility indicators of DIELS in Table 2. Low values represent plan-driven development (value 0), whereas high values represent agile development (value 9). The classification of the models was based on a literature research. As it is a first approach, the classification be detailed and validated in future research. The sources used for classification are mentioned in brackets next to the respective process in Table 2. Table 2. Categorized conventional, hybrid and agile development processes using the agility indicators of DIELS [START_REF] Schuh | Methodology for Determining Agile Product Scopes in Development Projects[END_REF] Dev. Processes / Indicators (a

) (b) (c) (d) (e) (f) (g) (h)

Description of the Matching Process

During the matching process, the characteristics of the defined subprojects are matched with the characteristics of all development processes one after the other, as shown in the example in Table 3. The number of matches with each development process is counted and can be used as an indicator for the suitability for the subproject. In the displayed example the given development process would have a total of four out of eight possible matches with the subproject, leading to a suitability value of 50 %.

Discussion of the Results for a Use-Case

The methodology was applied to a medium-sized technology company in Germany. The overall goal of their development was to design and build an IoT factory. In this case, IoT Factory refers to a factory with connected assets, such as machines and transportation systems allowing data based production control and autonomous actions. This is in alignment with the definition of CPS given in chapter 1 of this paper. Thus the "IoT Factory" can be considered a CPS (consisting of several sub-CPSs) in its entirety. The main benefits of this factory are to reduce lead times and realize batch size one. This will be reached by a high level of automation and connectivity for the different steps within the production line. The new factory will be implemented into a supply-chain of conventional "non-IoT" factories. Due to a large number of undefined requirements and the future orientation of the project, the choice of development process was not obvious. At this point, the methodology presented in chapter 3 was applied in order to individually select a development process for the project.

The first step was to divide the project into four subprojects: Production Machine Design, IT Systems, Intralogistics, and Construction. IT Systems refers to the relevant IT-Systems for controlling the production environment (e.g. ERP, MES). Usually the subprojects require competencies from different disciplines, such as IT, mechanical and electrical engineering for the Production Machine Design.

Every subproject was then assessed with the set of indicators presented earlier. Table 4 gives an overview of the assessment results.

Based on the matching results for the individual subprojects a coherent development process for the overall project had to be defined (phase 4). Subproject one to three all showed the highest suitability for the hybrid Scrum-V-Model, combining an agile project phase in the beginning with a conventional project phase for final deployment of the results. The selected processes suit the use case quite well, as the development goal is an IoT Factory, which requires both, a high level of innovation (Scrum), as well as a high level of accuracy and stability in the deployment phase (V-Model).

For subproject four, which refers to the construction of the factory as well as the physical placement of the assets within the factory, a plan-driven process is also very well suited. Especially building projects require a high level of planning and accuracy as most of the steps taken in the processes may be irreversible in the end. Due to its strong focus on planning, a waterfall process can easily be integrated into the V-Model phases of subprojects one to three. The selected development processes were implemented in the project as proposed by the presented methodology.

In summary, a very well-suited development process for the presented use case could be identified with the presented methodology. This shows that the proposed methodology can be used in order to identify the best-suited development processes.

Future research will consider further case studies in order to enhance the proposed methodology. Based on that, the indicators, choice of development processes as well as the matching algorithm, can be further refined. As the selection of the development process currently requires a lot of detailed knowledge, future work will also focus on automatically finding and composing a development process along the different subprojects.

Conclusion

This paper introduces a methodology for selecting the best-suited CPS development process based on the individual boundary conditions at a company. In beginning conventional, hybrid and agile development processes are introduced. Afterwards a set of indicators for the choice of the development process on a scale from conventional over hybrid to agile are selected. A selection of CPS-development processes is then classified within the identified set of indicators. The same set of indicators is then used as a means of assessment for the boundary conditions of CPS development projects. Therefore the development processes, which were typed with the set of indicators, are matched with the results of the assessment of the development project. In order to reduce complexity, the assessed project is divided into subprojects that are assessed on their own. Based on the matching results an individual development process is selected for every subproject. The results are combined to an overall development process for the assessed development project. For this paper, the presented methodology was applied to a case-study from a German manufacturing company.

Fig. 1 .

 1 Fig.1. Direction of progress in conventional, hybrid and agile projects[START_REF]Agile methods for design to customer[END_REF]

Fig. 2 .

 2 Fig. 2. The four steps of the developed methodology

Table 3 .

 3 Example of the matching process of a subproject with a development process

	Indicators / Rating	0	3	6	9	Indicators / Rating	0	3	6	9
	Internal	Solution space Prototype manuf. Resources Technology ability					Extern	Market relevance al Market accuracy Market volatility = characteristic of the dev. process
		Corporate culture						= characteristic of the subproject

On average, subproject 03 had the highest ranking on a scale from conventional to agile development. However, none of the projects were rated strongly towards agile approaches. Most of the ratings were within the range of the hybrid development processes. An interesting result in the assessment was that the subproject IT-Systems was rated less agile than the Production Machine Design. Hence showing that not only the development goal is relevant for the choice of the development process but also other boundary conditions such as corporate culture. As different departments may be involved in the subprojects, indicators may also differ between the different suprojects.

In General, CPS projects require interdisciplinary teams. That is why it is very important to have an assessment of every subproject, as the team composition may differ by discipline (Engineerg, IT, etc.) as well as the department involved (R&D, Prodcution Management, etc.). If the selected model does not support the team composition the project is likely to fail. Fig. 3 shows the matching results for the development processes for the assessed usecase. For all development processes selected in section 3.2, the suitability value was calculated and all development processes were listed in descending order of suitability.

For subproject one to three, the hybrid Scrum-V-Model shows the highest rate of suitability. Generally, the processes leaning towards strong agile or conventional development have a lower number of matches. Based on the average assessment results which were all between 3.75 and 4.88, which is mostly in the hybrid range, the result was expected and plausible.

For subproject four, the Waterfall Model has the highest number of matches. However, this subproject was not grasped by the methodology very well, as there were only three matches, resulting in an overlap of just 38 percent.


Alexandra Tenera

João Rosas
email: jrosas@uninova.pt

Collaborative Networks Management from a Theory of Constraints Perspective

Keywords: Collaborative Networks, Theory of Constraints, Critical Chain Project Management

Collaborative networks are organizational structures that, instead of expressing market behavior, their formation and operation are based on principles of collaboration, where trust, reliability, and commitment between partners prevail. These principles allow collaborative networks to share risks and become more competitive. Collaboration-based strategies are increasingly important in the face of a growing demand for new and more sophisticated services and products, posing significant challenges for companies that must struggle to fulfill. In this sense, companies need to adapt their business strategies, so they can react and keep up with the pace of change. In this work, we propose a new perspective from the Theory of Constraints in Collaborative Networks Management. The adaptation of the TOC's Five Focusing Steps and TOC Thinking Process, combined with the Critical Chain Project Management (CCPM) approach, are proposed to improve Collaborative Networks Management. CCPM is brought into a collaboration context to deal with project network uncertainty. A preliminary motivation example is shown in this position paper, aiming at illustrating this prospective approach in Collaborative Networks Management.

Introduction

The increasing level of market globalization is requiring the creation and development of ever more innovative products and services. Competitiveness, innovation, risk, sustainability, resilience, and flexibility are such terms that are increasingly being considered when reflecting on the general state of organizations, countries' economies and even nations, whose results are grounded on the performance of their productive systems. While, in many sectors of activity, increased competitiveness may be related to the modernization of processes associated with technological advances, in others, success may be related, above all, to how companies organize themselves and manage their productive systems.

In this context, Project Management and Innovation can contribute to the success of organizations, providing a contribution to increasing performance and improving countries' economies. Innovation projects, if well managed, will allow technological and organizational development and increasingly sustainable solutions which can be obtained through Collaborative Networks (CN) with high added value efficiently using available resources, skills or competencies in ever shorter development cycles.

As a result, the intrinsic characteristics of projects (by definition, unique and temporary), along with the dynamics of organizations and markets, contribute to the fact that change and uncertainty is inevitable. This happens both at project level (e.g. variations in programmed durations, unavailability of resources or materials) and at organizational level (e.g. by limitations of appropriate mechanisms for decision support or sharing information or competences). Considering these aspects, the application of the Theory of Constraints (TOC) in Collaborative Networks Management (CNM) is proposed in this position paper.

Assuming this TOC-based perspective into CNM, we could stipulate that there is always at least one constraint affecting the performance of a CN. Therefore, identifying and exploring this constraint will eventually make possible to subordinate it to the set of CN partners that are most capable of mitigating the mentioned constraint. In this way, the hypothesis that is being explored is that CNM can be improved by applying the principles of TOC into CNs.

In next chapter, a brief introduction to the Theory of Constraints, their corresponding POOGI, and TOC Process Thinking for problem resolution, as well as the Critical Chain Project Management for project and change implementation. In chapter 3, a few directions on how TOC could be used in Collaborative Networks Management are then addressed. Finally, the main conclusions and some points to be addressed in the future work are proposed.

Introducing the Theory of Constraints

In this section, we will begin by introducing fundamentals concepts and approaches of the Theory of Constraints, bounding the scope to the main aspects that can contribute to its application in Collaborative Networks.

The TOC Core Concepts

The Theory of Constraints, as presented by Goldratt in 1990 [START_REF] Goldratt | What is this thing called Theory of Constraints and how should it be implemented?[END_REF], has evolved methodologically as well as in its implementation domains [START_REF] Spencer | Optimum production technology (OPT) and the theory of constraints (TOC): Analysis and genealogy[END_REF] since its first publication [START_REF] Goldratt | The Goal: A process of ongoing improvement (1st ed)[END_REF]. Along their evolution, TOC has presented several designations over time.

Initially, it was associated to the "Optimized Production Timetable" (OPT) scheduling, but "Timetable" was later replaced by "Technology" [START_REF] Spencer | Optimum production technology (OPT) and the theory of constraints (TOC): Analysis and genealogy[END_REF]. It was also associated with other designations, such as Synchronous Production or Constraints Management (CM), which should be used in their specific domains [START_REF] Mabin | The performance of the theory of constraints methodology: Analysis and discussion of successful TOC applications[END_REF]. TOC is nowadays used as a management paradigm, theory or philosophy, as it includes their own concepts, principles, methods and tools [START_REF] Dettmer | Goldratt's Theory of Constraints: A Systems Approach to Continuous Improvement[END_REF][START_REF] Gupta | Theory of constraints: A theory for operations management[END_REF][START_REF] Gupta | Fundamental Concepts of Theory of Constraints: An Emerging Philosophy[END_REF].

The TOC assumes that in any system, there is always at least one constraint affecting its performance, and that eliminating or attenuating this constraint will increase the system performance. The rationale for this "at least one constraint hypothesis" is that if a system had no constraints, then its performance could increase indefinitely, but this is not possible [START_REF] Goldratt | What is this thing called Theory of Constraints and how should it be implemented?[END_REF]. The focal point of the TOC thus resembles Liebig's law, when he states that the growth of a system is not controlled by all available resources, but by the less abundant resource, which is intended as a limiting factor [START_REF] Stamm | TOC, lean and six sigma-Evolution of manufacturing methodologies under the paradigm shift from Taylorism/Fordism to Toyotism[END_REF].

Therefore, in the TOC perspective, contrary to what is commonly assumed, the existence of constraints should not be seen as negative, but rather an opportunity for focusing management actions and decisions on system improvement. As a constraint establishes the maximum performance of a system, its reduction translates directly into improved system performance.

According to the TOC, any organization can be considered a system, i.e. aggregation of interrelated elements, with defined purposes and objectives to support value creation: typically, more profit for stakeholders and more sustainable service level for organizations. A system can also be viewed as a network of interacting processes, not just a set of processes, in which the performance and survival of a system depends mostly on how its processes interact rather than their individual and local capacity or performance. Once the purpose of each system's component has been defined, the TOC concentrates all its efforts on promoting improvements that directly translate into system purposes or objectives and, inevitably, into increasing overall performance. These advantages may even increase, when TOC is combined with other management paradigms [START_REF] Demchuk | Combined Usage of Theory of Constraints, Lean and Six Sigma in Quality Assurance of Manufacturing Processes[END_REF].

In TOC, several types of constraints can be identified [START_REF]Theory of constraints Handbook[END_REF][START_REF] Mcmullen | Introduction to the Theory of Constraints (TOC) Management System. Constraints Management Series[END_REF][START_REF] Sproull | The ultimate improvement cycle: Maximizing profits through the integration of Lean, Six Sigma and the Theory of Constraints[END_REF][START_REF] Watson | The evolution of a management philosophy: The theory of constraints[END_REF], typically classified into: (a) physical (resources unavailability, as an example) and (b) strategic, political and organizational constraints (such as rules, regulations, procedures, lack of information, etc.). The physical constraints are the easiest to identify, as their effects can be seen through direct observation. On the other hand, the identification of nonphysical constraints can be more difficult to distinguish and manage. In addition, aspects like human skills, behaviors, and attitudes, whether individual or collective, can also be included in this non-physical category.

These constraints may also be considered internal or external to the system. A typical external constraint is the market itself. As such, when a production system has more capacity than the required by market, the constraint becomes external. Whenever corresponding balancing and changes are done, the improvements allow reviewing market share and to look for new opportunities. Organizations should concentrate on capitalizing on these new competitive advantages, instead of focusing on continuous improvement in their internal operations.

Furthermore, it is commonly assumed that in service organizations physical constraints are less relevant than organizational ones [START_REF]Theory of constraints Handbook[END_REF]. As highlighted in [START_REF] Rahman | Theory of constraints -a review of the philosophy and its applications[END_REF], it is usually necessary a full elimination of organizational constraints to boost organization results.

The TOC Thinking Process Logic

From the TOC perspective, any system performance improvement is based on Five Focusing steps known as the Process Of On Going Improvement (POOGI), which can be synthesized as: (1) identify, (2) explore the constraint, (3) subordinate, (4) elevate the constraint, i.e. improve performance and (5) evaluate the changes made and overcome inertia.

The framework is implemented using TOC specific tools, such as TOC Thinking Process (TOC TP), performed in a closed loop of continuous improvement, as shown in Fig. 1. Organizations can be seen as dynamic systems, which undergo changes for their improvement and survival [START_REF] Reid | Applying the TOC TP: a case study in the service sector[END_REF]. Although TOC TP is not in the literature traditionally associated with change management, it may support it providing new business perspectives, increasing the managers' sense of control, and allowing more proactive actions [START_REF] Mabin | Harnessing resistance: using the theory of constraints to assist change management[END_REF]. Therefore, the TOC TP presents itself as one of the TOC features with the greatest potential for research exploration [START_REF] Mabin | The performance of the theory of constraints methodology: Analysis and discussion of successful TOC applications[END_REF][START_REF] Kuruvilla | Theory of Constraints and the Thinking Process[END_REF][START_REF] Taylor | Applying Theory of Constraints principles and Goldratt's Thinking Process to the problems associated with inventory control[END_REF].

The TOC in Project Management

TOC principles applied to Project Management practices, the Critical Chain [START_REF] Goldratt | Critical Chain[END_REF] was introduced by Goldratt in 1997, and more conceptuality detailed later on [START_REF] Leach | Critical chain project management improves project performance[END_REF][START_REF] Leach | Critical chain project management[END_REF][START_REF] Newbold | Project management in the fast lane[END_REF]. This TOC tool is currently known as Critical Chain Project Management (CCPM). CCPM can be applied in products or services development projects. Whenever a project is planned, several generic objectives are commonly considered, namely: duration (deadline), cost (budget), resources (materials, equipment, …) and competencies, according to defined specifications or requirements. Among these objectives, time is particularly relevant, as it is a non-cumulative resource, i.e., whether it is used or not, it is spent and cannot be reproduced, resulting in unrecoverable loss of opportunity if not properly exploited.

CCPM applies TOC principles to project scheduling, allowing the best management project duration and resource utilization, while also promoting human resources behavior change. In fact, an effective management of the project execution time, was already highlighted in [START_REF] Hamburger | On time" project completion-managing the critical path[END_REF], proposing that in order to maximize the probability of project success, namely the completion of a project within its deadline, a realistic completion date should be established. This should include several types of relationships precedence and resource constraints, in which the only acceptable scheduled durations should be the exact time durations needed to execute the activities, since longer durations would be wasted by the effect of Parkinson's Law [START_REF] Parkinson | Parkinson's Law, and Other Studies in Administration[END_REF]. But to ensure that the project is completed on time, the project network must also accommodate uncertainty in the execution of the activities, thus establishing a time buffer at the end of the project and also at the critical chain integration points, known as Feeding buffers. This allows handling sudden changes on the critical activities and preserve management focus.

It is worth to notice that, in addition to the mentioned critical chain scheduling perspective, CCPM must also include specific changes in human behaviors during project activities execution, such as:

• The Relay Runner Behavior or Mentality, e.g., quick activity execution and work deliver as soon as it is completed. • Full dedicated resources to eliminate or reduce bad multitasking.

• Frequent report of activities expected durations for their completion.

• Prioritize all requests considering the buffer report.

• Use tasks priority lists to dynamically change and assign resources considering buffer penetration reports.

These aspects will have impacts in several other procedural areas of project management, as in costs, quality, communication, risk and procurement in projects [START_REF] Leach | Critical chain project management. 2nd Edition[END_REF][START_REF] Kendall | Advanced Portfolio Management and the PMO: multiplying ROI at warp speed[END_REF].

Exploring TOC in Collaborative Networks

In this chapter, we will explore the application of TOC in collaborative networks.

Although this is a position paper, the authors feel that a motivation example helps to illustrate how the TOC could be applied in the management of a collaborative networks.

In the second part of this section, some ideas on how to apply TOC in CNM are provided.

Motivation Example

This section presents a motivation example illustrating the application of the Theory of Constraints in collaborative networks, focusing in CCPM as starting point.

Typically, a project is specified by a set of activities, with durations and precedencies. For instance, as shown in table 1, activity a5 can only start after activities a2 and a3 are finished. Each activity requires certain resources, generically represented by r1, r2, ... which might be material, money, equipment, know-how, etc. Assuming it is a collaborative project, these resources are provided by potential partners who will then work together in the execution of the project activities, according to the necessities illustrated in Table 2 (a). Table 2 (b) shows a set of partners who, in an earlier collaboration phase, namely partners selection, have already been evaluated in terms of trustworthiness, reliability and past collaborations. In the next phase, the allocation of partners to activities is performed according to the availability of resources for the respective activities. The TOC's critical chain scheduling allows identification of constraints affecting the project, namely its critical activities. Applying this approach, the project requires 19 days plus 3 for project buffer (PB), which results in 22 estimated days for the project completion, requiring also two Feedings Buffers (FB) as shown in Fig. 2. The project critical activities (which establishes the critical chain) are in red on the project Gantt representation at the right side (a1, a2, a5 and a7).

Fig. 2. Project schedule with resource allocation

While CCPM allows addressing constraints from the project level. We can observe the same information from a collaboration perspective, enabling to focus on other project aspects which might help identify new potential risk factors.

From Fig. 2, we can perceive the interactions that are established between the partners in the project. The assumption here is that partners who work together in the same activity interact more intensively than in different ones. We can represent these interactions in a graph (Fig. 3), which can then be studied with Social Networks Analysis methods. This partners' interaction view can then be used to support collaborative decision making and problem resolutions during project execution.

Each vertex of the graph represents one partner. Each arc and weight represent the number of common project activities between two partners. But in order to represent the proximity concept, the inverse of the number of activities is used. For example, a value of 0.3(333) in the graph indicates that the respective partners work together on three activities (e.g. p1 and p4).

Fig. 3. Social network graph subjacent to the partners participating in the project

With the obtained social network graph, several indicators can be used to explore network properties relevant to collaboration. For example, the node sizes shown in the graph are proportional to the betweenness centrality measure [START_REF] Pereira | Improving the quality of collaboration requirements for information management through social networks analysis[END_REF]. This measure allows the identification of the network elements with greater authority and control over the flow of information, acting as brokers in the sharing of this information [START_REF] Sutanto | Emergent leadership in virtual collaboration settings: A social network analysis approach[END_REF]. These authors also indicated empirical research showing that when an element with high betweenness leaves a network, it can cause severe disruptions to information flow. Furthermore, it is suggested in [START_REF] Pereira | Improving the quality of collaboration requirements for information management through social networks analysis[END_REF] that a high betweenness indicates elements with great influence in the collaboration between the members of a network. In the context of this example, this indicator can then be used in project management, in order to more closely monitor the activities of these partners.

Potential Research Lines in Collaborative Networks

Collaborative networks are complex and multidimensional structures, requiring the management and supervision of multiple processes that are developing simultaneously. The fundaments of Collaborative Networks, morphology and lifecycle are out of scope of this study, which can be found in [START_REF]Collaborative networks: Reference modeling[END_REF][START_REF] Camarinha-Matos | Collaborative networks: A mechanism for enterprise agility and resilience[END_REF].

The most important contribution of TOC could be to help handling the complexity of CN management. As stated by Goldratt [START_REF] Goldratt | What is this thing called Theory of Constraints and how should it be implemented?[END_REF], "Focusing on everything is synonymous with not focusing on anything". TOC could therefore be applied in CN to provide methods to support collaboration contexts, so that a network manager could focus on the most important constraint, or core problem, in a collaborative project. For such, the potential methods from TOC that can be applied in CNM are identified in table 3, highlighted in bold.

Operation Monitoring

TOC can be used to identify deviations from plans, and alert mechanisms can be provided for the VO-planner (BM). For instance, eventual disturbances affecting resources availability may pose impacts on the project's critical chain and delay its completion. They can be spotted during project execution (CCPM) and resolved by TOC POOGI / TOC TP.

Performance assessment

Development of new indicators and monitoring rules for the detection of relevant impacts on project planned time objectives (CCPM).

Network reconfiguration

TOC can be used to manage change. Whenever there is a shift in goals, activities can be rescheduled, and resources utilization verified for eventual conflicts resolution (TOC TP & CCPM).

Risk assessment

As the project progresses, it is possible to observe its status proactively and thus reduce or manage risk of resource or competencies unavailability, spot potential conflicting partners and reduce delays occurrence (CCPM).

Trust assessment

There is a significant amount of research works dedicated to trust in collaborative networks, such as [START_REF] Msanjila | Modelling trust relationships in collaborative networked organisations[END_REF]. Information provided by trust indicators could be considered in the identification of constraints and risk (TOC POOGI cycle / TOC TP).

Collaboration preparedness assessment

The ability to collaborate is a relevant aspect in a collaborative network, as a partner's low score on this trait can be used to foretell relationship issues undermining project execution. Similar to trust, preparedness to collaborate indicators could also be used to assess the need to reconfigure the network (TOC POOGI / TOC TP).

Main Conclusions and Future Work

This position paper explored the integration of the Theory of Constraints in the context of Collaborative Networks Management. The foundations of this management theory were firstly presented. Then, the methodological integration of TOC into CNM was researched in two parts, starting with a motivation example, and then with an exploratory exercise, to illustrate the correspondence between a few TOC methods and typical phases of CN lifecycle.

The motivation example allowed identify several preliminary results. For instance, from the project definition, the critical chain method allowed identify conflicts in partners' resources utilization. The "betweenness closure" measure, from the realm of Social Networks analysis, was used in the example to identify potential collaborationrelated risks. In this regard, disruptions involving partners with high betweenness can pose significant impacts on network performance, including at collaboration level. As such, the example helped highlight potential benefits from the use of TOC in Collaborative Networks Management.

Given the suggested hypotheses, proposed during this position paper, we can expect potential benefits in the use of the Theory of Constraints in collaborative networks. These aspects must be further explored and detailed in future research work. In addition, a CNM / TOC combination should be addressed assuming a multi-disciplinary perspective, involving researchers from distinct areas, namely Industrial Engineering Management, Sociology and Information Technology.

Fig. 1 .

 1 Fig. 1. The TOC Basic Questions and TOC TP tools As shown in Fig. 1, the TOC TP six logical tools, is used according to a specific set of objectives, namely: • Goal Tree (GT): clarification and identification of the objective to be achieved under analysis. • Current Reality Tree (CRT): identification and analysis of system core problems and existing related Undesired Effects (UDE). • Conflict Resolution Diagram (CRD): identification and resolution of conflicts; also called Evaporating Cloud (EC). • Future Reality Tree (FRT): search for alternative solutions, characterizing the entities and foreseeable interconnections in the future system, converting the UDEs into desired effects (DE). • Negative Branch Reservation (NBR): used to identify possible risks of the future solutions and corresponding implementation plan, checking the new system solution against the identified UDEs. • Prerequisites Tree (PRT): used to ensure the coherence of the solution. • Transition Tree (TT): to determine the main actions to be taken during the implementation of the solution.

Table 1 .

 1 Project activities precedence table

	Activity Most likely Pessimist Optimist Precedence
	a1		4	1	--
	a2	5	6	2	a1
	a3	3	4	2	a1
	a4	4	6	3	a1
	a5	8	10	5	a2, a3
	a6	5	7	3	a3, a4
	a7	3	5	1	a5, a6

Table 2 .

 2 (a) Required resources in the project, and (b) Availability resources

		(a)				(b)
		Required resources		Available resources
	Activity	r1 r2 r3 r4 r5 r6	Partner	r1 r2 r3 r4 r5 r6
	a1	1	3	2	p1	5	5
	a2	2	4		p2	2	4	1
	a3	2	5		p3	5	5 3
	a4		4	3	p4		4	2 1
	a5	6			p5	1 5
	a6	3	2		p6			4
	a7	2 3 3

Table 4 .

 4 TOC contributions for Collaborative Network Management (cont.)

Acknowledgments

. This work has been partially supported by UNIDEMI -Research and Development Unit for Mechanical and Industrial Engineering by the Portuguese FCT-PEST program UID/EMS/00667/2019 and by the Center of Technology and Systems (CTS) -Uninova, Portuguese FCT-PEST program UID/EEA/00066/2019.

Earlier research works concerning the application of TOC in collaborative networks can be found in [START_REF] Tenera | A TOC perspective to improve the management of collaborative networks[END_REF][START_REF] Tenera | A critical chain perspective to support management activities. In: dynamic production networks[END_REF]. But a more in-depth study must start by attempting to fit the TOC's methods from Table 3 with CNM aspects presented in Table 4. In this table, there are some suggestions of how TOC can be applied in CNM.

Table 4. TOC contributions for Collaborative Network Management

Management aspect

How it can be done (with mappings from table 3)

Collaborative project definition

Characterization of the project in terms of activity precedencies, required resources, and competencies. TOC methods can use this information to find the critical chain, detect and resolve resource constraints, to manage and adjust the expected project duration (CCPM).

Partnership formation

TOC can be applied to help achieve the best possible allocation of partners to project activities, having in mind resources availability and critical chain buffer management (TOC TP & CCPM).

Partners selection issues

There are many methods for partners selection. For instance, partners competencies, reliability, trust, collaboration preparedness (and other traits), skills, and resources are some of the ingredients in partners selection approaches. In TOC, these aspects could be explored in terms of availability versus needs in the project activities and evaluate them for eventual conflict issues (TOC TP).