Knowledge Base Development for Maritime Regulations

8/14/2019 Knowledge Base Development for Maritime Regulations

1/11


2/11

Technology Board of Singapore, Singapore Polytechnic and DNV. This paper

describes some of the preliminary work done to establish the KBS framework and the

associated risks and risk-management plans for the development .

2. A KBS for Design Approval of SOLAS Elements in Oil Tankers

For this pilot project the scope of KBS development is restricted to SOLAS

Regulations relating to tankers. The KBS would be providing performance support at

task level for the DNV's approval engineers. The knowledge-base developed would

include the following:

a) computer-based information with access to reference information and case historydatabases wherever relevant,

b) learning experiences with access to realistic scenarios,

c) guidance/ support for decision making processes,

d) user-friendly interfaces providing proactive and reactive support to assist users in

completing their approval tasks.

The project takes a two pronged approach for the KBS structure.

Task segmentation to Regulation level. All approval tasks would be broken down

to compliance of related SOLAS regulations. This is illustrated in Fig.1.


3/11

SOLAS related approval task for an oil-tanker

Subtask 1

Subtask 2 (Example: Structural Fire Protection)

Regulation 1

Regulation 23

Regulation 57

"

"

Regulation N

Subtask 3 (Example: Means of Escape from different

compartments)

Subtask N

Additionally, approval tasks could also be processed using a rule-base. This rule-

base is to be based on past approval experience. The rule-base would be called the

STANDARD RULE-BASE. A dynamic component to the rule-base would also be

available, which would capture the new problems and their approval processes as

encountered over time. This would be called the DEVELOPING RULE-BASE.

The components of the DEVELOPING RULE-BASE would be transferred

manually to the STANDARD RULE-BASE from time to time after vetting.

Figure 1. Task segmentation


4/11

The overall structure of the KBS at three levels is shown in Fig.2 below. Approval

work is initiated at the top level by choosing one of the tasks (task details are given in

the legend to Fig.2).

LEGEND

(Details of tasks at the top level)

LSA Life saving appliances TA/GDZ Tank Arrangement/Gas

dangerous zones

RC Radio communication VN/GFR Ventilation/ Gas freeing

FD/A Fire detection and alarm GTS Gas tight seals

FE Fire extinction SATB Safe access to tanker bow

ME Means of escape SFP Structural fire protection

LS Location of spaces SP Safety plan

ETA Emergency towing arrangement IGS Inert gas systems

KBS TOP

LEVEL

Task

Selection

Figure 2. KBS Structure at three levels


5/11

Once a particular task is selected, the related SOLAS regulations are identified

at the 2nd

level. At the 3rd

level of KBS, the user can access the following for each

regulation:

Regulation details - these represent the surface level information and are called

declarative knowledge. Declarative knowledge equates to "knowing that". This is

book-based knowledge [SOLAS regulations] and it may not be directly related to

the experts' cognitive foundations and concepts that they use to relate the

information in a meaningful fashion for approval processing.

IMO/IACS interpretations - these may represent semantic knowledge, providing

inter-relationships which could help in identifying decision making procedures.

Alternatively, they could also be declarative.

Standard rule-base - these would form a rule base, attempting to capture the

established procedures, which is already standardised in DNV's approval centres.

These would most likely be procedural knowledge identifying routine procedures

or tasks undertaken during approval processing.

Developing rule-base -- these would form the dynamic component of the KBS,

attempting to capture the new knowledge as it evolves while the approval

engineers tackle and solve new problems during their day-to-day work. The

approval engineers would be encouraged to enter the rationale for their decisions

and relate the premises to the actions opted for. This developing knowledge-base

would have to be vetted from time-to-time and the items found justified would be

included in the standard rule-base. The KBS structure would be planned to allow

for sharing of this developing knowledge-base among the approval engineers even

before the vetting takes place. This could provide the following:

a conducive environment for capturing new experience,

a platform for cognitive interaction between approval engineers and

an opportunity to critique the new knowledge during the development

stage.


6/11

This will make the new knowledge more robust by the time it is put up for vetting.

Knowledge type for developing rule-base could be procedural, semantic or

episodic.

Examples-- provides past cases with diagrams, calculations and necessary support

material. Examples would form the episodic information, relating past events and

associating them with relevant aspects of the regulations.

3. KBS DEVELOPMENT STRATEGY

3.1 COMPARISON OF STRUCTURED DEVELOPMENT LIFE CYCLEPROCEDURES AGAINST PROTOTYPING APPROACH AND

ASSOCIATED RISKS

The KBS project is being developed using a prototyping approach. In this

section we relate the differences between traditional software engineering

development strategies against prototyping and how we are planning to handle risks

during the development stage. Major risks are envisaged during planning, knowledge

acquisition and failing to exercise the re-use strategy.

Traditional methodology of developing of information systems is to use a

linear structured development lifecycle (SDLC) as illustrated below.

The fundamental assumption for the above lifecycle depends on the

assumption that the system requirements are well defined and in the short term they

are considered to be static. Based on these assumptions project milestones are planned

ProblemDefinition(withoutambiguity)

Analysis ofWell-definedproblem

Design Implementation

Figure 3. Linear structured development lifecycle


7/11

and intermediate project deliverables are produced. The deliverables are then verified

and evaluated for meeting the objectives as stated in the clearly definedrequirement

specification. Thus, these deliverables, delivered after completion of various

intermediate stages, provide the necessary control and the management of the overall

risk in the system development.

In KBS development, the requirements are not well defined. In such cases, a

linear development methodology is not suitable. Instead a prototyping approach is

normally undertaken. In a prototyping development process the system evolves

through multiple stages of interaction between the KBS builder and the domain

experts. This is shown in the following diagram.

3.2 KNOWLEDGE ACQUISITION FOR CAPTURING DIFFERENT

KNOWLEDGE ATTRIBUTES.

It is acknowledged that knowledge acquisition is the primary bottleneck for

KBS development. Hence, techniques used for knowledge acquisition become

important criteria for a successful KBS development. We are planning different

techniques for capturing the various attributes of the knowledge. A description of our

plan is given in Table 1.

Ill defined

problem

Prototyping1 2 3 4

X X X

Reached

desired level of

convergence

Prototyping: CONCEPTUALIZE FORMALIZE IMPLEMENT TEST

Conceptualize: KNOWLEDGE EXTRACTION

KNOWLEDGE REPRESENTATION

: NOT REACHED THE DESIRED LEVEL OF CONVERGENCEX

Figure 4. Iterative development process during prototyping


8/11

Knowledge

attribute

Declarative Procedural Semantic Episodic

Scope of

knowledge

segment

SOLAS

Regulations

(considered as

surface level

information)

Heuristic task

sequences and

procedures

undertaken by

approval

engineers

Concept based

decisions in

approval

processes.

(Interpretations

based on

relationships

between

concepts)

Experiential

information

that has been

grouped or

chunked by

episodes.

(Case-based

decisions.)

Intended

technique

1) Capture

directly

from public

domain

information

2) Interviews

1) Structured

interviews

2) Process

tracing

3) Simulations

1) Task

analysis

2) Process

tracing

1) Could be

obtained

from past

records.

2) Process

tracing

3.3 RE-USE OF COMPONENTS DURING KBS BUILDING

It is recognised that one of the main reasons for lack of dominance of KBS

technology in information system development is lack of re-use during KBS building.

To promote re-use as an integral process of our KBS development we have chosen a

development platform of Microsoft Visual Basic (VB5) and Visual Rule Studio

(VRS) of Rule Machines Corporation. Instead of using proprietary expert system

development environment, this VB5+VRS platform provides an open architecture and

lends itself to package rules into components reusable objects called RuleSets. By

fully utilizing OLE and COM technologies, RuleSets act as COM Automation

Servers, exposing RuleSet objects to any COM compatible client. RuleSets are

presented not by static, cumbersome API, but are exposed as COM automation

Table 1. Knowledge acquisition matrix


9/11

objects derived from the objects created within each individual RuleSet. Thus, each

RuleSet exposes a unique object signature, which directly models the object

behaviour of the specific RuleSet. Implication of this platform is the emphasis on

reuse, e.g. re-use of SOLAS RuleSets for the tanker KBS being used for other types of

vessels or re-use of the RuleSets for developing teaching software.

3.4 RISKS AT THE KNOWLEDGE REPRESENTATION STAGES

Knowledge extracted during elicitation stage is to be eventually represented

into a meaningful knowledge structure. This is also seen as an area of considerable

risk. The risks and risk reduction strategy is shown in the following table.

RISKS INCURRED

BY

RISK REDUCTION

Wrong formalisation

to store elicited

knowledge

Knowledge

engineer

To be identified during testing of

prototypes. Could be minimised

by better interaction between

knowledge builder and domain

experts.

Right formalisation of

knowledge, but not

flexible enough to

accommodate future

structural changes in

knowledge

System

design

engineers

To be identified during planning

of prototype. Could be

minimised by better interaction

between knowledge engineer and

system design engineers.

Right formalisation of

knowledge, but not

generic enough for

reuse.

System

design

engineers

To be identified during planning

of prototype. Could be

minimised by better interaction

between knowledge engineer and

system design engineers.

Table 2. Risk management during knowledge representation


10/11

Additionally, the effectiveness with which the KBS meets the needs of the

users will also be important criterion for assessment during prototyping.

3.5 REDUCING RISK DURING PROTOTYPE TESTING PHASE

In KBS development, the degree of convergence or divergence between the

decisions made by an expert and while using the KBS should be carefully assessed

during testing phases and the consequences evaluated as illustrated below. The

process will identify the degree to which system captures the knowledge.

4 CONCLUSION

Use of KBS technology in the maritime regulatory domain is seen as a

possible trend to manage information influx, which is becoming increasingly complex

and voluminous. Success of this trend would depend on how appropriately we apply

this new technology to this regulatory domain and manage the associated risks. The

pilot project described in this paper is an experiment in this direction. Experience

gained from this pilot study could be used to develop a full scale maritime regulatory

domain KBS or expert systems in other areas, e.g. heuristic fault-finding of machinery

systems or ISM code management etc.

Decision

made usingKBS

Decision

made byExpert

CONVERGENCE/ DIVERGENCE

How far apart?

Risks andconsequences to

assess

Figure 5. Risk assessment during prototype testing


11/11

5. REFERENCES

Agrawal, R and M. Tanniru, (1990). Organizational Management of Expert System

Development, In: Balagurusamy, E. and J. Howe (eds),Expert Systems for

Management and Engineering, Ellis Horwood, Chichester. 21-35.

Chatterjea, K. and T. A. Piyasiri, (1996). Capturing Expertise in Marine Regulations

on a Knowledge-based System, Proc. MARTECH '96 International Conference,

Singapore Polytechnic.

DNV Rules for Classification of Ships, Vol.1 & Vol. 2.

Durkin, J., (1994).Expert Systems - Design and Development, Macmillan, New

Jersey.

IMO,International Convention for Safety of Life at Sea (1974), SOLAS Consolidated

text (1997).

IMO, SOLAS 1996 Amendments, Effective July 1998.

McGraw, K. L. and K. Harbison-Briggs., (1989). Knowledge Acquisition: Principles

and Guidelines, Prentice Hall, New Jersey.

Documents

Knowledge Base Development for Maritime Regulations