Innovative Production Machines and Systems Conference

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.

The knowledge base is an instantiation of the knowledge model.

Conceptual modelling involves the formalisation of domain knowledge in a high-level, application-independent, yet authoritative and rigorous way. The conceptual modelling aims the development of a knowledge base for product support.The knowledge base contains two models: architectural and functional.
The objective of the first phase is to organise data in a way that ensures homogeneity and validity of the resulting information. The use of ontological principles is deemed appropriate because of the formality and richness of ontological knowledge modelling. This approach takes advantage of some widely accepted notions in KE, such as concept, instance, and relation.
Concept is a class of objects from the real world. Instance is something that specifies a concept by illustrating a real world object that belongs to that concept, such as Peugeot 206 (A) for the notion of cars.
Relation is an attribute shared by objects in the subject domain that links and/or constrains them. One of the main ontological relations is generalisation. For example “car is-a vehicle” (C) is a generalisation type of relation.
In addition to these main ontological elements, this approach suggests the use of new structures, such as domain and connector. These are employed to enrich the representation ability of the system.
Domain is a hierarchy of concepts (i.e. concepts linked with “is-a” relation), which describes a part of the real world and is a concept itself. For example a domain “Product” (D) includes the hierarchy “car is-a vehicle is-a Product”. Relations that associate different domains are called connectors.The structural components described above, except for instances and their associations, enable the composition of the architectural model.
The aim of the second phase is to put the structured information into productive use, within the context of product support. During this phase the architectural model is enriched by employing two new notions, knowledge-specifier and arc, which are further used in defining predicates and cases.
Knowledge-specifier is a property that is considered so significant within the application domain that it is represented as a different concept. For example, it may be useful to know whether a product is viewed as complex or not, since that can define the way in which the support provided is adapted. Therefore, a knowledge-specifier called “ProductType” (G), which defines product’s complexity, is introduced. The level of the product support will be determined using mechanisms that include “ProductType”.
Arc is a relation that links the knowledge-specifiers with other concepts and/or domains.
Connectors can be characterised as active or inactive depending on whether the real world components they describe exist or not.
The possibility of having such cases is represented by the connector-dependence (CD) measure. CD can take two values and be either true or false depending on whether the connector is always active or not.
The notions introduced enable the creation of the system’s functional model.
The combination of the architectural and functional models results in the development of the system’s knowledge model.

The goal of any product support system is to deliver knowledge that is accurate, applicable, reliable and user-tailored. To do that, the product support knowledge base should contain relevant knowledge about the products, users and their tasks, as well as identifying the way in which these are linked to each other.The overall process of transforming data into knowledge has three stages. First, relevant raw data of the products, tasks and users is gathered. This includes CAD models, bills of materials, drawings, assembly sequences, and user attributes. Next, this data is organised into information by identifying common relations between data items and employing them in accordance with ontological principles and semantics, as will be described in the following slides. The resulting structures are further analysed and then used in model and case-based reasoning algorithms, to make them available for productive use.

Product support is often described through the various forms of assistance that companies offer to their customers. Traditionally, it is associated with the provision of supplies, tools, equipment and facilities, as well as information.
Although, in general, access to knowledge is recognised as a critical part of any pro-active and creative business strategy, product support is rarely viewed as a knowledge engineering activity. In fact, job tasks involved in the creation of knowledge are perceived to be very different from those that have traditionally been expected of the technical writers and technical educators concerned with product support.
The aim of this work is to demonstrate that product support is a knowledge intensive process that should be modelled using knowledge engineering methodology.