# Information and Data Provision of Operational Data for the Improvement of Product Development

Klaus-Dieter Thoben, Marco Lewandowski

► To cite this version:

Klaus-Dieter Thoben, Marco Lewandowski. Information and Data Provision of Operational Data for the Improvement of Product Development. 12th IFIP International Conference on Product Lifecycle Management (PLM), Oct 2015, Doha, Qatar. pp.3-12, 10.1007/978-3-319-33111-9_1 . hal-01377420

HAL Id: hal-01377420

https://inria.hal.science/hal-01377420

Submitted on 7 Oct 2016

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
# Information and Data Provision of Operational Data for the Improvement of Product Development

Klaus-Dieter Thoben<fnref n="1" />, Marco Lewandowski<fnref n="2" />

**Abstract.** Today's usage of supporting technologies like RFID, condition monitoring or further embedded systems provides a huge amount of data to the operation and maintenance (O&M) phase of complex technical systems. While analyzing this data for the purpose of more efficient operation is already extensively adopted, the transfer of data to other lifecycle phases is most often lacking. This paper will analyze the obstacles and requirements for information and data provision from the usage phase in order to support the development of next generation products. This is carried out by analyzing sub-aspects of data provisioning for product development purposes thus leading to a comprehensive framework for the reorganization of information backflows from the O&M phase. The findings are discussed in the case of a windfarm. The paper gives a valuable insight regarding the derivation of targets and action fields for information and data provision to improve the product development process.

**Keywords:** Product Lifecycle Management, Internet of Things, Operation and Maintenance, Maintenance Concepts, Data Mining, Wind turbines

## 1 Introduction

In increasingly more complex technical systems, a broad range of supporting technologies nowadays characterizes the operation and maintenance phase of such systems. These include for instance condition monitoring, RFID or embedded controlling units: Condition monitoring to measure and access the operational conditions, RFID to identify components and record service actions as well as further embedded technologies to capture data from the field level of industrial I/O systems, often referred to as Supervisory Control and Data Acquisition (SCADA) [1]. Besides the technical systems, also service protocols of the maintenance staff are most often available in digital form. All sources in total lead to a huge set of structured and unstructured data that is directly related to the use phase of an individual product and provide in general a good impression about the individual operational environment and purpose.

<footnote n="1">¹ University of Bremen, Institute for Integrated Product Development, Bremen, Germany
tho@biba.uni-bremen.de</footnote>

<footnote n="2">² BIBA – Bremer Institut für Produktion und Logistik GmbH
at the University of Bremen, Bremen, Germany
lew@biba.uni-bremen.de</footnote>
Industrial investment goods face a shift from a product perspective to an integrated perspective on product service systems, which brings the entire product lifecycle of individual products into focus of improvements [2]. With regards to the development of new product generations or the continuous improvement of existing machinery designs, it should be of uppermost interest for the designers and manufactures to deduce ‘lessons learned’ by letting data and information of actual products flow back to the design teams. Referring to the term ‘Internet of Things’, technological prospects to enable ubiquitous access to operational data exist and are recently on the way to emerging markets [3]. However, to reorganize the general design methodology by means of encompassing operational data, the framework presented in this paper shows an overall approach addressing relevant fields of action.

The remaining parts of the paper are organized as follows. Section 2 states and analyses the overall objective, which is generally requested by design departments and breaks it down into sub-aspects. Section 3 sketches a general framework approach to solve requirements and accordingly discusses concepts for the sub-aspects. Section 4 briefly describes the application of the approach to the case of wind turbines, while section 5 finally sums up the findings and outlines possible further research.

# 2 Research Motivation and Fields of Action

From the perspective of product development, the deviated challenge of data provisioning of operational data is to transform data into information and action-oriented knowledge to support the development process. According to the considered case of improving next generation systems or topical designs, the objective encompasses that data of the individual product lifecycle will be stored and processed in order to link the information to the individual tasks.

## 2.1 The Product Design Process in the Context of Data Provision

For the question how designs are created in the field of mechanical engineering, a variety of prescriptive models has been investigated [4]. According to [4] a general understanding of the design process is an iterative process encompassing the steps illustrated in the following Fig. 1.
<figure><img src="image_2.png" /><figcaption>**Fig. 1.** General iterative steps of the design process (according to [4])</figcaption></figure>

The *recognition of needs* describes the general and partly undefined idea of a product or technical solution to face a problem or challenge. A subsequent question for data provision of operational data accordingly addresses a possible support for finding new ideas for new designs or adaptive designs. It can be assumed that essentially systematic problems in topical designs are investigated so that these trigger ideas to adapt or vary designs.

Derived from that, the *specification of requirements* is a far more detailed description of required properties, which the later system should have. Again, the subsequent question for the data provision is: Does operational data of topical products help to deduce concrete requirements for future designs? The strength of material, the accessibility in case of maintenance actions or the causing of unexpected high operational costs, to name just a few examples, could be possible results of operational data analytics and directly address tasks under the considered step.

With a *concept formulation*, first technical solutions are generated which face the general need under consideration of the stated requirements. A broad range of tools support this tasks, namely solution catalogs, modelling software, 3D-CAD software, etc. By fulfilling the tasks summarized under this step, tasks have a particular context which might be “strengthening a mounting”, “finding a locking mechanism”, “lowering production costs”, “substituting material” and much more. From the perspective of data provision, a highly aggregated key performance indicator for existent designs - taking into account the collected data - should support and simplify the selection processes for design principles. Aggregated and context-related information has to be integrated seamlessly in the engineering tools (i.e. engineering desktops, software or the like).

In particular regarding this sub-aspect of data and information provision, also the *concept selection* profits from an underlying fundamental experience for different design principles. Again, the challenge from the design perspective is to extract experience and practical knowledge from data and link it to design principles.

The *exposition of design details* addresses detailed requirements on calculations, computations or further verifications. The output of this step should be a concrete technical design. Anyway, verification methods even if done with modern methods like Finite Element Method (FEM) are still based on load assumptions or the like. An idea of data provisioning from operational use is also to have more realistic assumptions regarding loads or operational environments, as those are continuously monitored referring to the general concept.
*Production, sales, and maintenance* are the classical transition from the beginning of life phase to the middle of life or usage phase. While the design process is an iterative process, a continuous target-performance comparison should be intended essentially in this phase by means of comparing aggregated key performance indicators.

To sum up the individual sub-aspects, by and large a knowledge infrastructure has to be built in order to acquire, convert, process, apply and also protect the operational data, which was captured by the mentioned supporting devices. The capabilities of a data provision framework should include a) reporting on systematic problems, b) support on selecting appropriate design principles, c) support for realistic verification and d) continuous target/performance comparison. To establish this derived knowledge concept with design departments, technology, structure, and cultural or organizational acceptance is required [5].

With respect to the latter, from the practical perspective, it is required to translate relevant issues to key performance indicators (KPIs) so that a continuous monitoring can take place. These could be ‘new product introduction time’, ‘new products failure rate’, ‘new products success rate’, etc. and should be significantly improved with respect to data provisioning. Furthermore, a crucial point includes the support on selecting appropriate design principles which could reach from manual design principles to decision support systems like case based reasoning (CBR).

## 2.2 Closed-Loop PLM as a Concept for the Technical Infrastructure

The concept of closed-loop product lifecycle management underlines essentially the challenges from the technical perspective. Closed-loop in this sense defined by [6] describes “as strategic approach for the effective management of product lifecycle activities by using product data/information/knowledge which are accumulated in the closed-loops of product lifecycle [...]”. This is further illustrated in the following **Fig. 2**. The system, which is operational in the field, works additionally as permanent test rig and shares information driven from captured data all over the product lifecycle. Stakeholders from the design departments or the lifecycle engineering have the possibility to access, manage, and control the related information. Furthermore, when adopting the concept of closed loop PLM, information can also flow from the first life-cycle phases to the usage phase, which could be for instance 3D-models, failure mode analysis or simulations which could support service technicians in their work [7]. Jun et al. [8] describes an approach for a system architecture that enables the concept.
<figure><img src="image_3.png" /><figcaption>**Fig. 2.** Closed-loop PLM as technical concept for data provision for the product development process</figcaption></figure>

**2.3 The Concept of the Product Avatar for Context-Specific Information Provision**

A further concept encompasses the digital or cyber representation of the real product by means of the so called “Product Avatar”. To manage the communication between the intelligent system and the different stakeholders in the design department, the stakeholder-specific digital representation called “Product Avatar” was introduced by [9]. The core idea of the “Product Avatar” implies that each product has a digital counterpart by which it is represented. The different involved stakeholders are able to gain access to the information acquired within the lifecycle [10]. Consequently, suitable interfaces have to be provided, which are for instance a common messaging interface, service or agent. For the design engineers these interfaces are for example dedicated desktop applications or plugins in existing software, web pages or mobile “apps” tailored to the specific information and interaction needs [10]. In general, the concept of the “Product Avatar” promises to establish a greater acceptance in the organizational structure of design departments.

**2.4 The Cyber-Physical System as the Vision for Autonomous Data Exchange**

Acquiring and using data by the systems mentioned above is already practicable today. Regarding the technical progress on supporting technologies or enabling technologies for the concepts described before, so called “Cyber-Physical Systems” play an important role. The first definition was introduced by Lee [11] and later replenished by Broy [12]. According to this, a cyber-physical system could be understood as a physical object, e.g. a wind turbine, which is equipped with sensors, a data processing module, a communication module as well as actuators, which determine and control physical processes and communicate with other systems [11, 12]. These modules are highly integrated and embedded into the product. The
products detect their own status and their environment through sensors. The data processing module stores these data and the communication unit transfer the aggregated information, to the SCADA system for instance. Human actors or other technical systems analyse the data. They are able to effect the environment via actuators, e.g. actuate an axis, reset a system, change parameters, etc. Regarding the detailed technical challenges for the data analytics, i.e. to provide information and knowledge rather than raw data, integrated concepts are a not solved issue in research and practice. Anyhow, broadly investigated individual methods and tools include statistical techniques, artificial intelligence like fuzzy logic or neural networks, complex event processing, and others.

## 3 Framework for the Data and Information Provision

In order to reorganize the product development process in a way that topical system behavior of operating products is considered, we propose a general framework, which addresses fields of actions in three main pillars. These pillars are driven from the requirement statements as well as from known approaches described in the previous section.

<figure><img src="image_4.png" /><figcaption>**Fig. 3.** General framework approach for the reorganization of the product development process by means of data and information provision of operational data</figcaption></figure>

Fig. 3 illustrates the three main pillars, which are technological prerequisites, methodical concepts and procedural implications. The sub-aspects are described in the remaining parts of the section.
## 3.1 Technological prerequisites

The fundamental basis of the complete intention is that products or complex industrial systems gain “intelligence”. Intelligence in this sense means, that physical products have the ability to act in an intelligent way. McFarlane et al. define the Intelligent Product as “a physical and information based representation of an item [...] which possesses a unique identification, is capable of communicating effectively with its environment, can retain or store data about itself, deploys a language to display its features, production requirements, etc., and is capable of participating in or making decisions relevant to its own destiny.” [13] The degree of intelligence may vary, but supporting technologies mentioned before generally provide products with this decision-making responsibility.

Storage and access of raw data ranges from decentralized to centralized approaches, while centralized *Internet-of-Things* platforms to store and exchange the acquired data build today's state of the art [3]. They serve for a ubiquitous access to the data and accordingly are also required for the further data processing in the product development context. The same platform concept should be aware of integrating further data and information and providing a *uniform access* to these. As mentioned before, service protocols could be from great interest regarding the designer's requirements but are typically stored in other IT systems.

At least, today's most challenging part is to provide *processing capabilities* for the data analytics. As discussed before, rather information and knowledge instead of raw data is requested, so that a problem-specific toolset for data processing is required. Anyway, from the IT infrastructural point of view, the state of the art is prepared for the big data challenge in this context [14].

## 3.2 Methodical Concepts

The central point of the methodical pillar is the *design process* itself. Referring to the general requirement analysis in section 2, it is necessary to adopt the general approach to the companies' individual design processes. This means, that starting a data provision project for the design department requires a deep analysis on the particular design steps and tasks of the individual design process. In each of these, one should raise the question, which is the expected output of the data analysis that supports and simplifies the considered task.

Following this argumentation, another relevant aspect includes the context-awareness of information. We propose to consider and develop a *semantic model* that classifies design principles in order to link data categories as well as calculated results to product-related design principles. This is a necessary step to make designs comparable and to use data for enhanced verification procedures.

While this consideration of the context is focused on the considered technical system, the components or design principles, the general *product avatar* concept as described in section 2 is necessary for filtering information for the different stakeholders. As design tasks for complex systems differ from engineer to engineer, a product avatar-like stakeholder concept will be a success factor for the acceptance of a data provision project.
## 3.3 Procedural implication

By trying to focus more on experience in the design process by means of data and information provision, the design process itself will slightly change. Our general framework addresses three aspects in two categories. The first category implies the building of a specific application-oriented know how for the data processing tasks. While a broad range of algorithms from statistics or artificial intelligence are present in the scientific literature, design teams will need an aligned toolset for *processing* tasks and essentially for *aggregation* tasks, which are in general derived from the first processing.

The second category of implications focuses on human-machine interfaces, which means that information should seamlessly be integrated in the known working environments, e.g. the CAD software, so that the engineers do not have the trouble to use further tools. The aspect is referred to as *context-specific interfaces* and is essential for the acceptance and success of a data provision project.

# 4 First Pilot Implementation: The Case of Wind Turbines

In order to support the idea of the general concept described above, the application on the case of wind turbines is described briefly in the following.

According to Fig. 4, mainly raw data from the turbine itself is collected, but also further context-related data is part of the input. The following step has to encompass the processing of data to gain information for the design department and the life-cycle management. The maintenance team itself is an additional stakeholder but not considered further in this context.

<figure><img src="image_5.png" /><figcaption>Fig. 4. Illustration of the case of wind turbines for data provision</figcaption></figure>

More detailed, the flow of data throughout this case is described regarding three pillars, namely input, processing and output.
## 4.1 Input

The main data sources are the SCADA system and historical data from past maintenance measures, e.g. orders, checklists, feedback forms, etc. Other known and also isolated data sources are historical weather data, weather forecasts, general and statistical reliability data, functional interconnections and possible failure modes.

To answer questions that focus on interlinked aspects of the different data sources, a uniform data access is necessary to enable joint queries. Exemplary questions are for instance:

* Are there specific patterns in the input data of a wind turbine that announce future failures in advance?

* Are there specific designs that show a significantly higher failure probability?

* Are the simulated or anticipated loads and the derived wear comparable to the measured situations in reality?

## 4.2 Processing

In order to process data, a centralized data cloud concept is proposed according to Fig. 4 and known IoT platforms [3, 14]. The cloud enables further processing according to the requirements of the design process. To do so, transforming raw data to information requires

* methods that interlink data sources in the sense of data mining in order to search for conspicuous patterns (such as statistical techniques, clustering and pattern recognition, artificial intelligence like neural networks and fuzzy systems, etc.) and software tools for a uniform data access of different data sources,

* methods that predict future developments through an algorithmic processing which encompasses pattern recognition, classification, time-series prediction, statistical residual life prediction, etc. also in the sense of an integration of several individually applied methods (e.g. scoring via TOPSIS, analytical hierarchical process or similar), and

* methods that are able to apply above mentioned procedures on continuous data streams again taking the complexity of different data sources into account (i.e. aspects of complex event processing [15]).

## 4.3 Output

The information pool that derived from the processing is not specific to context or stakeholders. The described concept of the “product avatar” could filter information and provide communication channels and user interfaces according to the stakeholder’s requirements. Each product avatar representation of the wind turbine is a tailored virtual representation of the real turbine.
# 5 Managerial Implications and Discussion

The paper described challenges and a general approach so that companies can deal with the question of integrating data and information from real products in the product development process. The lifecycle of a wind turbine reflects today's state of practice and illustrates the application of the conceptual frame.

While the motivation to share information along the lifecycle for the design departments was clarified, data- and information-driven concepts like the “product avatar” will show further progress on applicability to real-world scenarios. There are still obstacles in many companies, but it is necessary to change the access to product-related data so that information processing can take place.

Within ongoing projects the technically related challenges (e.g. big data, processing times, etc.) of implementing the described concepts are currently investigated and lead to first prototypes. Having a functional proofed framework and performing infrastructure for data processing is the first step for further investigations. So as to be able to give an example, great effort is needed for experiments that deal with the tailored integration of all this information in the existing workplaces.

## References

1. Mobley RK (2002) An introduction to predictive maintenance, 2. ed. Butterworth-Heinemann, Amsterdam

2. Wuest T, Hribernik KA, Thoben KD (2015) Capturing, Managing and Sharing Product Information Along the Lifecycle for Design Improvement. In: Meyer A, Schirmeyer R, Sándor V (eds) Proceedings of the 10th International Workshop on Integrated Design Engineering. Inst. of Machine Design. Univ, Magdeburg, pp 107–115

3. Wortmann F, Flüchter K (2015) Internet of Things. Bus Inf Syst Eng 57(3): 221–224. doi: 10.1007/s12599-015-0383-3

4. Finger S, Dixon J (1989) A review of research in mechanical engineering design. Part I: Descriptive, prescriptive, and computer-based models of design processes. Research in Engineering Design 1(1): 51–67. doi: 10.1007/BF01580003

5. Gold AH, Malhotra A, Segars AH (2001) Knowledge Management: An Organizational Capabilities Perspective. Journal of Management Information Systems 18(1): 185–214

6. Jun H, Kiritsis D, Xirouchakis P (2007) Closed-loop PLM. In: Taisch M, Thoben K, Montorio M (eds) Advanced manufacturing: An ICT and systems perspective. Taylor & Francis, London, pp 79–87

7. Jun H, Kiritsis D, Xirouchakis P Research issues on closed-loop PLM. Computers in Industry 2007(58): 855–868. doi: 10.1016/j.compind.2007.04.001

8. Jun H, Shin J, Kiritsis D et al. (2007) System architecture for closed-loop PLM. International Journal of Computer Integrated Manufacturing 20(7): 684–698. doi: 10.1080/09511920701566624

9. Hribernik KA (2005) The Product Avatar as a product-instance-centric information management concept. Product lifecycle management: emerging solutions and challenges for global networked enterprise ; [proceedings of the International Conference on Product Life Cycle Management (PLM' 05) held at the Lumière University in the city of Lyon, France during the 11 - 13th July 2005]: 10–20
10. Wuest T, Hribernik K, Thoben K (2013) Digital Representations of Intelligent Products: Product Avatar 2.0. In: Abramovici M, Stark R (eds) Smart Product Engineering. Springer Berlin Heidelberg, pp 675–684

11. Lee EA (2008) Cyber Physical Systems: Design Challenges. In: 11th IEEE International Symposium on Object and Component-Oriented Real-Time Distributed Computing (ISORC). IEEE, pp 363–369

12. Broy M (2010) Cyber-physical Systems: Innovation durch softwareintensive eingebettete Systeme. Acatech DISKUTIERT, vol 0. Springer, Berlin

13. McFarlane D, Sarma S, Chirn JL et al. (2003) Auto ID systems and intelligent manufacturing control. Intelligent Manufacturing 16(4): 365–376. doi: 10.1016/S0952-1976(03)00077-0

14. (2014) IoT and Big Data: A Joint Whitepaper by Bosch Software Innovations and MongoDB

15. Chakravarthy S (2009) Stream data processing: A quality of service perspective. Advances in database systems, vol 36. Springer, New York