**1. Introduction**

A manufacturing failure is an event in which some part of a manufacturing system does not perform according to its operational specifications and therefore it occurs in a specific manufacturing context. Due to such a failure, production is disturbed to a certain extent. The consequence is that production targets may not be achieved. The gap between the resulting production state and the intended production state is thus a problem. A Manufacturing Problem Solving (MPS) procedure starts when such a situation arises. The first step in an MPS procedure is the fault diagnosis, which presents considerable difficulty to human operators in supervisory control of manufacturing systems [1,2]. Providing support to these operators, by means of knowledge-based software applications, has been identified as essential to achieve good results from the solving procedure [3–5].

The characterization of the manufacturing context, where a failure might occur, can be set by means of processes, process steps, machines, tooling, process parameters, and product manufacturing features. Therefore, the context of the failure can be described by means of Process-Product-Resource (PPR) data. When looking at data, historical failure data could be used to assist in the MPS process. The use of such historical data would require identifying similar failures, which, in turn, requires making use of manufacturing context data. Product Lifecycle Management (PLM) systems are considered the main source of PPR digital information, and therefore their use would facilitate any attempt to develop a knowledge-based solution to support an MPS process [5,6]. PLM systems are one of the main components of the digital manufacturing and Industry 4.0 strategy [7,8].

The technological vision of a Smart Factory [9,10] is also included in the strategy Industry 4.0 [8], and eventually aims to develop a factory model that is context-aware and assists people and machines in the execution of their tasks. Fault diagnosis can be considered as one of these tasks to be supported.

A typical approach to a Smart Factory [9] is the deployment of smart artifacts, along the value streams, that are able to collect a large quantity of data from their environment and to communicate with each other (Internet of Things) [8]. This approach implies large investments, which prevents some companies from taking their first steps into Industry 4.0 [11,12]. This work presents an approach that aims to contribute to the technological vision of a Smart Factory but observing the constraints of being based on existing facilities, existing company data repositories, and with low investment.

The proposed approach is a knowledge-based development that integrates two main types of software applications: PLM and Case-Based Reasoning (CBR) [5]. The developed prototype assists human operators during an MPS process. It guides the user through the MPS activity based on the problem-solving method 8D [13]. The user introduces a query describing a problem that occurs in a production line, and the developed prototype software proposes several potential causes to be checked in the line. Based on the user feedback related to these first proposed causes, the system will propose the next lower level of causes. The process is repeated until the root cause of the problem is identified. More detailed information can be found in Camarillo et al. [5].

As sources of information, the prototype integrates two repositories. First, the existing company Process Failure Mode and Effect Analysis (PFMEA) records [14] are stored in the case base of the Case-Based Reasoning (CBR) system [15]. Second, the company's Product Lifecycle Management (PLM) repository contains the PPR data. The Case-Based Reasoning (CBR) system is used to search for and retrieve information concerning similar problems. The similarity determination between the current problem and the problems contained in the case base depends on the PPR data stored in the PLM repository. The architecture of the system is based on SEASALT (Shared Experience using an Agent-based System Architecture LayouT) [16], which is a multi-case-based, domain-independent reasoning architecture for extracting, analyzing, sharing, and providing experiences. Camarillo et al. [17,18] show a description of a first prototype and initial results. Camarillo et al. [5] shows the MPS process model, the architecture of the developed prototype, the main ontology to support the MPS process, and the validation of the prototype. This paper provides an insight into the information and communication models of the developed prototype.

The next sections of this paper are structured as follows. Section 2 contains a review of research works with similar approaches. Sections 3 and 4 discuss the created information and communication models, which are implemented in the developed prototype. Section 5 describes the configuration of the developed system. Section 6 provides a brief description of an application case. The paper ends with the conclusions.

#### **2. Related Works**

The developed approach is grounded on three basic models: an MPS process model, an MPS knowledge representation model, and an MPS system architecture model [5].

The MPS process model defines the steps to be taken by the user to solve a problem with the support of the proposed system. This process model basically follows the steps defined in the 8D method [13] and specifies the kind of interaction expected at each step between the user and the system. The left side of Figure 1 shows the developed Graphical User Interface (GUI), the center part of Figure 1 shows the main steps of the MPS process, and the right side of Figure 1 shows the main systems of the developed prototype. The main steps of the MPS process are explained next and their links with the developed GUI are shown in Figure 1.


**Figure 1.** Process model of knowledge-based system. PLM, Product Lifecycle Management; PFMEA, Process Failure Mode and Effect Analysis; CBR, case-based reasoning.

The MPS knowledge representation model is based on an ontology that allows for the representation of any knowledge related to the MPS process [5]. It comprises the following main concepts: Problem, Component, Function, Failure, Context, and Solution (Figure 2). The relations among these six concepts, their associated taxonomies, and their parameters have been designed to fulfil several constraints: support a generic definition of a manufacturing process and its location, be compatible with the information structure of the PFMEA method, comprise concepts to describe different aspects of a manufacturing problem, and to allow case similarity determination.

The proposed ontology defines the concept "Problem" similarly as in FMEA (Failure Mode and Effect Analysis) [14], where a component performs a function, and the latter fails in a defined mode. Component, Function, and Failure form a unique trio. The concept "Component" is subdivided into six subtypes: Process, Man, Machine, Material, Method, and Environment. The concept "Context" allows for representing the setting of a problem, is subdivided into seven different types of contexts: Material, Process, Machine, Event, Method, Man, and Environment, and has an associated taxonomy represented through the relationship type "is part of" pointing to itself. Each subtype of Context has different types of attributes to specify each type of technical information in the context (e.g., pressures, temperatures, and dimensions). These attributes are used in the configuration of the PLM system to

store PPR information explicitly associated with the problem. More detailed information about this ontology can be found in Camarillo et al. [5].

**Figure 2.** Manufacturing Problem Solving (MPS) top-level Ontology.

The proposed MPS system architecture model is based on SEASALT (Shared Experience using an Agent-based System Architecture LayouT) [16]. The developed architecture supports the deployment of the different agents across different manufacturing plants of a company. Within each plant, agents can be deployed across the areas with different manufacturing processes. In this way, each topic agent, hosted in a specific manufacturing process of a specific manufacturing plant, will be able to collect and to store knowledge related to its own area, becoming an expert of its process and plant. By means of a coordinator agent, a topic agent can communicate and interchange information with all the other topic agents hosted in different processes and/or plants through the company's intranet. Each topic agent has its own case base and uses CBR technology to find the most similar cases related to a user query. This information exchange supports the MPS process by providing the user with solutions for the most similar failures stored in any topic agent of the architecture [5].

In the literature review, several relevant works developed by other researchers were identified. Firstly, in relation to the modeling of PFMEA concepts. Dittmann et al. [19] presented an ontology to support FMEA concepts. The information model proposed in this work enhanced that ontology mainly by adding the concepts of Problem and Context [5]. In relation to the use of a PLM repository, Bertin et at. [6] propose, as part of a Lessons Learned System (LLS), the use of a PLM system as the central repository of data, but they put the focus on the Engineering Change Request (ECR) process of the company, whereas this work focuses on problem solving at production lines.

The work of Yang et al. [1] presents a fault diagnosis system for software intensive manufacturing systems and processes. They also profit from the stored information in the FMEA documents of the company and use CBR as an Artificial Intelligence (AI) tool. Nevertheless, they propose a second AI technology, deep-level Bayesian diagnosis network, to be used in cases of dynamic multi-fault diagnosis with uncertainty. The approach presented in this paper shares with them the use of FMEA and CBR but remains at a simpler AI level. However, the application scope of this work considers the sharing of knowledge among different manufacturing processes and plants (represented by topic agents). Also, contrary to the single-diagnosis suggestion proposed by Yang et al. [1], this proposed system uses an MPS method to guide the user step-by-step through the resolution of problems, which allows multiple cycles of problem redefinition, and that is fundamental when addressing very complex problems.

Finally, two relevant research works were identified in the field of fault diagnosis in aircraft maintenance: Chiu et al. [20] and Reus et al. [21]. Chiu et al. [20] propose the use of CBR together with genetic algorithms to enhance dynamic weighting and the design of non-similarity functions. With this approach, the proposed CBR system is able to achieve superior learning performance. As in the previous case, the approach presented in this paper remains at a simpler AI level, but proposes knowledge sharing among different MPS units. Reus et al. [21], as in this work, propose the use of SEASALT as a multi-agent architecture to share knowledge among multiple units. Nevertheless, the use of extended context-related information to enrich the similarity calculation is not addressed. Therefore, the link to a PLM system to enrich the similarity calculation and the search for solutions is outside its scope.

The next section introduces the developed information models and their link to the data sources, with special focus on the data related to PFMEA and the PPR concepts to be supported by the PLM system repository.
