Innovative Production Machines and Systems Conference

The structured approach presented in this paper advances product support by segmenting the development phase of the system’s inference mechanism into small manageable steps. These include determining the kind of product support problems that the system is expected to handle, and selecting accordingly the reasoning technique that should be followed. The types of product support problems predetermine the situations with which the product support system should be able to cope with. The multi-modal reasoning strategy proposed enables the system to respond to a variety of user queries since case-based reasoning is utilised in providing accurate and personalised information while model-based reasoning is used to compensate for the lack of documentation resources. The conducted analysis denotes a correlation between problem solving and product support, indicating possible collaboration between the two research communities in terms of approaches and methodologies.
Future work includes the development of a product support knowledge engineering framework, where the proposed approach will be integrated with knowledge-based models.

If the user selects the browsing mode, the solution given to him/her is a pre-composed document. On the other hand, if the choice is to use the case-based reasoning tool, the user is presented with a list of ranked hypotheses and given the choice to select those that best fit his/her interests. Finally, the user is presented with an adapted solution.

The stages of the process when a previously solved problem is detected (Fig. 1 (A)) include retrieving relevant cases, reusing them, presenting the best match as a proposed solution, evaluating this solution, and retaining it in the knowledge-base.
If the problem is similar to a previous one (Fig. 1 (B)), an extra stage (i.e. solution adaptation) is needed, where case-based reasoning adaptation techniques can be utilised.
Fig. 1 (C) shows the solving process for a new problem. Model-based reasoning is employed at each stage for identifying new problems, classifying the cases’ attributes according to the models, and configuring the generated documents. Enrichment of the models employed is also possible.

Previously solved/same PSPs are problems that have already been solved by the system.
The reasoning technique used should be able to retrieve solutions without repeating the reasoning process, as well as be able to compare the specifics of different problems. Naturally, case-based reasoning is considered as the most appropriate technique.
Similar PSPs are problems for which the current set of observations is not the same as any of the previous ones but which shares similarities with them. The new PSSs can be produced by removing, adding, replacing, and adapting IOs and IOCs used in previous situations.
Case-based reasoning provides means for adapting solutions according to previous experiences. This feature is highly utilised here.
New PSPs occur when there are no similarities between earlier observations and new ones.
The existence of a new problem that has little or no similarity with previous experiences cannot be easily managed by CBR alone. In this case a multi-modal reasoning strategy is needed. General knowledge about the application domains (e.g. product domain), contained in the models, can be utilised to support the case-based reasoning component.

There are two main factors that define the structure, content, and presentation of a document generated by a product support system. These are the domain and the environment within which the system is deployed. Domain-specific elements include the products and the tasks that are supported, as well as the documentation resources that describe them. Environmental-specific elements consist of user, location, time and purpose dependent features.
A Product Support Problem (PSP) is a 4-tuple PSP := (MOD, HYP, CON, OBS) where:
MOD is a finite set that includes knowledge about the domain (i.e. supported products and tasks) that is represented with corresponding models. MOD also contains the links between these models and relevant IOCs and IOs.
HYP is a finite set of combinations of elements of MOD. Each combination corresponds to a possible documentation configuration. The arrangement of MOD combinations and documentation configurations will be referred to as hypotheses.
CON is a finite set that includes knowledge about the application environment. It is represented by related models (e.g. user model (UM) or system’s specifications model). CON will be referred to as the system’s context.
OBS is a finite set that consists of the observations acquired by the current query. OBS should correspond to elements of MOD and CON.
Given a product support problem
PSP := (MOD, HYP, CON, OBS) and a finite set of observations OB such that OB a subset of OBS, then valid hypotheses are represented by VH where VH subset of HYP if and only if, MOD and CON and VH infer OB. Product support solution (PSS) can be every hypothesis ‘h’ that h is an element of VH. The best solutions are considered the ones for which OB=OBS.

In the context of product support, the first step is to identify the required resources and to define the product support problems (PSPs). The problem solving process continues by determining the type of a PSP and the course of actions that should be followed for reaching a product support solution (PSS).
Ideally, product support documents should be constructed using information objects (IOs). An IO is defined as “a data structure that represents an identifiable and meaningful instance of information in a specific presentation form”. Information Object Cluster is a 2-tuple IOC:=({IO}, S) where {IO} is the set of IOs sharing a common property that are arranged in a structure S.Document (D) is a 2-tuple D := ({IOC}, S) where {IOC} is a set of logically structured IOCs.

Divide and conquer and building block techniques are employed in rule-based reasoning, where expert knowledge is represented using rules. Solving by analogy is utilised in case-based reasoning (CBR), which retains and reuses previous solutions generated by the system. Means-ends analysis is used in model-based reasoning (MBR), which employs general knowledge about the application domain.
These approaches differ in terms of the knowledge, inference cycle and inference process involved, as follows.
Knowledge. Rules and cases represent specific knowledge while models capture general knowledge. For example, an instance of a clutch can be represented using a case with a number of attributes, each of them containing specific knowledge about the type of clutch. The same clutch can be represented using models, which contain generic knowledge such as “clutch is an assembly”.
Inference cycle. Rule-base technique follows an iterative cycle, while case- and model-based techniques reuse previous solutions.
Inference process. Rule-based reasoning creates a series of progressive inferences between the problem definition and its solution rather than modifying parts of old solutions, as it is in case-based reasoning.
Studies show that the most common AI technique used is rule-based reasoning, which is primarily employed in troubleshooting.
A number of researchers have used CBR for diagnosis and help-desk applications.
The research reported in this paper extends these approaches by studying the inference mechanism in a structured manner, which enables the segmentation of the development process into smaller, more manageable steps. The application of multi-modal reasoning in product support systems has not been thoroughly researched. Therefore, the integration of CBR and MBR is a significant part of the presented approach.

Product support is defined as everything needed to support the continued use of a product. Advanced product support takes various forms, ranging from interactive technical manuals (IETMs) to intelligent product manuals (IPMs) and electronic performance support systems (EPSSs).
Efficient support involves answering to users’ queries by providing accurate and user-tailored information. Each user query can be represented as a problem, using approaches from problem solving research. The diversity of the problems posed to the system should be an essential consideration throughout its design.
This paper supports the view that a structured problem solving approach can be used throughout the development of a product support system.

This paper focuses on the representation of the knowledge about users, products, and tasks that a product support system should contain. Knowledge is acquired following a three stage process of transforming raw data into information and knowledge by the utilisation of ontological principles. New notions are introduced (domain, connector, knowledge-specifier, and arc) for formalising the acquired knowledge and applying it in the context of product support. A new measure (connector-dependence) is also proposed to ensure the completeness and validity of the developed structures. In addition, a knowledge base has been developed based on the knowledge model described.
This new approach for representing product support knowledge formalises the context within which a product support system operates and improves the product support responsiveness by prescribing the knowledge sets used and how these should be represented. The knowledge model provides an ontology that can be shared and reused by product support systems. It introduces the structural components needed, the links between them, and establishes their usability. The developed ontology advances the interoperability between product support and other knowledge intensive fields, by representing the elements of knowledge in a machine processable way. Furthermore, it facilitates the provision of adaptive and personalised support.
This work is a step towards formalising product support as a knowledge intensive process. Future work includes the development of a product support framework, where the developed knowledge base will be one of the major components.

The knowledge base is created using the Protégé ontology editor, and part of it is depicted in Fig. 3 with the Jambalaya plug-in. The squares in the figure represent concepts. An “is-a” relation is represented by placing a square within a bigger one. The connectors between different domains, with CD being false, are represented with bold straight lines, and with CD being true are shown as bold curved lines. The straight lines that link the black squares (instances) are connectors, with CD always false, linking different instances. The knowledge-specifier (“ProductType”) is shown as a rounded square and the arcs that link it to the other concepts are represented by bold dotted lines. THING (the domain within which everything is contained) is the root concept of the ontology.