Study on an architecture of ontology-based task modeling and deduction for automotive troubleshooting service

Abstract

The rapid development of today’s smart automobile with increasing functionality and complexity, which results in rising requirement and cost for its troubleshooting service in the after-sales stage. Hence, to keep the firm’s competitive strength, effective design knowledge utilization of automotive created from the task model can promote the feasibility making of a troubleshooting procedure by offering available relationships and semantic scheme of task. The proposed architecture primarily consists of base, field and application three tiers. A formalized representation of ontology, OWL, is used to organize the base filed. The filed tier includes extensional notions and relations for integration of troubleshooting and a criterion repository for verifying solution feasibility, which is depicted in SWRL. In the application tier, a deducing module is generated on the basis of ontology and criterion deduction. To enhance this semantics, in this research, a task modeling and deduction mechanism with feature-intensive ontology are proposed to clearly represent correlative notions for automotive troubleshooting planning (ATP). A criterion-based deducing module on the basis of OWL-DL and SWRL is also applied to specify implied relations through merging deducing modules (DMs) to deal with complex feature data. Eventually, this proposed architecture is examined and verified with an instance relevant to automotive troubleshooting procedure.

Introduction

As competitive pressure increase in automotive industry, after-sales service is one of the key success factors for motor companies.^1,2 Furthermore, the rapid development of today’s smart automobile with increasing functionality and complexity, which results in rising requirement and cost for its troubleshooting service in the after-sales stage.^3–5 Hence, to keep the firm’s competitive strength, shortening the time of problem-solving process is one of the effective approaches. The troubleshooting process is a vital activity of after-sales service, in which a car is recovered integrating the several portions: motor company, material/tool supplier, auto repair shop and end user in terms of an effective time and cost consideration.

Task modeling and troubleshooting process have become key study issues in the near decade.^3,5,6 The former has revealed as an inclusive notion for catching features and semantic messages during the troubleshooting process ³ ; the latter is the outcome of automotive troubleshooting planning (ATP), which concerns feasible resources to streamline the entire troubleshooting (or scheduled maintenance) process.^3,4 There are many studies presented different models and solutions about troubleshooting process over the past decade. One of the proposed techniques, computer-aided process planning, has promoted ATP by obtaining the appropriate order of problem-solving operations offered the activity expression of the troubleshooting. ⁵ Even though these modes and approaches have been broadly explored, intrinsic restrictions in the present work still appears while it involves the information interaction between the task model and ATP. The efficient inferring of such information also keeps to be mentioned. ATP is on the basis of both the procedure messages and the underneath feature data in task models. Specification, material, tool, and mobility of components are the major elements that have to be deliberated in a troubleshooting process. Furthermore, ATP has to combine such messages to enhance the semantics in representation of task model and promote the capabilities of decision-making. Ontology-based modeling can represent united, structural, and semantic messages. In addition, it also allows for inferring capabilities because of the regular and specification with logic mode in the model of information. That is to say, the implied messages are transformed into distinct information.^3,7

In this scenario, an ontology-based architecture of feature-intensive modeling and deduction for ATP is addressed. The troubleshooting activities with ontology mode are developed in light of “task feature.” A deducing module is also presented to reason the procedure of troubleshooting activities on the basis of predefined criteria and the task model. This research is outlined as below: Section 2 reveals the related issues regarding ontology-based architecture of development and inferring in the scenario of ATP. Section 3 stresses the presented ontology-based framework of task modeling and deduction for ATP. Meanwhile, the generation of criteria and deducing modules (DMs) are also discussed. An instance is demonstrated to verify this architecture in Section 4. Eventually, the conclusion drawn and future issue is mentioned in Section 5.

Related work

Within a specific field, knowledge can be represented through ontology which is a formal manner. Ontology has the characteristic of being able to elicit and generalize notions. Meanwhile, it also provides more simplicity to depict attributes and relationships between the notions and information models. Multiple ontologies have been generated to depict each phase of PLC (product lifecycle) in the previous decade.^8–10 In addition, it is used to help reasoning by deductive methodologies in many fields, for example business modeling, ¹¹ aerospace engineering, ¹² manufacturing planning, ¹³ machine tools, ¹⁴ and medical information. ¹⁵

Conventional methods for task modeling in automotive troubleshooting

The conventional methods for task modeling chiefly aimed at the relationship among components of a module or system. Diagram-based approaches, for example genetic algorithm, are presented to reason the orders of feasible task. ¹⁶ But the expression is mainly implemented through priority graphs that involve variables such as procedure times and tiers of troubleshooting by combining troubleshooting priority relations obtained from a series organized items. ¹⁷ However, the developed approaches of troubleshooting plan solo are insufficient, so it is necessary to investigate relations of troubleshooting plan that facilitate ATPs is created automatically based on different methods, for example, applying algorithms of neural network and matrixes of design structure.^18,19 This method also assists in the complexity reduction of ATPs, in which task priority indicates task sequence among components by taking main qualitative task restrictions, such as feature intervention, feasibility, and stability of function. ²⁰ This further reveals that knowledge integration is very important for making the decisions of ATP.

A new method of task modeling is mentioned for the automatic construction, choosing, and assessment. ²¹ A method of reference pattern is proposed for task modeling from the aspect of reference feature inferring. ²² Yet, to make task modeling feasibly, it is necessary for connecting tasks with their corresponding tools and decisions. Besides, this also reveals that an efficient inferring module is needed for integrating knowledge into task modeling, it can effectively aid decision-making in phase of troubleshooting planning. Yet, few kinds of studies can be addressed on knowledge depiction of troubleshooting planning and its reasoning from task model with feature mode. In the semantic web, ontology is an important pillar for enriching knowledge description.^3,23 Meanwhile, it also improves comprehensibility of information model to eliminate the ambiguity.^5,24 Hence, knowledge with ontology mode becomes a focus of research in recent years.

Ontology-based information model in product development

There are many studies presented in ontology-based information model of product development. PSL (process specification language) is proposed by NIST (National Institute of Standards and Technology). It is utilized to support the interexchange of process messages automatically among a broad and different process utilizations, for example, modeling, scheduling, management, and simulation. ²⁵ OntoSTEP is addressed to transform the geometric data of product with STEP format into ontology.^26–28 ONTO-PDM, a product-oriented ontology, is generated for interoperability of product information management during the manufacturing settings. ²⁹ An ontology-based architecture is depicted to represent the knowledge with functional structure in product design stage. ³⁰

Furthermore, the relationship between information modeling and decision-making process has to be considered for making decisions effectively. For instance, the models with entity mode regarding component and assemblies are developed and investigated their utilizations in planning of assembly procedure. ³¹ A method of OWL (web ontology language) representation is mentioned about a product knowledge model with express-oriented mode. ³² The notions of ontology are also applied on the decision-making of product disassembling process through CBR (case-based reasoning) ³³ and product life cycle within product sustainability. ³⁴ A hierarchical graph is depicted for the examples of consecutive and concurrent assemble activities in open architecture products. The priority restriction of knowledge between parts and units to create tasks of achievable assembly.^35,36 A formal ontology-based assembly sequence planning is addressed for the specific product assembly. ²⁸ An organized ontology-oriented mereotopology with space-time mode is introduced in assembly-based design. ³⁷ Because the deducing module is not included in the before-mentioned studies, this results is limited availability.

To develop reasoning mechanism, the model with assembly relation is presented to depict the messages of assembly on the basis of relationships between components and assemblies. ³⁸ An architecture of product collaborative development is proposed through integrating model of product information with a criterion-based mode. ³⁹ By utilizing SWRL and entity-oriented model with ontology form to promote the members’ collaboration. ⁴⁰ A mechanism of ontology deduction is stressed to reason the implied messages in the product. In addition, a framework of hierarchical semantic utilization for the deducing module is implemented to inquiry and infer messages from product repositories. ⁴¹ However, the details of feature information are not in-depth regarding these cited researches.

Ontology-based knowledge of machinery in maintenance and problem diagnosis

Ontology-based approaches and frameworks are also applied in complex machineries. A knowledge structure diagram of fleets in the machine field is addressed on the basis of ontologies for diagnostic goals, offering participants with more knowledge and integrated messages regarding the behaviors of system.^42,43 A method of smart problem diagnosis is proposed on the basis of ontology, which revealed an instance of smart problem diagnosis principles.^44,45 A framework of ontological pattern is proposed to get a universal knowledge representation for machine state in factory. ⁴⁶ The method solves the heterogeneity in traditional machine documents. Besides, it also becomes an accessible format for offering the extraction and sharing of knowledge in diagnosis stage. However, present studies in maintenance or problem diagnosis of machinery are less focused on systematized, extensible, and multi-functional way. Conventional expert platforms, for example, can conduct effectively one special problem of machinery, yet not the others. Despite ontology-oriented approaches and platforms can combine the diagnosis modules of problem, the discovering and recognition of problem are still weak. Cheng et al. ⁴⁷ mentioned the some causes regarding the application of commercial software is discretely seen all over machinery field, involving issues of adaptability, installation and cost of the sensors as well as obstructions of in appropriately combination into hardware, software performance, and interface. In addition, still there are several issues: (1) reuse – it is not easy to build and reuse for other machines through the conventional knowledge representation, for example the rule of if-then. The approaches with signal-based mode encounter difficulties in adjusting to different states or machines; (2) update – owing to variation of working states and inevitable aging of parts, the pre-designated variables, methods, and modules may barely assure the requirement of diagnosis and inspection, which creates demands of re-build; (3) merge – to create an integrated system of problem diagnosis regarding complex machineries, it is not satisfactory that studies on problem detection for a few trouble sorts or parts. Conventional expert platforms are inappropriate in semantics to organize different approaches.

In the perspective of manufacturers, products with many models (such as machinery, automotive) and their problem types, it is ineffective and unessential to build a system of problem diagnosis for each product and problem sort. In the aspect of end user, according to different purpose, financial consideration, and future usage, the requirements of product after-sales service are various (e.g. maintenance, diagnosis, and troubleshooting). In the viewpoint of product itself, properties such as the sort, phase of life cycle, present state, structure, maintenance record, interaction ability, and level of intelligence differ a lot. Hence, it is very essential for constructing an architecture for troubleshooting with good adaptability, extensibility, and integrity.

In view of the primary target of the study and the past works survived, it is deduced that there is a requirement for a deducing module that can reason troubleshooting relations on the basis of definite criteria to promote decision making in ATP. Modeling and deduction of feature-intensive ontology is involved in this research as an architecture to not only enhance knowledge depiction, but offer a communication in two fields, process and product for the eventual ATP. The details will be depicted in the following sections.

Modeling and architecture of automotive troubleshooting planning

Automotive troubleshooting is a complex and multi-domain issue including principles and skills of problem-solving, knowledge in automotive engineering containing electrical/electronic, material, hydraulic, mechanics, and information. ⁵ To enhance the semantics in ATP and the deduction of implied information in existed repositories, the methodology is presented in this research, which applies the feature messages and task representation to preferably indicate the feasibility of problem-solving. There are two main portions involved in this proposed methodology: (1) a model with ontology mode that defines the terms and information scheme for ATP; (2) a deduction mechanism that deduces the relations among the present messages.

As shown in Figure 1, the data from activity model is analyzed, introduced, and gathered as the ontology element, which involve many implied relations among feature, structure and procedure. According to the pre-specified criteria and deducing modules created based on the knowledge of troubleshooting process, derived relations can be deduced from the implied relations to make decision for ATP effectively. The critical notions of troubleshooting manipulations and their relations are included in the ontology model. To assure the integrity, OWL-DL ⁴⁸ is used for clarifying and organizing these notions and relations. Meanwhile, the digraph, a kind of graph theory, is also utilized to depict the model with OWL-DL mode. ⁴⁹ The ontology-based approach for automotive troubleshooting is revealed in Figure 2. First of all, the prior messages are analyzed regarding the automotive to be investigated, involving structure, knowledge of troubles (e.g. types, possible causes), and criteria of diagnosis can be acquired. Next, the task models of troubleshooting and knowledge repository are constructed by applying feature-intensive ontology (FIO_TMT), involving OWL and SWRL two libraries. The problems discovered through technician or detector can be corresponded to the individuals in the knowledge repository with ontology mode. Hence, knowledge inferring can be executed to get more messages with regard to the problems, involving properties, possible causes, and solutions. For common troubles, present knowledge (axioms on the basis of depiction logic) is sufficient. SWRL criteria offer a flexible way for inferring. By applying SIWRL module, ⁵⁰ the present knowledge can be inquired easily.

Figure 1.

Conceptual diagram of the proposed architecture.

Figure 2.

Diagram of automotive troubleshooting with ontology mode.

The architecture primarily consists of base, field and application three tiers. First of all, in the base tier, it consists of the KPM (kernel product model), the ISO 10303 AP242 and the SAE vehicle standards ⁵¹ two standards, which transforms kernel knowledge into kernel ontology. It is used to define common notions, relations and constraints for the whole architecture. Meanwhile, in the filed tier, it is composed of the extensible ontology and the criterion repository. It is adjusted based on the various automotive sub-systems. Eventually, in the application tier, it is composed of a deduction module for inferring ontology. When a symptom or problem is extracted from the client application, the deduction module then takes advantage of the semantic criteria and ontologies in field tier to reason the all possible causes and their corresponding solutions. The results then be transformed into OWL and feedback to the client end, such as technician, for making a reference of problem-solving.

The digraph of an example is illustrated in Figure 3. There are three portions involved in the structure of ontology: object, attribute, and class. The attribute group means the connection of two objects; the attribute message connects an object with a definite sort of data. Two attributes, group and message, are included and defined in attribute. A class represents the notion and the object is a case of the class. The OWL-DL model can depict attributes and their constraints. The attribute depiction explains the properties in a universal scenario. The attribute constraint clarifies properties in the scenario of a particular class. The both attributes enhance the semantics in the relationships among notions. Some implied relationships, in following phases, will be reasoned by deduction modules for making decision.

Figure 3.

Diagram of the digraph representation with OWL-DL mode.

Ontology model with OWL-DL representation

To obtain universal kernel notions of automotive troubleshooting, the proposed architecture is primarily composed of KPM (kernel product model), SAE vehicle standards ⁵¹ and OWL as illustrated in Figure 4. The KPM is a universal and un-concrete model with universal semantics that depicts the universal messages of part features of various products regarding a specific field. It is constructed at a preceding phase of product descriptions.^52,53 It is also applied to help the semantics of type and function of the part features. ⁵⁴ The ISO 10303 AP242, an ISO standard, is adopted to represent and exchange automotive mechanical design information. ⁵⁵ It can be applied easily to connect the other present ontologies. The kernel notions from the above-mentioned three resources are elicited. As for the logical axioms and relations among the elicited kernel notions, are also decided in the base tier.

Figure 4.

The architecture of the ATP – Base tier.

To definitely depict the ontology model for ATP, the vital notions must be defined. They are represented as classes and categorized as entity feature, structure, and procedure of troubleshooting. Every class has its sub-classes. An example of a kernel notions constructed and illustrated in Figure 5 on the basis of OWL-DL by Protégé. Figure 6(a) is an instance of kernel message attributes hierarchy of the base tier, which designate the kernel diagnosis knowledge. There are several sub message attributes included in attribute message“unit_ specifications,” for example, “force,”“length,”“resistance,”“temperature,” and “thickness.”Figure 6(b) reveals another example of kernel group attributes of the base tier, which designates the kernel repair knowledge. Attribute group“solved_by” has its sub group attributes, such as “replaced_by,”“ground_by,”“adjusted_by,”“assembled_by,” and “disassembled_by.”

Figure 5.

Snapshot of kernel notions with OWL-DL in Protégé.

Figure 6.

Snapshot of kernel attributes of the base tier: (a) Kernel data attributes and (b) Kernel object attributes.

Entity feature of troubleshooting

There are many detailed feature information involved in the troubleshooting. According to the SAE vehicle standards, ⁵¹ entity feature of troubleshooting is depicted through some fundamental features, for example, member, tool, material, component, and resource, etc. The OWL-DL model with entity feature is able to be revealed through the attributes and categorized as illustrated in Table 1. These attributes are chiefly made up of functional relations. A Structure, for example, consists of a BrakingSubsystem. The attribute hasFeature that links the two classes. The feature information can be acquired from an auto manual, which is provided through all motor companies, and then configured as in form of ontology.

Table 1.

List of the attributes in troubleshooting entity feature.

Attribute	Field	Scope
hasFeature	Structure	Resource
hasMember	Resource	Member
hasTool	Member	Tool
hasMaterial	Tool	Material
hasComponent	Material	Component
hasDirection	Component	Direction

Structure of troubleshooting

This class reveals the structure of troubleshooting information from automotive system to planning of troubleshooting process. Generally, a sub-system consists of units, while a unit can be father disassembled into components and single parts. The related position and orientation of components are predefined through feature restrictions. In the proposed ontology model, the defined attributes and classes of troubleshooting structure are listed in Table 2. Based on this hierarchical configuration, the relationships among classes, for example, component, unit, sub-system, and system are constructed by using attributes, such as ConsistOf and isMadeUpOf. Restrictions are defined among these classes by designating an attribute restriction or hasRestriction. Because ConsistOf and isMadeUpOf are also explained as reverse attributes by putting the attribute depiction owl:reverseOf between them, it is with restriction or hasRestriction.

Table 2.

List of the attributes in troubleshooting structure.

Attribute	Field	Scope
isMadeUpOf	System	Component/Mechanism
ConsistOf	Component/Mechanism	System
hasRestriction	Structure	Restriction
Restriction	Restriction	Structure

Procedure of troubleshooting

This class carries the messages that combines several resources in a reasonable and time-ordered mode. It involves a range of fundamental factors, that is, manipulations of troubleshooting. According to the different phases, one (or several) certain task(s) is/are implemented applying specific resources. Besides, each manipulation has corresponding relations, for example, task sequence (prior, posterior) and time span (initial, finish). The attributes of a troubleshooting procedure are defined in the ontology model (as illustrated in Table 3). Meanwhile, the classes that connect with them are also listed in this table. The proposed ontology model of troubleshooting procedure is represented (as shown in Figure 7) by applying digraph. Regarding the initial and finish tip of a task manipulation, they are revealed through message attributes, initialTip and finishTip, which are categorized in a message sort tipTime. As for the taskPrior and taskPosterior, they are group attributes that link two task manipulations and specified their order. The structure to be changed in the related manipulation is specified with attribute altering. While replaced, the structure is specified as attribute replaced in the corresponding manipulation. The resource to be utilized is specified with the attribute utilize. There are two factors, depiction of attribute and constraints, provided for entirely representing the relations among various manipulations. In addition, the relevant structure and resource are also utilized in them.

Table 3.

List of the attributes in troubleshooting procedure.

Attribute	Field	Scope
taskPrior	Manipulation	Manipulation
taskPosterior	Manipulation	Manipulation
initialTip	Manipulation	xsd:tipTime
finishTip	Manipulation	xsd:tipTime
utilize	Manipulation	Resource
altering	Manipulation	AlteringStructure
replaced	Manipulation	ReplacedStructure
check	Manipulation	CheckStructure

Figure 7.

The digraph representation for OWL-DL model of troubleshooting procedure.

Extensible ontology

Extensible ontology, for example, automotive troubleshooting, is specialized from the kernel ontology in the base tier. When ontology of filed tier is more particular which is customized on the basis of field knowledge and user utilization, the base kernel ontology can be treated as an un-concrete form that is composed of un-concrete attributes and classes. For example, a manual wrench for removing/assembling hex bolt can be further split up into several types: adjustable, box-ended, combination, ratcheting, etc. The field ontology also designates the relative postures of various components. In the perspective of troubleshooting planning, particularly in the diagnosis or repair phase, the assembly/disassembly planning, rely on the relative posture among components in the system. To represent the posture of a changed/replaced component, the posture ontology is created and its related attributes are defined (as illustrated in Table 4). There are 12 variables (v₁ to v₁₂), for instance, defined for the posture messages of an assembly/disassembly. The first three, v₁ to v₃, indicate the relative coordinates to the origin of the absolute positioning system. As for v₄ to v₆, v₇ to v₉, and v₁₀ to v₁₂ reveals the vector coordinates of the axes a_x, a_y, and a_z in the relative coordinate system, respectively. Hence, 12 message attributes are involved in the class Posture, which is the spectrum of the hasPosture attribute. By using this, the relation with specific Posture class is created in class Structure. The other attributes of Table 4 are applied to construct relations among various classes. Furthermore, the field ontology also designates the message attributes of components. As illustrated in Figure 8, messages attributes are organized through OWL-DL. It is composed of actual value that designating various properties for each feature mentioning. The sort of message could be float, string, or Boolean. In addition, it can easily calculate and infer regarding the inconsistency of the notions. ⁵⁶ Due to two kinds of syntaxes, RDF and XML, it can exchange easily messages among heterogeneous systems. Thus, the knowledge can be comprehended by several utilizations in automotive troubleshooting. It is also applied to limit the conditions and many other feature needs on the basis of member field scene, which assists to promote the verification of problem-solving during troubleshooting procedure by minimizing the repetitions in knowledge utilization.

Table 4.

List of the attributes in component posture.

Attribute	Field	Scope
hasPosture	Structure	Posture
hasRotation	Axis	Rotation
hasSpot	Axis	Spot
hasAxis	Posture	Axis

Figure 8.

The partial formalized message attributes through OWL-DL.

A trouble has to be conducted by using many various phases, such as inspecting, diagnosis, repairing, and verifying. In the troubleshooting ontology of field tier, partial abstracted troubleshooting phases can be further divided into specified phases. For instance, as illustrated in Figure 9, a measuring task in the diagnosis phase can be split into component, hydraulic, electric, and controller. Each task includes some information, for example, measuring knowledge of component involving dimension, position, the characteristics of measuring tool, materials, and standards. These messages are encoded in OWL format so as to limit the rules or feasibility of various troubleshooting phases offered through the cause field and utilization.

Figure 9.

Mapping diagram among troubleshooting ontologies by object attributes.

The ontology of troubleshooting is associated on the basis of a notion mapping module that is composed of object attributes among structure, entity feature, and procedure. As illustrated in Figure 9, the object attributes are also converted into an OWL form, which designate the relations among these ontologies. It is hub bridge for mapping three knowledge.

Repository of criterion

To offer solution suggestions for various automotive troubles, a repository of criterion is required for accumulating expertise criteria that are depicted on the basis of automotive knowledge. A SWRL, criterion-oriented modeling language, is used in this research. Based on the attributes and the classes that have been pre-defined in the proposed ontology in the OWL, the relations between variables and restrictions of task feature are transformed and depicted in SWRL. There are two main criteria, deduction and restriction, stored in this repository of criterion. The former is applied to reason variables and process of ATP. It is defined through the professional members, for example, technician, engineer, etc. The following expression, for example, shows that if there is a brake pedal height with length is between 144.1 and 154.1 mm, then it can be measured by ruler.

$$\begin{array}{l}\mathrm{brake}\_\mathrm{pedal}\_\mathrm{height}\left(?\mathrm{u}\right)\wedge \mathrm{length}\left(?\mathrm{u},?\mathrm{v}\right)\wedge \mathrm{swrlb}:\mathrm{greaterThanOrEqual}\left(?\mathrm{v},144.1\right)\\ \wedge \mathrm{swrlb}:\mathrm{lessThanOrEqual}\left(?\mathrm{v},154.1\right)\wedge \mathrm{ruler}\left(?\mathrm{w}\right)\to \mathrm{measured}\_\mathrm{by}\left(?\mathrm{u},?\mathrm{w}\right)\end{array}$$

Furthermore, the latter is used to limit variables and/or processes. It can be further divided into capacity and process two restrictions. The following expression, for instance, indicates that if there is a brake pedal height with length less than 144.1 mm and it is measured, then the result does not meet the norms.

$$\begin{array}{l}\mathrm{brake}\_\mathrm{pedal}\_\mathrm{height}\left(?\mathrm{u}\right)\wedge \mathrm{length}\left(?\mathrm{u},?\mathrm{v}\right)\wedge \mathrm{ruler}\left(?\mathrm{w}\right)\wedge \mathrm{measured}\_\mathrm{by}\left(?\mathrm{u},?\mathrm{w}\right)\wedge \\ \mathrm{swrlb}:\mathrm{lessThan}\left(?\mathrm{v},144.\mathrm{1}\right)\to \mathrm{has}\_\mathrm{irrationality}\left(?\mathrm{u},“\mathrm{the}\mathrm{result}\mathrm{does}\mathrm{not}\mathrm{meet}\mathrm{the}\mathrm{norms}”\right)\end{array}$$

Deduction of ATP ontology

In this ontological model, there are still abundant implied relations except the definite relations have been constructed, particularly those cores among feature entities. They could be reasoned by using a deducing module to assist decision-making in automotive troubleshooting planning. The proposed deducing module of troubleshooting process will be explored below.

The module of ontology deduction

On the basis of OWL-DL, the presented ontology model involves a set of bivariate functions, with each bivariate function expressed as (u,Z,v) or Z(u,v), in which u and v indicate two objects relative to attribute Z. Therefore, the inferring procedure of implied relations can be depicted through the following expression.

$$\begin{array}{l}Goal:\\ Z_{\mathrm{m}}\left(u,v\right),u,v\in OntObjects,Z_{\mathrm{m}}\in TruthBase\vee DeduceBase\\ S\cdot T\cdot \\ A_{11}\left(u_{11},v_{11}\right)\wedge A_{12}\left(u_{12},v_{12}\right)\wedge \dots \wedge A_{\mathrm{1p1}}\left(u_{\mathrm{1p1}},v_{\mathrm{1p1}}\right)\to \exists u_{\mathrm{w1}}\exists v_{\mathrm{w1}}{T}_1\left(u_{\mathrm{p1}},v_{\mathrm{p1}}\right)\\ A_{21}\left(u_{21},v_{21}\right)\wedge A_{22}\left(u_{22},v_{22}\right)\wedge \dots \wedge A_{\mathrm{2p2}}\left(u_{\mathrm{2p2}},v_{\mathrm{2p2}}\right)\to \exists u_{\mathrm{w2}}\exists v_{\mathrm{w2}}{T}_2\left(u_{\mathrm{p2}},v_{\mathrm{p2}}\right)\\ \dots \\ A_{\mathrm{n1}}\left(u_{\mathrm{n1}},v_{\mathrm{n1}}\right)\wedge A_{\mathrm{n2}}\left(u_{\mathrm{n2}},v_{\mathrm{n2}}\right)\wedge \dots \wedge A_{\mathrm{npn}}\left(u_{\mathrm{npn}},v_{\mathrm{npn}}\right)\to \exists u_{\mathrm{wn}}\exists v_{\mathrm{wn}}{T}_{\mathrm{n}}\left(u_{\mathrm{pn}},v_{\mathrm{pn}}\right)\\ A_{\mathrm{kr}}\in TruthBase\\ Z_{\mathrm{k}}\in DeduceBase\end{array}$$

(1)

In the above expression, Z_m(u,v) is the result of deduction. OntObjects means the accumulation of all objects. TruthBase is an accumulation of all the definite objects and attributes. As for the DeduceBase, indicates the accumulation of attributes that have been reasoned. Each row in this expression denotes a restriction, in which A_kr(u_kr,v_kr) is the r_th prerequisite in kth restriction, and Z_k is the deduced outcome of the kth restriction. All prerequisites shall be valid to assure the correct outcome of reasoning in each restriction. To depict the deducing module in detail, there are three phases shown below:

Phase I: Represent all the definite objects and the attributes among them as instances in the existing knowledge, because the truths are composed of them for inferring, as revealed through TruthBase in the expression;

Phase II: Determine the criteria of semantic web on the basis of troubleshooting knowledge. It can be represented as restriction expression in Exp. (1), which act as criteria of semantic web. Besides, it can also be converted into the SWRL. Through a criterion-based inferring module (or engine), e.g. Jena, ⁵⁷ Pellet^58,59 and RacerPro,^60,61 SWRL is easy to be recognized. On the basis of the criterions designated in SWRL, the module is capable of reasoning the implied relations among objects, hence generating new bivariate function to make up the DeduceBase as designated in Exp. (1). A criterion in SWRL, for example, specifies that if there exists two relations, they are connected with O₁ and O₂, O₂ and O₃ respectively, a new bivariate function will be created deducing a relationship between O₁ and O₃.

Phase III: Inquire the outcome by applying a goal equation (as revealed in Exp. (1)). Next, the SIWRL (semantic inquire-intensive web rule language) can be used to inquire the bivariate functions that meet the goal equation. This study will investigate the deducing approaches on the basis of this deducing module of ontology in the automotive troubleshooting planning.

Intensive inferring with DM

The ordinary criteria and logic can represented by typical SWRL, but the deduction of relations among feature knowledge of an automotive and its troubleshooting procedure need the profession-intensive diagnosis and decision-making depend on the various symptoms. The ontology-based architecture with feature-intensive DM mode, therefore, is presented to promote the capabilities of information representation and deduction in this research. As listed previously in Exp. (1), criteria are created on the basis of consideration of several prerequisites. There are two parameters, import and export, included in each prerequisite. According to one of the two returns a Boolean value to decide the state of prerequisite (true or false). Similarly, a DM also involves these variables and returned value. By applying the customized SWRL built-in unit, the several important types, such as expressions, formulas, logical decisions, etc., can be encapsulated in DM. As a result, this DM can intensify the inferring capability and simplify the representation. In accordance with the functional characteristics, the feature-intensive DMs can be categorized into several types: (1) expression – for example, it is used to compute the relative location of replaced components, in which the position of this components in the corresponding unit; (2) formula – for example, computation of actual braking force; (3) logical decisions – for example, identification of diagnosis restrictions, in which a list of decisions are made in accordance with the known states to judge whether definite restrictions reveal between tool and component.

Furthermore, the DM uses the feature messages obtained from SAE vehicle standards ⁵¹ as import variables in this research. As for the calculation and logical decisions with built-in deduced mode, the results, for example troubleshooting restrictions, working torque, free travel in the brake pedal, etc., that are export to assist the decision-making in ATP.

Deduction of troubleshooting procession

Procession for problem-solving, as an essential messages in automotive troubleshooting planning, indicates the procession of troubleshooting manipulations. To construct these steps, it is useful and beneficial to consider several factors comprehensively, that is, structure, entity feature, and procedure. In the proposed architecture, all the implied relations among objects are inferred by deduction module on the basis of the criteria and existing messages. Tables 5 and 6 shows the partial criteria, parameters are revealed after the symbol (question mark in general) and the format is represented as ?u. Regarding both the former term and the last term of criteria, they are connected through continuous dots, for example, u_p∧…∧u_q. Afterward, a goal equation is defined through SIWRL inquiries the deduced procession between troubleshooting manipulations. Because the procession relations between Manipulation objects are recognized in accordance with their taskPrior attributes, the object that has the highest amount of taskPrior attributes have to be handled first. Therefore, by sorting the objects in descending mode of the amount of taskPrior attributes that they own, the procession can be decided. Correspondingly, the goal function can be organized in SIWRL form and listed below:

Table 5.

The partial general criteria for ATP in automotive braking system – inspection phase.

S/N	Criterion	Corresponding SWRL
1	Fundamental tasks are executed first	Fundamental(?u) ∧ Manipulation(?v) ∧ inspect(?v, ?u) ∧ Manipulation(?w)→ taskPrior(?v, ?w)
2	The task has the most executed than other tasks is fundamental task	Task(?u) ∧ intensiveOnto:isFundamental(?u) → Fundamental(?u)
3	Before tooled tasks, the tool-less tasks should be executed (judging fromthe specifications)	Task(?u) ∧ Manipulation(?v) inspect(?v, ?u) ∧ intensiveOnto:hasTool(?u, ?p)∧ Task(?w) ∧ Manipulation(?t) ∧ diagnosis(?t, ?w) ∧ intensiveOnto:hasTool(?w, ?q)∧ differentFrom(?p, ?q) → taskPrior(?v, ?t)
4	If a series of sub-tasks exist in a task, they should be executed before single task	Task(?u) ∧ Manipulation(?v) inspect(?v, ?u) ∧ Task(?w) ∧ Manipulation(?t)∧ Task(?t, ?w) → taskPrior(?v, ?t)

Table 6.

The partial specific criteria for ATP in automotive braking system – diagnosis phase.

S/N	Depiction of implied relation	Depiction of criterion in SWRL
1	The fundamental tasks need to be executed first	Fundamental(?u) ∧ Manipulation(?v) ∧ inspect(?v, ?u) ∧ Manipulation(?w)→ taskPrior(?v, ?w)
2	Regarding the guide bolt loosen, loosen the guide bolt first, then take the broken component out	Bolt(?u) ∧ Manipulation(?v) take(?v, ?u) ∧ Component(?c)∧ hasComponent(?c, ?u) ∧ hasComponent(?c, ?p) ∧ hasComponent(?c, ?q) ∧ Manipulation(?w) ∧ loosen(?w, ?p) ∧ Manipulation(?t) ∧ loosen(?t, ?q) → taskPrior(?v, ?w) ∧ taskPrior(?v, ?t)
3	Regarding the guide bolt fastening, put the new component to the exact position first, then fasten the bolt/nut	Bolt(?u) ∧ Manipulation(?v) put(?v, ?u) ∧ Component(?c)∧ hasComponent(?c, ?u) ∧ hasComponent(?c, ?p) ∧ hasComponent(?c, ?q)∧ Manipulation(?w) ∧ fasten(?w, ?p) ∧ Manipulation(?t) ∧ fasten(?t, ?q)→ taskPrior(?v, ?w) ∧ taskPrior(?v, ?t)

$$\begin{array}{c}\mathrm{Maniuplation}(?\mathrm{u})\wedge \mathrm{taskPrior}(?\mathrm{u},?\mathrm{v})\wedge \mathrm{siwrl}\hfill \\ :\mathrm{select}(?\mathrm{u})\wedge \mathrm{siwrl}:\mathrm{quantity}(?\mathrm{v})\hfill \end{array}$$

(1)

Through the implementation of above expression, a list of troubleshooting manipulation activities will be shown. It reveals all the Manipulation objects and the amount of taskPrior attributes that each object includes in descending sequence. Therefore, the troubleshooting procession will be recognized from the record.

Implementation

Figure 10 illustrates the application tier that is composed of several portions: an elicitation module of variables from client application interface, an instantiation repository of troubleshooting knowledge, a reasoning module, and a suggestion module for troubleshooting and recommended solving processes. In the process of instantiation, the variables of feature and procedure are elicited from client application software and defined with specific values. In addition, the case of automotive troubleshooting knowledge are also instantiated with class of field ontology. Then the corresponding variables are connected through the field ontologies to consider feasibility of problem-solving. An alternative will be revealed for solution recommendation when a conflict with field ontologies occurred. To achieve the deduction of field criteria for automotive troubleshooting, the Jena is applied to implement inferring process in this research. It has been used in many various domains for the generation of criterion-oriented platform.^57,62 After the stage of instantiation, the variables and the SWRL criteria are converted into the Jena’s format for reasoning. The deduced results then are transformed into OWL. Through the suggestion module, the solutions will be sent to the client application interface for follow-up disposal.

Figure 10.

Conceptual diagram for the application tier of proposed architecture.

The ATP of a symptom (excessive pedal travel) in automotive braking system is illustrated as a case to depict the architecture of feature-intensive ontology modeling and deduction. The typical structure of automotive braking system is shown in Figure 11. First of all, the present data, for example system structure and information of features retrieved from the KPM and the several standards (as mentioned in Section 3). The kernel portions, including notions, message attributes, and group attributes, are constructed and gathered in the ontological model as the truths for inferring. Next, the ontologies of automotive troubleshooting are formulated in the filed tier. Eventually, criteria are created on the basis of the available knowledge and relevant DMs are generated for conducting the feature information of system. According to the proposed architecture, there are several restricted criteria and inference criteria triggered by reasoning feasibility of troubleshooting while inspecting this trouble. Based on the standards, the allowable gap range is 3–6 mm (pedal freeplay). Thus, when checking the variables in the inspection stage, if the result does not meet, then it will judge that the value is unqualified. The criterion is represented below:

$$\begin{array}{c}\mathrm{pedal}\_\mathrm{freeplay}(?\mathrm{u})\wedge \mathrm{gap}(?\mathrm{u},?\mathrm{v})\wedge \mathrm{swrlb}:\hfill \\ :\mathrm{greaterThan}(?\mathrm{v},6)\vee \mathrm{lessThan}(?\mathrm{v},3)\wedge \mathrm{ruler}(?\mathrm{w})\hfill \\ \multicolumn{1}{c}{\wedge \mathrm{measured}\_\mathrm{by}(?\mathrm{u},?\mathrm{w})\to }\\ \mathrm{has}\_\mathrm{irrationnality}(?\mathrm{u},"\mathrm{the}\mathrm{distance}\mathrm{of}\mathrm{pedal}\hfill \\ \multicolumn{1}{c}{{\mathrm{freeplay}\mathrm{is}\mathrm{incorrect}}^{"}}\end{array}$$

(2)

Figure 11.

Typical automotive braking system.^5,63

A prototype platform is generated and illustrated in Figure 12(a). The technician can enter values in the corresponding fields according to the measured results. If the distance of the pedal freeplay, for example, is incorrect, that is, greater than 6 mm, a cross sign and its warning are shown. Similarly, if the inspected distance of pedal height is not within the allowed range (144.1–154.1 mm), then this result will be judged as a failure. The criterion is represented below:

$$\begin{array}{c}\mathrm{pedal}\_\mathrm{height}(?\mathrm{u})\wedge \mathrm{distance}(?\mathrm{u},?\mathrm{v})\wedge \mathrm{swrlb}:\hfill \\ :\mathrm{greaterThan}(?\mathrm{v},154.1)\vee \mathrm{lessThan}(?\mathrm{v},144.1)\hfill \\ \multicolumn{1}{c}{\wedge \mathrm{ruler}(?\mathrm{w})\wedge \mathrm{measured}\_\mathrm{by}(?\mathrm{u},?\mathrm{w})\to }\\ \mathrm{has}\_\mathrm{irrationnality}(?\mathrm{u},"\mathrm{the}\mathrm{distance}\mathrm{of}\mathrm{pedal}\mathrm{height}\hfill \\ \multicolumn{1}{c}{{\mathrm{is}\mathrm{unacceptable}}^{"})}\end{array}$$

(3)

Figure 12.

Screenshot of the ObATS platform – partial items: (a) mechanism portion in inspection phase, (b) hydraulic portion in inspection phase, (c) module portion in diagnosis phase, and (d) controllor in diagnosis phase.

As for the Brake fluid in inspection phase, the results are shown in Figure 12(b). Based on the previous restrictions and criteria, the platform with diagnosis mode is executed automatically to discover the real causes. As illustrated in Figure 12(c), the relevant criteria will be triggered after the technician enters the values. For example, if the lining thickness and uneven wear of pad are not meet the standards, two warnings are revealed in block Message. The criteria are represented respectively as follows:

$$\begin{array}{c}\mathrm{lining}\_\mathrm{thickness}\_\mathrm{of}\_\mathrm{pad}(?\mathrm{u})\wedge \mathrm{length}(?\mathrm{u},?\mathrm{v})\wedge \mathrm{swrlb}:\hfill \\ :\mathrm{lessThan}(?\mathrm{v},3)\wedge \mathrm{vernier}\_\mathrm{caliper}(?\mathrm{w})\hfill \\ \multicolumn{1}{c}{\wedge \mathrm{measured}\_\mathrm{by}(?\mathrm{u},?\mathrm{w})\to }\\ \mathrm{has}\_\mathrm{irrationnality}(?\mathrm{u},"\mathrm{replace}\mathrm{the}\mathrm{used}\mathrm{lining}\mathrm{of}\hfill \\ \multicolumn{1}{c}{{\mathrm{pad}\mathrm{with}\mathrm{new}\mathrm{one}}^{"})}\end{array}$$

(4)

$$\begin{array}{c}\mathrm{uneven}\_\mathrm{wear}\_\mathrm{of}\_\mathrm{pad}(?\mathrm{u})\wedge \mathrm{length}(?\mathrm{u},?\mathrm{v})\wedge \mathrm{swrlb}:\hfill \\ :\mathrm{greaterThan}(?\mathrm{v},1)\wedge \mathrm{dial}\_\mathrm{gauge}(?\mathrm{w})\wedge \mathrm{measured}\_\hfill \\ \multicolumn{1}{c}{\mathrm{by}(?\mathrm{u},?\mathrm{w})\to \mathrm{has}\_\mathrm{irrationnality}}\\ (?\mathrm{u},"\mathrm{replace}\mathrm{the}\mathrm{used}\mathrm{pad}\mathrm{with}{\mathrm{new}\mathrm{one}}^{"})\hfill \end{array}$$

(5)

In addition, the controller is also be diagnosed and its results are revealed in Figure 12(d). The feature information of system is converted into messages that is relevant to deduction of ATP, involving feature types, restrictions, structures and/or position of components through DM-intensive inferring. Besides, the general criteria are shown in Table 5, partial particular criteria used in this instance are depicted in Table 6.

Meanwhile, there is one deduction criterion triggered. There are two lining thicknesses of pad diagnosed, one of them is conflicted with criterion (4); thus, only one has to be replaced by disassembling. The criterion represents the SWRL form of the reasoning criterion.

$$\begin{array}{c}\mathrm{lining}\_\mathrm{thickness}\_\mathrm{of}\_\mathrm{pad}(?\mathrm{u})\wedge \mathrm{length}(?\mathrm{u},?\mathrm{v})\wedge \mathrm{swrlb}:\hfill \\ :\mathrm{lessThan}(?\mathrm{v},3)\wedge \mathrm{disassembling}(?\mathrm{w})\hfill \\ \multicolumn{1}{c}{\to \mathrm{replaced}\_\mathrm{by}(?\mathrm{u},?\mathrm{w})}\end{array}$$

(6)

On the basis of the present data, criteria and deducing modules, the inferring engine, Jena, is applied to reason the relations of implied sequence among problem-solving manipulations. The deduced solution based on the above criteria is shown in Figure 13. There are three corresponding messages (step, tool and additional note) listed. Criteria (7) and (8) are deduced to get the partial suggested solution regarding tool usage. The former means that if the diameter of wheel nuts equal 19 mm and the torque is 98 n-m, then an air impact wrench is suitable tool to disassemble nuts. The latter depicts that if the diameter of bolts equal 14 mm, then a six point socket is appropriate tool to disassemble bolt.

$$\begin{array}{c}\mathrm{wheel}\_\mathrm{nut}(?\mathrm{u})\wedge \mathrm{diameter}(?\mathrm{u},?\mathrm{v})\wedge \mathrm{swrlb}:\hfill \\ :\mathrm{Equal}(?\mathrm{v},19)\wedge \mathrm{torque}(?\mathrm{u},?\mathrm{w})\wedge \mathrm{swrlb}:\hfill \\ \multicolumn{1}{c}{\mathrm{Equal}(?\mathrm{w},98)\wedge \mathrm{air}\_\mathrm{impact}\_\mathrm{wrench}(?\mathrm{x})\to }\\ \mathrm{disassembled}\_\mathrm{by}(?\mathrm{u},?\mathrm{x})\hfill \end{array}$$

(7)

$$\begin{array}{c}\mathrm{bolt}(?\mathrm{u})\wedge \mathrm{diameter}(?\mathrm{u},?\mathrm{v})\wedge \mathrm{swrlb}:\hfill \\ :\mathrm{Equal}(?\mathrm{v},14)\wedge \mathrm{six}\_\mathrm{point}\_\mathrm{socket}(?\mathrm{w})\hfill \\ \multicolumn{1}{c}{\to \mathrm{disassembled}\_\mathrm{by}(?\mathrm{u},?\mathrm{w})}\end{array}$$

(8)

Figure 13.

Snapshot of suggested solution for problem-solving.

Conclusion and future issue

In the recent decade, many studies are presented to explore the automotive troubleshooting process by using technology of knowledge engineering. However, most of them aim at creating knowledge approach to depict the information on partial process. It is necessary to overcome the barrier by integrating the multi-domain knowledge of automotive troubleshooting.

An architecture of feature-intensive ontology modeling and deduction is presented for automotive troubleshooting planning in this research. It consists of an ontology model for troubleshooting manipulation and a deducing module for the reasoning of troubleshooting procession according to the constructed criteria and DMs. Because of the characteristics of ontology, the proposed model is extremely extendible and adjustable. There are several key notions and relations in the field of task modeling and troubleshooting planning, for example structure and procedure, represented in this architecture. In addition, this proposed model also involves the related messages, such as position of component, entity feature, etc., which promotes the feasibility for feature representation.

Meanwhile, a deduction mechanism of ontology is presented through SWRL which serves as a language of criterion depiction. It is very useful to definite the implicit knowledge. The DMs are also involved in this module to improve the applicability in the information of entity features. Therefore, the implied relations within the information of features can be deduced from the messages of ontology to assist decision-making automatically in ATP. An instantiation is offered to execute the approaches presented in this architecture in the ATP of an automotive braking system. Furthermore, the architecture eliminates some existing obstructions in inherent models by involving feature messages.

Nevertheless, the proposed study merely focuses on exploring basic problem based on restrictions of automotive troubleshooting, and criteria base with SWRL format is suitable for fundamental troubles. More effective approaches will be investigated to deal with the complexity in the future research.