Keywords

1 Introduction

Nowadays, in the era of Internet of Things, people tend to be more tied to connected products seeking to ease and improve quality of life and find new ways to make things such as daily tasks differently. At the same time, the expansion and high availability of sensors and electronic components with new features covering increasingly users’ requirements enable the development of smart products with new capabilities. This expansion makes the development of such products more complex than the traditional ones due to the difficulty to find rapidly the right match of components. Nevertheless, a plethora of smart products were released during these last years, with a high interest in healthcare, sport and games.

This paper addresses the intelligent wearable Meta-Products, main focus of the European FP7 project “EASY-IMP” (Collaborative Development of Intelligent Wearable Meta-Products in the Cloud). Meta-Products consist of products to which we add network of sensors that enable them to connect to the Cloud, allowing the user to capitalize on the collected data through specific applications. Meta-Products require more complex elements than generic products and need the involvement of teams with interdisciplinary skills (garment designers, sensor networks designers and application developers). We have previously established a high-level generic methodology of MP development to describe an overview of the phases, methods and tools in EASY-IMP project [1].

This paper focuses on the details of Set-Based Concurrent Engineering (SBCE) which is practiced to tackle the design and testing of the alternatives. SBCE is applied for dealing with complexities of products and multi-disciplinary of involved stakeholders. It allows actors working in parallel to discover set of feasible MP designs and select the compatible set of feasible components to establish MP prototype. Customer’s requirements, technical solutions, and manufacturability are considered as constraints for evaluating and selecting feasible alternatives. This paper provides the specification of SBCE from theoretical concept and principles to concrete (practical) specifications adapted to Wearable Meta-Products leading to a prototype implemented on top of a PLM system.

Next section explains the notion of “Wearable Meta-Product”. A review of SBCE is given in Sect. 3. Section 4 presents the SBCE specification for Meta-Products and implementation is specified in Sect. 5. Finally Sect. 6 concludes the paper.

2 What Is a Wearable Meta-Product?

The product is shifting nowadays from a physical thing to a smart thing capable of sensing, processing, storing data and communicating with the environment. This tendency has led to a rapid growth, especially in the field of wearables technologies where the customer is no longer looking for a simple piece of textile but to have services in addition to that. These innovative products made companies to change their thinking to make a shift of trend from product-centric to service-centric and gave birth to a set of names to designate these products. Several names are available in the literature related to “Smart” [2], “Intelligent” [2], “Smart, Connected Products” [3], or “Meta-Wearables” [4]. However, these terms refer to the same range of products with sensing, computing, storing and communication features.

The term “Meta-Product” was introduced first by S. C. Rubino et al. in 2011 as “web-enabled product-service networks” [5]. Meta-Product comprises physical and digital elements. The physical element consists of sensorial and actuating functions. The sensorial function can communicate with user or environment and serve input information to the digital element. The actuator function is initiated by the digital elements for notifying the user. The digital elements accomplish actions such as data computing, storage, and visualization [5].

In this sense, we define Wearable Meta-Products as intelligent hybrid products made of garments, sensor networks and applications, interacting with users and the environment capable of real time data processing and storage, with capabilities to extend functionalities by communicating with other things.

The Product Lifecycle Management (PLM) is used to manage the products during all the phases of the lifecycle “from cradle to grave” [6]. As any product, the lifecycle of Meta-Products consists of three phases during which information must be tracked and knowledge capitalized:

  • The Beginning-of-Life (BOL) phase comprises all the phases of development of the MP defined by T. Elhariri et al. [1], from the concept definition to production and delivery to the customer.

  • The Middle-of-Life (MOL) phase mainly consists of the use of the MP by the customer, and eventually the maintenance, repair and overhaul (MRO). Also, the evolution and upgrade of the components of the MP (as instance: the change of a sensor by another one more accurate) or updates of related software or applications.

  • Finally, the End-of-Life (EOL) phase includes the re-manufacturing or disassembly of the MP into parts, and the reuse, refurbishing or recycling.

3 Set-Based Concurrent Engineering Review

The traditional Point-Based Concurrent Engineering (PBCE) is dealing with a single solution qualified as the best one [7]. The process of PBCE is iterating on one solution until reaching the expected result, otherwise another solution is selected (Fig. 1–A). This practice generates a lot of waste due to exhaustive investigation of failing solutions that are spread apart.

Fig. 1.
figure 1

Comparison between PBCE and SBCE [8]

Unlike the PBCE, the Set-Based Concurrent Engineering (SBCE) is considering multiple alternatives simultaneously (Fig. 1–B). The SBCE is characterized to develop set of alternative designs depending on an effective decision process which is significantly important. It focuses on the design convergence among set of design alternatives through using a variety of tools and techniques to eliminate weaker solutions and save time on a project development. The evaluations of alternative designs set gives a clear idea about each alternative solution and facilitate communication and selection of final design. Finally, alternative solutions are kept in the set until enough knowledge is gathered to eliminate them.

The SBCE rely on three principles (Table 1) derived from an industrial company (Toyota) by Sobek et al. [7]. The principles constitute the framework for product development where all the involved stakeholders work concurrently to develop new products. However, these conceptual principles need to be adapted to company’s specific product to practice effective SBCE.

Table 1. Principles of Set-Based Concurrent Engineering [7]

4 Application of SBCE for Wearable MPs

To apply SBCE to the development of Meta-Product, we need to adapt its theoretical principles to the specificities of this new kind of smart product combining a physical part (garments and network of sensors) and a service part (applications and software). These specifications should ease the work of the multidisciplinary team aiming to develop the Meta-Products, by eliminating wastes, facilitating collaboration, maximizing value and delivering high quality Meta-Products that meet the customers’ expectations.

The challenge at this level is to propose specifications based on the theoretical SBCE principles by proposing a strategy to manage a Meta-Product the project using the SBCE, by defining processes to pragmatic application and having in mind the PLM system support. By providing an effective solution, the development team will put more efforts on innovation at Meta-Product level.

The process to develop Meta-Products is presented as a sequence of activities targeting a high level of collaboration between the teams in charge of the development (Fig. 2).

Fig. 2.
figure 2

Meta-product development process

4.1 Preliminary Design

The Meta-Products consists mainly of assembled parts and components produced by various suppliers, thus it is recommended to apply the Design for Assembly (DFA) approach for the design. The preliminary design of the Meta-Product gives a first idea about the Meta-Product expected design and the main required parts. Based on the technical requirements extracted in the second phase of the MP Development methodology [1], the designers are able to breakdown the Meta-Product into sub-subsystems (i.e.: garment, sensors, computation unit…) and start the design. The design of mobile applications can also start at this level to identify what are the needs of the new Meta-product in terms of software. It can rely on such existing application by releasing an update or develop a new application with new features and capabilities to communicate, gather, and process the data to give accurate information to the user.

4.2 Technical Solutions

In this second phase of the process, we need to identify the parts corresponding to the sub-systems identified previously. The parts database is the main data source of the available parts from the suppliers’ catalogue. It should be kept updated and store all technical specifications of the parts. Starting from this database, we identify for each sub-system the parts that fit their needs. Based on the parts technical specifications and the knowledge captured during the previous MPs development, the stakeholder can use the compatibility matrix with the maximum of information about the compatibility and combination dependencies without imposing further constraints based on “guesses”.

The parts compatibility matrix as shown in Fig. 3, visually represent the relations between the all the Meta-Product candidate parts. For instance, the matrix shows that ECG1 is not compatible with GPS3, while it can be assembled with GPS1 and GPS2.

Fig. 3.
figure 3

Parts compatibility matrix

4.3 Technical Alternatives

Once the compatibility between the identified parts is established, the Meta-Product alternatives can be generated and Investigated in parallel. Decisions and constraints should be delayed as much as possible till enough knowledge is gathered through testing, simulations, and integrations. The set of alternatives will be gradually narrowed by discarding the alternative combinations that are infeasible and in conflict.

Each Meta-Product alternative item can be linked to several objects and information:

  • CAD design

  • Bill of Materials (Engineering BOM and Manufacturing BOM)

  • Manufacturing process

  • Virtual Prototypes

  • Physical Prototypes

  • Testing results and Information

To manage the technical alternatives progress and evaluation, we propose the lifecycle illustrated in the following figure (Fig. 4):

Fig. 4.
figure 4

MP alternatives lifecycle

Description of the technical alternatives lifecycle states:

New:

This first state assigned to an alternative when created.

Assigned:

In this state the alternative is assigned to a team (Design, Manufacturing or testing…). The work on the alternative has not yet begun.

Design Engineering:

This phase is assigned to the alternative when there’s a need in designing the MP, changing, or detailing. The results of this phase are the CAD (Computer Aided Design) design and eBOM (Engineering Bill of Material) of the Meta-Product.

Manufacturing Engineering:

This phase consists of the manufacturing feasibility analysis and the generation of the MBOM (Manufacturing Bill of Material) required for the physical prototy** of the MP.

At this level the design of the Meta-Product should be evaluated by taking into account the manufacturing constraints. Starting from the eBOM that describes “What” is needed and using the Manufacturing Process Management (MPM), the manufacturing team can investigate the feasibility of the Meta-Product from a manufacturability perspective, plan for the manufacturing process and generate the MBOM that represents the “How” the MP will be produced and assembled [9]. The manufacturing process is also investigated by the manufacturing team by defining a Bill of Operations (BOO) that contains all the steps to assemble the Meta-Product.

Virtual Testing:

In this state the virtual prototype is created and tested before going deep in the design or manufacturing feasibility study of the Meta-Product.

It will be necessary to conduct for prepared testing activities, in terms of virtual prototype and Virtual Reality (VR) simulations to meet the production metrics and the level of customer satisfaction, when the Meta-Product design finishes.

In this Easy-Imp project, VR simulator is a stand-alone application with user-friendly interface that allows to select and position sensors, make simulations, obtain visualization of the results and make records (images and videos). Virtual reality simulations are used to evaluate the behavior of the designed Meta-Product configurations (interplay between garment, sensor network and Application) under different simulated real-life conditions following different test scenarios and hel** to optimize sensor positioning. The test managers will take charge of the whole process of virtual testing and provide feedback. The results of the VR simulations (e.g. error characteristics for motion/activity capture) will be stored in graphical form or as videos for being reviewed by the MP development team.

Physical Testing:

In this state the physical prototype of the Meta-Product validated virtually is now physically assembled and tested.

At this level, the Meta-Product prototype is assembled using the parts from the mBOM, and following the BOO defined the manufacturing team. Real testing scenarios will be performed to confirm the efficiency of the final design configurations. The evaluation results will be analyzed and validated by respective experts (e.g. sensor/application experts) who can also help during the testing phase.

Validated:

This state means that the resulting MP has succeeded in the physical testing phase. The alternative is then validated.

Rejected:

This state means that the alternative has failed in one of the steps before (Design engineering, Manufacturing engineering, Virtual testing, or Physical testing). The Project manager needs in this case either to re-assign the alternative to explore other solutions or to abandon it.

The change of states will be followed by the sending of notifications to project members to inform them about the progress of the alternative. Sharing new results and data about the alternative with work teams enables to get quick and useful feedback. While the alternatives are going through the defined lifecycle, the project manager is more and more able to make decisions to narrow the set of alternatives. The alternatives will be gradually narrowed based relevant information and additional constraints from the project stakeholders until reaching the best solution.

4.4 Final Design

The best Meta-Product alternative is found; all the parts are clearly identified and the MP success through the testing phase proves that the results meet the customer requirements. Finally, the mobile application can be developed and tested with the real MP prototype. The Application Programming Interface (API) of the Meta-Product can be developed to offer to the mobile applications developers the opportunity to develop new applications. The knowledge from this experience should be capitalized and used for upcoming MP projects.

5 SBCE Prototype

To implement the SBCE prototype, we have decided to use PLM systems, which are largely considered as innovation enablers and best candidates to support product development methodologies. The development of this new kind of products is not supported by actual PLM systems [2].

ARAS Innovator has been selected by the Easy-Imp project after the scoring of different PLM systems available in the Market, considering functional, technological, methodological, and commercial criteria. ARAS Innovator relies on SOA architecture with a web-based client, offers extensive functionalities, is fully customizable and exposes an API to ease integration with other systems. For this prototype, we have used the version 10 SP4 of ARAS Innovator with Microsoft SQL Server 2012 database.

The process explained in the previous section will be implemented within ARAS Innovator and automated using the workflow feature. Before that, the standard PLM data-model needs to evolve to support the complex Meta-Product data structure and handle the Meta-Product project using SBCE. A Meta-Product data-model was established in order to have a common Meta-Product in all systems used during the product development. However, this data-model will not be discussed in this paper.

Figure 5 is the Meta-Product project data-model implemented. The data-model includes all the necessary items to handle the Meta-Product project using SBCE and technical alternatives with related prototy**, testing and manufacturing information.

Fig. 5.
figure 5

Meta-product project data-model

Figure 6 is a screenshot of the Meta-Product project in the PLM, the grid lists the alternatives linked to this project with information such as the status, progress, current team in charge and related KPIs. Figure 7 depicts one of the validated alternatives with all the associated information and tested prototypes.

Fig. 6.
figure 6

Meta-product project in PLM

Fig. 7.
figure 7

Meta-product alternative in PLM

6 Conclusion and Outlook

This paper provides the SBCE specifications related to the High Level Generic MP Development Methodology. This specification presents a transformation process towards Meta-Product development by defining the relying activities and the associated tools that implement the principles of SBCE. Therefore, this paper provides a novel approach to shift from SBCE theoretical principles towards a pragmatic (practical) application to Wearable Meta-Products and help the multi-disciplinary team to deal with the complexity of Meta-Products, find the best design solution that fits customers’ requirement and lower the time to market.

The automation and use of PLM system to implement the SBCE approach will contribute for a better understanding avoiding confusions and enable the stakeholders to focus on the level of innovation of Wearable Meta-Products.

The Product Lifecycle Management (PLM) is intended to manage the whole lifecycle of products. Meta-Products require a PLM that supports both the Hardware and Software. Since actual PLM systems are not managing software, our future research will concern the integration of PLM and Application Lifecycle Management (ALM) in order to offer a complete PLM solution that manages efficiently the whole Meta-Product throughout the lifecycle.