Case-Based Reasoning and Rule-Based Reasoning for Railway

Incidents Prevention
Yanping Cui, Zhenmin Tang2,Haibing Dai
2

School of Traffic and Transport, Beijing Jiaotong Udversity, Beijing 100044,China

School of Electrical Engineering, Beijing Jiaotong University, Beijing 100044, China

School of Computer Science, Inner Mongolia University, Inner Mongolia 010200, China
cuiyanp@sina.C0m.cn, 2zmtang@center.njtu.edu.cn,3csdhb@imu.edu.cn

Absfract- This paper presents a knowledge-based approach

for preventing railway operation incidents, which helps railway
operation professionals explore opportunities for dispatch
quality improvement The approach consists of two processors:
incident analysis and dispatch advisory. Given a specific
operation incident description, the proposed approach enables
the identification of underlying problems in the incident and
the suggestion of appropriate dispatch strategies that can be
implemented to prevent repetitions of similar incidents,
Case-Based Reasoning (CBR) and Rule-Based Reasoning
(RBR) are applied to generate dispatch strategies by adapting
ones applied to previous incidents and/or using generalised
rule-based knowledge for dispatch.
Keywords: case-based reasoning; rule-based reasoning;
railway incidents preveation

I. INTRODUCTION
For the railway service system, safety is the most
important factor of all. With the development of science and
technology, all kinds of advanced equipments have been
used to promote safety conditions. This has brought two
changes: on the one hand, the accidents caused by
equipments has decreased greatly; on the other hand,
dispatch difficulty caused by the the technique progress and
train density has increased. Subsequently, many goods loss
and train delay are caused by human error.
The effective mhagement of adverse incidents is a major
issue. Many lessons can be learnt from investigating adverse
incidents and taking actions to avoid a repetition. Given a
particuIar incident, it is important to find appropriate
strategies that can be implemented for decreasing the
occurrence of similar incidents. To do this, incidents need to
be analysed. It is required to understand what incidents result
from and identify factors that contribute to such incidents.
The pathways and contributing factors can then be viewed as
suggested strategies to be implemented to prevent repetitions
of incidents, for example, recommendations for regulation or
deregulation of dispatcher where appropriate; strategies to
improve communications between operation professionals.
This paper introduces a knowledge-based approach for
preventing railway operation incidents. A variety of
knowledge is applied in the approach. The ontological
knowledge is used for incident analysis. Specific incident
cases and rule-based dispatch knowledge are applied for
dispatch advisoq based on Case-Based Reasoning (CBR)
and Rule-Based Reasoning (RBR). An intelligent system has

been developed based on the approach, which assists

operation professionals in analysing incidents and
determining relevant measures to prevent the occurrence of
such incidents. The system allows dispatchers and other
operation professionals to complete structured incident
reports about any event, which has caused loss and can cause
potential loss. When a new incident is reported, a set of
remedy strategies are recommended, which can be
implemented to reduce the chances of similar problems
occurring. In our context, operation incident can be broadly
defined as an unintended event, no matter how seemingly
trivial or commonplace, which could have caused loss during
the train moving. This criterion includes near miss where
the loss may have been averted, but the potentid for loss
exists.
11. DESIGN OF PREVENTION STRATEGIES
Designing prevention strategies is concerned with
analysis of the given incident and given an incident
description reported by operation professionals, the
proposed design approach identifies sources of underlying
problems and suggests measures for solving these problems.
These measures can be viewed as strategies that can be
implemented with high potential for decreasing the
occurrence of similar incidents. Furthermore, Rule-Based
Reasoning (RBR), and ontological knowledge base are
applied in the design of prevention strategies. Figure 1 gives
major components of the proposed approach. Two
processors, incident analysis and prevention measures are
core components. The arrows with a single line represent a
process flow while mows witb double lines represent
datalinformation ___
flow..

An incident
deaulption

Firr.1 the components of systems

h e design approach takes an inciaent description as inpur.

First, The processor of incident analysis examines it and
identifies sources of underlying problems involved by

- 1057 0-7803-897 1-9/05/$20.00

02005 IEEE

..

applying ontological knowledge about operation incidents.

An analysis tree is derived, which contains details of what
happened and how they happened in the given incident. The
processor of prevention advisory then recommends
appropriate prevention strategies based on information in the
analysis tree. In doing this, specific incident cases and
generalised rule-based knowledge about dispatch are used
based on case-based reasoning and rule-based reasoning.
Three types of knowledge are applied in the proposed
approach. The ontological knowledge is used for incident
analysis. It provides guidelines for analysing incidents in
order to identify types, features and possible causes of
underlying problems. The incident case base contains a
number of specific operation incidents, which provides
contextual information about problems and situations in
incidents. Each incident case consists of an incident profile,
analysis information about underlying problems and relevant
suggestions that can be used to avoid a repetition. The
rule-based knowledge for prevention is used to generate
resolvents if no matched incident case is available.
Some effort has been made in risk incident monitoring and
disposing in railway domain. Our work differs from the
above studies in that it provides detailed contextual
information about specific processes and situations that can
lead to adverse outcomes. Such information is then used to
make specific recommendations for improvement. The
incidents are managed in terms of identifying sources of
problems and offering suggestions.
The next two sections respectively describes two
processors; incident anaIysis and prevention advisory in
terms of relevant process and knowledge components.

HI. INCIDENT ANALYSIS

When an incident is reported, an incident profile is
completed. The incident profile includes the incident's
information, incident outcomes and a general description of
the incident. The processor of incident analysis investigates
the information of the given incident profile to identify types
of problems involved in the incident, relevant features and
possible causes. This is done based upon ontological
knowledge using structured fixed - choice responses. The
processor provides a set of choices in levels of Problem Type
(F'T), Problem Feature (PF) and Possible Causes (PC)
according to the ontological knowledge for incidents. The
user responses by selecting one or more from the choices.
As a result, an analysis tree is derived for the given incident.
It captures analysis information in a hierarchy. The analysis
tree represents types, features and possible causes of
underlying problems in the given incident.
The processor of incident analysis applies ontological
knowledge about incidents to identify problem types,
features and possible causes. Ontological knowledge
represents domain knowledge for incident analysis. It
provides guidelines for identifying F'roblem Types (F'Ts),
Problem Features (PFs) and Possible Causes (PCs) in the
incident. This knowledge is formulated in a hierarchical and

categorical ontology based on relationships among PTs, PFs

and PCs. A PT is described by a number of PFs. each of that
is further related to a set of PCs.
The Figure 2 gives some of ontological knowledge for
dispatch incidents. The "problem-type" layer shows the type
of problem, eg command problem, judgement problem, etc.
The "problem feature" layer represents the categories of
problem featufes found for a particular problem type. For
example, for command problem, the problem features
include incorrect command etc. The "problem-cause" layer
shows the possible causes found from studies that are linked
to each problem feature. For example, the possible causes for
"incorrect command'' include wrong receiver, receiver's
misunderstanding etc.

/\\......

lr"rect
command

.....

judgement

command

/\\
' \ \

missed
I

delayed

Limitad
Wrong .__.._ Recwiver's
eqerienca
reCBiVel misunderstanding

.1.

"'"'

.'""

Fig.2 The hierarchy of E,PFGd Pc in the generalised%alysi$ rules.

The processor of incident analysis contains three actions:

(1) Identifying types of underlying problems;
(2) for each problem, identifying relevant features related
to the problem;
(3) for each feature, identifying possible causes.
The output of the incident analysis is an analysis tree for
the given incident. The analysis tree contains information
about what problems are involved and why they happen.
Moreover, each branch in the tree provides an underlying
problem and its features and possible causes, which can be
used for the processor of prevention advisory to suggest
appropriate prevention strategies.

IV. PREVENTION ADVISORY

The processor of prevention advisory applies CBR and
rules-based reasoning to generate preventions based on
information represented on the analysis tree. First, it
searches through the incident case base. In the generation of
preventions, CBR and RBR are applied in complementary
manner. It allows specific incident cases to be used directly
when relevant and the generalised advisory process, incident
cases rules to be used when no matched case is available. So,
two types of knowledge are applied in the prevention
knowledge for preventions.
A. Representation of incident cases
A case in the system represents information related to a
specific operation incident. An operation incident can be
defined as an unexpected event, which has caused loss or can
have potential bad effect to train operation. An operation
incident involves one or more underlying problems (eg.,
human errors and preventable system problems), each of that

- 1058-

IF PT(i) and PFQ) and PC (k) THEN a set of relevant

preventions.
If a matched subcase can be found based on problem type,
features and possible causes, the preventions in this subcase
are adapted as preventions to the problem. In the current
system, the adaptation process is simply taking previous
preventions as ones for the new problem. This is because we
only consider exact matching between subcases and the new
problem description. If no relevant subcase is available, the
generalised prevention rules are applied to generate
preventions using RBR.
The algorithm for prevention advisory includes
For each branch in the analysis tree
Retrieving subcases using information of the branch;
If a subcase is available
Then adapting its preventions;
Else applying generalised rules to generate preventions;
Combining preventions generated for each problem.

implies sources of potential loss. An underlying problem can

be represented by a number of features that can be further
related to some possible causes. In the system, an incident
case consists of a number of subcases. Each subcase
represents information to an underlying problem and
relevant preventions to it.
An incident case in the system contains
an incident profile;
analysis information of underlying problems,
which describes what happened and why they
happened; and
measures which can be implemented to solve
each problem in the incident.

Incident Profile
Incidents time:
Incidents Place:
Incidents Category:
Incident description:

Once a set of prevention strategies is generated for the

given incident profile, the process updates the incident case
base by adding a new incident case that consists of the input
incident profile, information from the analysis tree and
suggested prevention strategies.
Analysis information of
underlvinp;problems
Problem Type:
Problem Features:
Possible Causes:

Preventions:
(1)
(2)

...

Figure 3 shows the representation of an incident case,

which consists of subcase 1.1, subcase 1.2 etc. The incident
profile provides (1) the incidents information (eg., time,
place, reiatvie professionals, etc.) (2) outcomes of incident
in terms of immediate consequence and potential loss, and
(3) a contextual description of the incident. Each subcase
provides analysis information and appropriate preventions
for an underlying problem. The analysis information of
underlying problems is represented by a number of
parameters: type of the problems; features of problems;
and possible causes to the problems. This information
describes details of what happened and why they happened.
Associated with each underlying problem, a set of relevant
preventions is represented in the subcase. For example, a
judgement problem in the subcase 1.2 is featured by
missed or delayed etc. It occurred due to possible causes
such as the operators limited experience and doze on duty
etc.

B. Rule-bused knowledge for preventions

The rule-based knowledge about preventions is used to
generate relevant preventions when no relevant case is
available and CBR is not appropriate. Given a FT,a PF and a
PC,a particular type of prevention can be derived. The form
of prevention rules is

V. CONCLUSIONS
A knowledge-based approach for incident prevention
strategies was described. The approach consists of two major
processors: incident analysis and prevention advisory. Given
a specific incident description, the proposed approach
investigates it by identifying what underlying. problems
happened and why they happened in the incident based on
ontological knowledge on incidents. Such analysis
information is then used as a basis for designing appropriate
preventions. The prevention advisory process is based on
adapting ones applied to previous incidents and/or using
generalised rule-based knowledge.
This paper has presented an approach for incident
prevention and some relevant issues for application of CBR
and RBR. Our further considerations include an automatic
process of incident analysis, retrieval of relevant incident
cases according to a flexible attribute order, and linking
prevention measures with relevant on-line sources. First, the
current incident analysis is conducted based on interaction
between the system and users through fix-choice responses.
This can be improved by an automatic analysis process.
When an incident is reported, the contextual description of
the incident can be captured in a well-structured format. The
proposed approach can then analyses the contents of the
incident description to identify types, features and possible
causes of underlying problems. Second, in the retrieval of
incident cases, a fixed attribute order is currently used to
specify the importance order for attributes used in the query.
To provide previous incidents that are more relevant to
users query, it is important to allow users to specify the
importance order for attributes used in the query. Third, the

1059 -

suggested preventions in the current approach only provide

strategies that can be implemented to avoid the occurrence of
similar incidents. It will be useful to provide some references
and guidelines associated with the suggested preventions.
These reference and guidelines can be directly from on-line
sources. Additionally, in order for users to have a better
understanding of the prevention measures, it is essential to
offer some scenarioslexamples when preventions are
recommended.

REFERENCES
Edited by David B.Leake. Case-Based Reasoning --- Experiences,
Lessons, Future Directions[M]. AAA1 Press MIT Press. 1996.
121 Riesbeck C K, Schank R C. Inside Case-Based Reasoing[M].
Hillsdale, New Jersey Lawrence Erlhaum Associates Inc, 1989, 1I.
[31 Watson, I. & Marir, F., Case Based Reasoning: A

[I]

Review[J]. The Knowledge Engineering Review, Vol. 9:4,

1994, pp. 327-354.

[4] Marir. F. & Watson, 1.. Case Based Reasoning : A Categorised

3ibliography[J]. The Knowledge Engineering Vo1.9:4. 1994,
pp.33.5-381,
[5] Johnson, C. The Epistemics of Accidents[M]. Int. J.
Human-Computer Studies, 47,659-688. 1997.
161 DU Xiao-ming, YU Yong-li, HU Hui. Case-based reasoning for
multi-attribute evaluation[J]. Systems Engineering and Electronics,
1999.21(9): 45-48.
[7] Watson I, Marrir F. Case-based reasoning: a review[J]. The
Knowledge Engineering Review, 1994,9(4):335-381.
[SI YANG Shu-zi. Diagnosis reasoning based on knowledge[M]. Peking:
Tsinghua University Press, 1993.(in Chinese)
[9] Rissland E I., Skalak D B. Combing Case-based and Rule-hased
Reasoning: A Heuristic Approach(J1. I n hoc. Of IJCAI-89, Detroit.
1989.
[lo] Dutta S. Integrating Case-based and Rule-based Reasoning: The
Possibilistic Connection[J]. I n Proceedings of the Six Conference on
Uncertainty in Artificial Intelligence, 1990-07.
[ I I ] Knton P. Reasoning About Evidence in Causal Explanations[J]. In
Proc. Of AAAI-88,1988.
[12] Barletta R, Mark W. Explanation-based Indexing of Cases[J]. In
Proceedings of the CBR Workshop. Clearwater Beach, 1998.

- 1060-