**3. Information Models and Sources of Data**

The proposed knowledge-based system uses data from four different sources (Figure 3):


**Figure 3.** Top-level view of the proposed system data sources. GUI, graphical user interface; PPR, Process-Product-Resource; PFMA, Process Failure Mode Analysis.

Figure 3 shows the top-level view of the knowledge-based system. The user manages the system through the GUI. The GUI represents a Problem-Solving Sheet (PSS) divided into the corresponding areas of the 8D method. The user inputs the description of the problem through the GUI as described at the beginning of this section. Based on the input description, a GUI agent will send a query to the PLM system to receive the contextual information related to the data input by the user. Then, a comprehensive query, comprising both the user's input data plus the retrieved context data, is sent to the CBR system (Coordination Agent). The Coordination Agent will need to collect a first set of possible solved cases. The Coordination Agent communicates with the different topic agents to request proposals for similar problems. The case base of each topic agent needs to be populated with an initial set of cases (i.e., already solved problems). To do so, the company's PFMEAs are taken as the initial set of cases. The case base will be continuously extended with new solved problems. A solved problem is analyzed by an expert to decide whether it is included as a new case in the CBR case bases or not. A deeper insight to this process is given in the next sections.

The next subsections focus on the developed information models used to collect cases from PFMEA and to collect context information from the PLM system.

#### *3.1. PFMEA Data*

The initial source of cases for the knowledge-based system is the PFMEA documentation of the company. Figure 4 shows the information mapping between PFMEA and the knowledge model of the system [5]. As is shown in this figure, the PFMEA does not contain all the needed information to match totally the knowledge model of the system. Thus, the support of experts and the PLM system of the company are needed to translate the identified failures from the PFMEA into useful cases for the knowledge-based system. This situation derives from the fact that a PFMEA document represents a detailed analysis of all possible modes of failure associated with a specific production process [14]. However, the PFMEA document does not contain explicit technical information about the context of the process under analysis, and that information needs to be found in other documents associated with the PFMEA. In the proposed knowledge-based system, the created cases will be definitely detached from their original PFMEA documents, and the context information will have to be extracted from the PLM system of the company. This situation requires an expert to conduct a translation of failures into cases. A second issue to solve, in the translation activity, is that a PFMEA is a technique to prevent failures, but it is not designed to contain or to correct failures. Therefore, an expert has to fill these two fields, as well as define who is involved when the problem might happen (i.e., the parameter "Who"), a piece of information that is also not explicit in the PFMEA document.

**Figure 4.** Information match between PFMEA and the knowledge model.

The fields in the PFMEA matrix (Figure 4) marked with 1, 2, 3 (i.e., the process, production facility, and product under analysis), and 4 (i.e., the component where the potential failure is identified) are used as input for the PLM to search for and retrieve the context data. The fields 4, 5, and 6 represent the core of the problem definition (i.e., Component, Function, and Failure). Field 9 (i.e., occurrence) defines the frequency of the problem, field 7 the preventive action, and field 8 indicates which failure causes the problem. The same process is repeated systematically with every new failure.

#### *3.2. PLM Information Model and Manufacturing Context Data*

The PLM system has the function of providing the context data related to the user query. For this, the PLM system has to be customized to fit into the defined ontological model, so the requested context information can be used by the knowledge-based system. This customization has two main areas of activity:


In the case study presented in this work, the selected company had no prior PLM system available. The software Aras Innovator (version 11.0) was selected as a PLM system and its installation and customization were part of the case study. On top of the two customization activities defined above, an experimental novel PLM information model was developed with the aim of accelerating the retrieval process of context data.

The taxonomy of the class Context of the ontological model (Figure 5) has six main elements: Process, Machine, Material, Man, Method, and Environment. These six elements were declared as main elements in the PLM data structure ("Items" as per the standard terminology in Aras). Figure 5 shows these six elements with their relationships. These relationships will be the key to the process of information search as previously mentioned.

In the PFMEA methodology [14], on which the created ontology is partially based, the element Method represents the defined procedures or standards. Following this philosophy, the element Method contains the technical specification of each of the other component types in the PLM system.

A relevant issue in the management of technical information is that part of the information can be common for a whole family of components (e.g., a family of hex bolts with a specific diameter and thread where each one is distinguished from the others by length). In this sense, it is important to create a configuration in the PLM system that allows this type of information inheritance. This will ensure higher information consistency in the PLM system and a much easier update procedure. This was addressed by the creation of an additional element named "Parameter". A Parameter is defined as the smallest stored unit of information in the PLM repository. It contains information about a single attribute, and it is made of the type of the attribute (e.g., pressure or temperature), its limit type (i.e., max, min, nominal, or not applicable), its value (either numerical or a selection from a set of possible values), and its measurement unit. Each instantiation of a Parameter can be shared by multiple instantiations of Method. For example, an instance of the element Process called "Casting Plate 90" will have a link to an instance of an element Method called "Casting Plate 90 method", and this last one will contain a list of instances of the element Parameter, such as "Pressure/Max/10/bar" or "Temperature/Nom/300/◦C". These parameters can be also used by the Method instantiation "Casting Plate 125 method" when the parameter Pressure does not change with the size of the grid.

Thus, this independency of Parameter-related Method allows the same parameter to belong to different methods. This inheriting process should not be confused with the type of inheritance between classes in typical Object-Oriented Programming (OOP). In the OOP case a child class inherits the attributes of its parent class, but in the proposed structure both an attribute and the specific values of such an attribute are inherited from an instance of the parent class to the instance of the child class. With this idea, each of the component subclasses can have links to multiple Method elements containing several types of technical data related to the family of the component (e.g., a method to define the material and supplier applicable to all hex bolts made of stainless steel, a method to define the thread and diameter applicable to all hex bolts with a standard thread and a diameter of 5/8", and a method to define the length applicable to a hex bolt with a length of 6").

**Figure 5.** PLM structure of items.

The defined relationships and attributes for the PLM system are (Figure 6 shows an example):


**Figure 6.** Example of the PLM structure of items (OEE: Overall Equipment Effectiveness).

Finally, each of the explained elements will have a set of standard attributes that contains the basic data of the element. These attributes are:


The next section presents the communication models developed for this work. These models define the communication among the main four actors of the proposed system: user, agents, PLM system, and CBR system.
