Chapter 7 Applications
7.2 Application: the enterprise problem diagnosis and solution retrieval
To obtain the high reliability and availability of the information system in the enterprise environment, the multi-domain architecture has been applied to system design extensively to enhance performance, flexibility and scalability of the information system [29][81]. However, it increases both the complexity of the system and the difficulty of problem diagnosis. Moreover, once the complex information system goes wrong, domain experts usually get together to look for solutions to fix the problem as soon as possible. In the enterprise environment, the expert finding and problem diagnosis of complex system is mission critical.
The typical customer relationship management system (CRM system) shown in Figure 7.3, a typical multi-domain system for daily operation, connects several component applications to provide services of billing management system, human resource management and network maintenance system. To ensure the CRM system works well in daily operation, experts in different domain (e.g., DBAs, system maintainers, system administrators and developers etc.) should participate in maintaining the system. Therefore, how to utilize domain knowledge and the profiles of experts during problem diagnosis processes to find the right persons to fix the problem of the complex system (multi-domain) has become an important issue.
Figure 7.3 System architecture of CRM system.
As we have known, case-based reasoning (CBR) [13] is an approach that solves new problems by retrieving existing successful solutions of similar problems from a knowledge source of cases, the so-called “case-base”. CBR has been broadly applied in various areas such as problem diagnosis, solution retrieval, help desk, assessment, decision support, design, and planning [12][72]. However, the process of case-based reasoning is very time-consuming and the result might not be accurate when the case base is likely a large coarse-grained case base. Searching through the whole “case base” for a solution in a sequential way is rather inefficient. Moreover, it is important to recommend an appropriate expert to solve the problem based on her/his domain knowledge, technical skill, experiences, and so on. Since role-based access control model can be used to solve such requirements of problem diagnosis and solution retrieval, we combine it with a hybrid case-based reasoning approach, the rule-based case-base reasoning (RCBR) methodology, to apply to the high-level knowledge for problem diagnosis and the concrete-level knowledge for solution retrieval. The high-level knowledge which is extracted by rule-based reasoning (RBR) can locate the problem in a specific category, and the concrete-level knowledge can
87
retrieve solution from the specific case base with case-based reasoning (CBR).
Similar to the concept of object-oriented programming, we could treat all the entities in the real world as concepts and it is natural for us to model the world using concepts hierarchy. In knowledge acquisition phase, knowledge engineers acquire error type ontology with domain experts. The ontology is divided into two layers, the abstract layer ontology describes abstract categories of error types, and the concrete layer ontology describes error spaces of the specific domain. In Fig. 5, knowledge ontology of error spaces is excerpted from the oracle database that is designed by cooperation of the domain experts and knowledge engineers. The knowledge classes that include oval and rectangularity represent the concepts from domain experts. As shown in Figure 7.4, the knowledge class “oracle DB”, consists of two KCs (knowledge classes), “instance” and “database”, and the rectangle stands for knowledge class of the error type of cases. Two types of relationships are used in error type ontology to describe relationships of problems. The first one is the “trigger”
relationship between concepts. Some rule class is triggered when some specific conditions are satisfied. It means that a problem may be transformed into another problem. For example, “system error” can transform to “databases error” when the root cause of error is identified in DB layer. The second one is “acquire” relationship, which could be used to describe the sub-problem may be solved by acquiring another rule class. For example, a “control file error” may acquire the expertise of “DB diagnosis”.
Figure 7.4 The error type ontology of oracle database
With the defined error type ontology, the Rule-based Error Type Inferring for Problem Diagnosis and the Case-based Reasoning for Solution Retrieval are proposed as followings.
1) Rule-based Error Type Inferring for Problem Diagnosis
Figure 7.5 The behavior of pondering over known information in Rule-Base
As shown in Figure 7.5, when facts are collected through sensors or other input sources, the facts will be inferred from a specific concept in a domain and other three
89
concepts can be associated according to their relationships. Nevertheless, people may not consider all relevant knowledge at the same time since too much effort is required to solve the problem. Some inference skills are widely used in human thoughts to improve the performance of knowledge inference. The inference process for problem diagnosis is described as follows. The first step is to select a rule-base from multiple rule-bases. Because a knowledge system cannot contain all types of domain knowledge, it is necessary to specify a knowledge domain before inference. The second step is to collect the facts and specify a knowledge class (KC) containing the corresponding control knowledge for the problem to be solved. According to the specified KC, the inference engine will perform the reasoning process. Finally, interesting and useful information can be obtained from final fact value. Furthermore, the order of fired rules is decided by CF values, and the lower priority rules have weak CF values. After the inference processes, the error type of the problem can be identified.
2) Case-based Reasoning for Solution Retrieval
After the error type of the problem is diagnosed, we retrieve the solution from corresponding case base with Case-Based Reasoning approach. Case-Based Reasoning (CBR) is an approach that solves a new problem by recalling a previous similar situation and reusing information and knowledge of that situation. A process model of the CBR cycle may be described by the four processes: RETRIEVE the most similar case, REUSE the information and knowledge in that case to solve the problem, REVISE the proposed solution, and RETAIN the parts of this experience which it‟s likely to be useful for future problem solving.
Example 6.1
In the case bases, the original solution documents of error instances obtained from the experts and technical forums are retained as the attribute-based solution cases with attributes error type, subject, module, version, platform, publisher, date, and solution statement as described in Table 7.4. It is the example case of “Redo Log Error”, and the case is represented as case vector by Local Solution Case Feature of error type “Redo Log Error”.
Table 7.4 Example case of Dropping Redo Log Not Possible
Attributes Description
Error Type Redo Log Error
Subject DROPPING REDO LOGS NOT POSSIBLE
Application File
Version 8.1.7
Platform Solaris
Description Could not drop the redo logs which may be needed for instance recovery.
The online redo logs could not be dropped if:
1.There are only two log groups.
2.The corrupt redo log file belongs to the current group.
Solution The error ORA-1624 will be produced, since an online redo impossible to conduct a complete recovery. Perform a backup immediately after completing this command.
Based upon Local Solution Case Feature of “Redo Log Error”, the solution case can be represented as case vector.
“DROPPING REDO LOGS NOT POSSIBLE“ Vector = {“Redo Log Error”,
“dropping redo log”, “8.1.7”, “solaris”, “online redo log”, “corrupt redo log file”, “ORA-1624”, “status=CURRENT”, “status=ACTIVE”, “logfile”, “alter
91
database clear logfile”, …}
To evaluate the performance of the novel approach, the Solution Retrieval System (SRS) is implemented based on RCBR approach to support problem diagnosis and solution retrieval for customer relationship management system of a telecom company as shown in Figure 7.6 and 7.7. We defined six error categories, and extracted about 10800 error inference rules, 360 real cases, and 27 expert profiles in SRS system. The experimental results of SRS system is compared to the KM Center which is original solution retrieval system implemented based upon keyword search approach.
Figure 7.6 SRS User Interface in Query
Figure 7.7 Solution List in SRS
Two experiments have been designed and implemented to evaluate the accuracy and efficiency of both Rule-Based CBR approach and Case-Based Reasoning approach, where five domain experts have participated in our experiments by inputting the query to both systems and then evaluating the results. In Experiment 6.1, we evaluated the accuracy in solutions and expert suggestion between the KC Center and the SRS. In the following experiment, we calculated the efficiency of system in average query times.
To evaluate the retrieval accuracy, 28 error problems have been dispatched to experts randomly for judging the correctness of suggested solutions from both systems, KC Center and SRS, and the evaluated results are shown in Table 7.5. In addition, the SRS system suggested appropriate expert to solve the problem. The experimental results showed that the average accuracy rate of RCBR (82.14%) is better than that of CBR (60.71%) as shown in Figure 7.8.
Table 7.5 Accuracy evaluation between RCBR and CBR
Error Types Average
93
DB Crash Redo Log Archive Log Data File Control File System Monitoring Error Type
Solution Accuracy
KM(CBR) SRS(RCBR)
Figure 7.8 Accuracy evaluation between SRS system and KM center
To evaluate the efficiency, the experiment of average query times in system diagnosis and solution retrieving was done. With predefined 28 questions of six categories, the average query times are listed in Table 7.6, where the query efficiency of SRS system is quicker than that of KC Center and the average query times of RCBR is 2.10, and CBR is 4.93. The diagram of Table 7.6 shown in Figure 7.9 describes the comparison result between SRS and KM Center for system diagnosis and solution retrieval in efficiency aspect.
Table 7.6 Efficiency evaluation between RCBR and CBR
Average Times in Solution Retrieval Average times
0 1 2 3 4 5 6 7
Db Crash Redo Log Archive Log Data File Control File System Monitoring Error Type
Average Query Times
KM(CBR) SRS(RCBR)
Figure 7.9. Efficiency evaluation between SRS system and KM center
According to the experimental results, the paradigm of using RCBR methodology and RBAC model to build SRS system works well and effective. RCBR will benefit the inference on problem diagnosis, and incorporate domain experts into retrieval system with RBAC model by constructing expertise ontology. It is assumed that the same approach could be adaptively modified to other problem domains for knowledge base and user database construction.
95