A Rule-Based Approach to Capture Engineering Knowledge in Ship Design

Ole Christian Astrup, Det Norske Veritas as, ole.christian.astrup@dnv.com

Kjell Tangen, DNV Software, kjell.tangen@dnv.com
Ove Aae, DNV Software, ove.aae@dnv.com
Abstract
This paper describes a framework for capturing and storing knowledge in the form of best
engineering practices. The framework can capture both design rules (in this paper in the form of the
DNV Ship Rule) and generic design processes in form of workflows. Special emphasis has been put on
achieving good performance of the rule executions. Being able to capture and store best practices as
formalised electronic knowledge can provide huge advantages to the shipbuilder and designer
throughout the design process, and from one design to the next. The paper shows how the framework
can be used to optimize the ship weight accounting for rule-based structural constraints.
1. A rule-based approach to capture engineering knowledge
1.1 Design knowledge and design patterns
Brachman (2004) defines knowledge representation or knowledge base as follows: An electronic
knowledge representation is a dynamic, IT-based and machine interpretable representation of an
information base for a known and agreed-upon domain of intercourse that reflects relevant knowledge
about the problem at hand. The information base consists of a collection of symbolic structures
representing the systems beliefs that are used for reasoning during operation.
Three characteristics elements can be identified:

Symbolic or formal structures are used to represent knowledge.

The representation is grounded on conditioned beliefs (rules).
Reasoning is performed by inferring new information from existing information using this
knowledge.

The application of knowledge in an IT system requires explicit knowledge. In engineering, a definite

reproducibility and traceability is required. Heuristic or case-based systems are not applicable, as their
underlying concepts of self-learning and heuristic approaches cannot guarantee an absolute
reproducibility and traceability of the reasoning performed. Therefore, only constraint- and rule-based
systems are suitable for design problems in the domain of engineering, Zimmermann (2010).
Rules alone are not sufficient to capture naval design knowledge. Design rules need to be combined
with procedural structures or Design Patterns. Design patterns are used to define a sequence of design
tasks. A formalized description of a specific part of the design process can be achieved by combining
workflows with rule-based formulations for the definition of such tasks as building blocks. Hence,
workflows can be used to define solution strategies for design tasks with a clearly defined design
objective.
A design task can consist of multiple atomic so-called Design Activities. A design activity is a
transformation of the state of information by means of a design or problem solving method based on
knowledge of the designer or any other acting entity and reflecting the context of the evolving design.
These activities are executed sequentially or in parallel such that an optimal design is achieved. In
other words - with a design activity, a single design objective should be reached such that all relevant
requirements and constraints given are adhered. During the solution process, i.e. within the execution
of an individual design activity, multiple steps are performed. Design activities are therefore of key
importance for any IT based system that concentrates on design support.

227

The design task as performed within the design process in naval architecture is given by a sequence of
individual design activities, Fig.1.

Fig. 1: The naval architect design spiral

The designer usually starts from a candidate solution based on past experience or designs. While not
being a guaranteed valid solution, this solution presents a first approach towards the design problem
given. Here, constraints and requirements given as part of the design context or proposed by other
design activities need to be taken into account. In a following step, this candidate solution is assessed
and the design objective is validated, Fig.1. Also, functional performance as well as the fulfilment of
constraints or requirements is evaluated. If multiple solution concepts are given for a single design
problem, a suitable and valid design is selected from this set in a following operation. Here,
management constraints like cost considerations or ratings representing the performance of the
individual solutions are taken into account.
Since shipyards are not high-volume assembly lines like car manufacturers, it is difficult to find
processes that can be repeated over and over, thousands of times. For every ship design, and for every
variation to an owners specification, there are different scenarios to be considered during design and
construction. However, ship yards and designers have best practices and pre-defined workflows that
can be applied to each design. Being able to capture and store best practices as formalised electronic
knowledge can provide huge advantages to the shipbuilder and designer throughout the design
process, and from one design to the next, Cochran (2007). If a shipyard or designer can easily
customize design software to capture best practices and its decision making process, it will benefit in
five key ways:

Increased ability to capture and embed standard practices (knowledge as an asset)

Increased automation of routine tasks
Improved transparency of decision making processes
Improved design consistency and reduced risks (and costs)
Improved speed of design iterations

1.2 Problem statement

We have looked at the Structure Design activity and how a rule-based design application such as
Nauticus Hull can support a 360-degree solution for design optimization. By a 360-degree solution,
we mean a solution that is able to automate a full evaluation of a parametric design and optimize it

228

iteratively based on design criteria specified by the designer fulfilling the design objective. Reaching
such a high degree of automatic design optimization requires relevant design knowledge to be
automatically applied in the design process in order to gain useful, if not optimal, results. Automatic
design optimization therefore requires software that is able to capture a substantial amount of design
knowledge and apply it automatically in ways that are both effective and efficient. Design knowledge
varies in form, ranging from rules to procedures; some of which may already be formalized, while
others are just informal practices, Zimmermann (2010).
A further complicating factor is the high variability in what constitutes relevant design knowledge.
For highly complex and knowledge intensive design domains, such as ship design, rules are regularly
updated; they come from different sources, and even vary between designers. Also, practices change
over time and vary between designers. Catering for both complexity and variability in the knowledge
driving the design process is no simple challenge. Let us summarize the problem at hand as follows:
Table 1: Problem summary
1
2
3
4
5

Engineering knowledge representation: General purpose software utilizing engineering

or design knowledge
Ability to model both procedures and rules
Continuous improvement of knowledge bases, based on local practices
Efficient execution
Effective tools for reviewing, developing and testing knowledge bases. Target audience:
Expert users

There is no single technology that can be applied to meet the problem posed above. It must be met by
applying different technologies, and we will spend the rest of the paper describing what technologies
were chosen and how they were applied.
2. The DNV Rule Framework
2.1 Rule anatomy
A fundamental component of the DNV Rule Framework is the ability to represent knowledge in the
form of rules and use them to infer results, Buchanan and Shortcliffe (1984). Following the principles
of predicate logic, Brachman and Levesque (2004), a rule is a logical statement that, given a set of
input data, evaluates to true or false. It represents a logical relationship between one logical statement
(the premise) and another logical statement (the consequent). The consequent is true if the premise is
true (but not necessarily vice versa). More specifically, a rule can be expressed as a conditional
statement on the general form
if <premise> then <consequent>
In general, several rules may have the same consequent, so if <premise> is false, <consequent> may
still be true if the premise of another rule having the same consequent is true. While the purpose of
consequents is to provide a means of logical separation, the purpose of allowing many rules to have
the same consequent is logical decomposition. Logical separation means the logic involved in
evaluating a logical statement (the consequent) is separated from, and invisible to, the code making
the evaluation. Logical decomposition means that the logic involved in evaluating a consequent may
be decomposed into logically independent units (individual rules). In many cases, this allows logic to
be decomposed into multiple simple and independent rules instead of one complex rule. Here lies both
the usefulness and limitation of rules; rules must be independent of evaluation sequence and therefore
unsuited for representation of procedural knowledge.
Since both premise and consequent are logical statements, it is possible to build logical structures
where the consequent of one rule is part of the premise of other rules. This is called chaining of rules
and represents a way of providing logical separation and decomposition within a set of rules.
229

A rule may have side effects in the form of actions, which are executable statements that are executed
at certain points during rule evaluation. There are three types of actions:
-

Pre actions: Actions that are executed each time the rule is evaluated, before the premise is
evaluated.
True actions: Actions that are executed when the rule evaluated to true
False actions: Actions that are executed if the rule evaluated to false

In the DNV Rule Framework, consequents have the same structure as a method of a class; the
consequent has a name and a list of typed arguments. Each argument may either be an input or an
output argument, carrying either input data to the rule or output data from the rule. This similarity is
no coincidence, because when rules are executed, the application invokes rules by invoking a class
method corresponding to a particular consequent.
A rulebase is the basic rule management unit, and is just a collection of rules. Rulebases may be
stored on file, either in XML form or in the form of a JavaScript file.
2.2 Rule evaluation
The DNV Rule Framework supports two different modes of rule evaluation:
Forward chaining
Forward chaining means iteratively evaluating each rule in a selected rule set on a particular
data set. A rule is said to fire when its condition is true. When one rule fires, it may invoke
changes to the data set, thereby triggering more rules to fire in the next iteration. Forward
chaining could also be denoted data driven rule evaluation, because what drives the
evaluation is the data set and what changes rules make to it during evaluation.
Backward chaining
Backward chaining, on the other hand, requires the application to make a specific query by
evaluating a particular consequent. This consequent will be defined by one or more rules,
which in turn may be logically chained to other rules. Evaluating a particular consequent
therefore requires subsequent evaluation of rules that are logically chained to it.
The DNV Rule Framework provides means of generating executable code from rules as well as
runtime environments for rule execution. In the context of rule execution, a set of rules, in the form of
one or more rulebases, will be mapped to a class with methods and properties. All methods return a
Boolean value, which is the true outcome of the rule given present data.
Executable code must be generated prior to execution. The way executable code is generated varies
with which runtime environment is chosen. The DNV Rule Framework supports the .NET Common
Language Runtime (CLR) environment with dynamic code generation and execution. This is the
environment that supports dynamic editing and execution of rules. Rules are evaluated with the speed
of compiled code and rules can be tightly integrated with statically compiled code whenever
necessary.
2.3 Rule modelling and testing
We consider rule technology to be a crucial piece in the puzzle, because it can contribute to solve all
the problems listed in Table 1. The final point in this list is related to effective tools for modelling and
testing rules. This tool is an important piece of the DNV Rule Framework that enables expert users to
develop and test rules effectively.
An additional benefit of making the very formulation of rules accessible to domain experts is that it
enables rapid adaption of the design process as new knowledge is acquired.

230

2.4 Task Execution Framework

Task models provide a valuable way of representing procedural knowledge that naturally
complements rules. Together, these representations form a comprehensive framework for expressing
design knowledge:
-

Task model anatomy

Procedural knowledge can be decomposed into units of work, each of which are referred to as a
task. Complex tasks can naturally be decomposed into sub tasks, leading to a decomposition
hierarchy of tasks, a task model. Tasks can be of a generic type, like a sequential task, in which all
sub tasks are executed in sequence, or a fork, in which all sub tasks are run in parallel. A
particular type of task, the rule evaluation task, allows rules to be evaluated, thereby offering a
generic way of integrating rules into the workflow. Tasks may also be application specific. The
expert user is free to compose the task model that fits the problem from a palette of general
purpose and application tasks.
Task execution
The DNV Task Execution framework focuses on tasks that can be executed autonomously
(without user interaction), although tasks involving user interaction may be used. It is primarily a
system for modelling and execution of computational work. A task model is immutable during
execution, i.e. it does not change state during execution. This implies that the same task may
evaluate different data simultaneously. A job is a composition of a task model and a data set
needed for evaluation. The job is an identifiable unit of work that can be submitted to a service for
remote execution.
Task modelling and testing
The DNV Task Execution Framework has extensive support for both task modelling and testing.
It provides a rich graphical modelling and testing environment. More specifically, the test
environment provides the expert user with sophisticated debugging tools that allows him to step
through tasks and rules and inspect data during execution.

3. The DNV Rule Framework applied to ship design

3.1 Introduction
The shipbuilding industry is characterized by complex products, which have to be developed in extremely short time, Krger (2003). Design activities very early in the design phase have the greatest
influence on the final solution and hence offer very large potential savings, Fig.2.

Fig. 2: Comparison between actual costs and cost level fixed by the design for one RoRo ship and all
six sister ships, Krger (2003)

231

As a Classification Society, DNV develops Structural Rules for commercial ships. Design rules
constitute an important component of the ship structural design process, Fig.3. Designers have
become completely reliant on software tools as design rules have become more and more complex.
This has made design rules become more of a black box and less transparent to the designers, Ship
Structure Committee (2007).

Fig. 3: Components of Rule-Based Ship Structural Design, Ship Structure Committee (2007)
The DNV Nauticus Hull software implements the DNV Structure Rules. DNV has taken a new and
innovative approach in implementing ship structure or design rules by introduction of the DNV Rule
Framework. We will describe the concepts of the DNV Rule Framework with application to the ship
domain in the following sections.
The DNV Rule Framework has been implemented in Nauticus Hull in order to separate the DNV
structure rules from the actual application. The DNV Rule Framework offers end users a transparent

232

implementation of the design rules in the software. In addition, it gives the expert user an open API
with possibilities to intervene with the rules in completely new ways previously not possible.
3.2 The Nauticus Domain model
Nauticus Hull contains a rich domain model including topology information about how structural
parts relate to each other, and how plates and stiffeners are connected. 360-degree design iterations
require the model to support design changes. During the design phases, the hull form, placement of
compartments and main structures, plate-seams and stiffeners might change. Also scantling changes
will typically be a result of design iterations. An UML description of a sample cross-section model is
shown in Fig.4.

Fig. 4: Simplified UML description of the Nauticus cross-section model

3.3 Interface to the ship domain model
It is often necessary for several applications to access the same rule base. This requires a clearly
defined interface between the rules and the different applications. The Rule Framework contains a
Rule Interface Editor for defining these interfaces. The interfaces support enumerators and domain
interface types. A sample interface is shown in Figure 5.
The high level syntax interfaces to the ship domain model in Nauticus enable expert users and rule
experts without programming skills to access and interrogate the domain model.

233

Fig. 5: Rule Interface Editor, classes and enumerators

3.4 Rule implementation
The DNV Rule Framework supports the definition, storage and execution of rules. Each rule is
described using compact JavaScript syntax. Several rules can implement the same consequent (or
predicate) and it is the individual rule premise that dictate which rule is actually executed. This way of
defining rules is close to how design rules are expressed in traditional rule books, and represent a
more transparent, maintainable and better way of implementing rules than traditional programming
languages. The relationship between the rules is automatically established by the rule engine based on
the dependencies stated in the premises, Fig.6.

234

Fig. 6: Dependencies between rules are automatically established

3.5 Task implementation
The DNV Rule Framework applies the task model to capture procedural design knowledge. The Rule
Framework provides a graphical environment with task palettes where the user can model the
workflow directly using predefined elements. The Rule Framework offer several predefined
constructs like loops, conditions, rule evaluations, user defined procedures in addition to the interfaces
to the domain model described previously. In addition to capturing design knowledge, the task model
is also used to create executable code as described in the previous section. A sample task model or
task diagram is shown in Fig.7.
Rule Editor palette:

Fig. 7: Design Pattern representing part of local requirements for plates

These task diagrams have also proven to be very useful for communicating between software
developers, and also between expert users and developers reducing the barriers of knowledge transfer,
Astrup and Wien (2006). As such, the Design Patterns combined with the applicable rule-base
constitute Best Engineering Practices or knowledge assets part of an organisation, Astrup and Wien
(2006).
3.6 Design optimization
A general framework for structural optimization needs to be able to model both constraints and costs
as function of the design variables. A global optimum is then searched for based on the chosen
objective function and the constraints modelled, Fig.8.

235

Fig. 8: An optimization framework

3.7 Structural Constraints
Constraints can be taken as linear or non-linear functions, depending either explicitly or implicitly of
the design variables. These constraints are analytical translations of the limitations that the user
wants to impose on the design variables themselves or to parameters like displacement, stress,
ultimate strength, etc. Note that these parameters are functions of the design variables, Rigo and
Fleury (2001a). One generally distinguishes between three different types of constraints:

Technological constraints (or side constraints) that provide the upper and lower bounds of the
design variables, for example plate thickness limitations due to corrosion etc.
Geometrical constraints impose relationships between design variables in order to guarantee a
functional, feasible and reliable structure. They are generally based on good practice rules
to avoid local strength failures (web or flange buckling, stiffener tripping, etc.), or to
guarantee welding quality and easy access to confined spaces.
Structural constraints represent limit states in order to avoid yielding, buckling, cracks, etc.
and to limit deflection, stress, etc. These constraints are based on solid-mechanics phenomena
and modelled with rational equations. By rational equations, we mean a coherent and
homogeneous group of analysis methods based on physics, solid mechanics, strength and
stability treatises, etc. and that differ from empirical and parametric formulations.

Nauticus Hull implements the following rule-based structural constraints:

236

Local requirements to plates and stiffeners

Thickness requirements due to corrosion
Stiffened plate field collapse (Ultimate Limit State)

Fatigue (Fatigue Limit state)

Hull girder collapse (Ultimate Limit State)
Damaged conditions (Accidental Limit State)

It is up to the end user to select the applicable constraints that are part of the design optimization.
3.8 Implementation of optimization methods
Currently the DNV Rule Framework offers two optimization methods, namely the Conjugate Gradient
method and the general purpose Monte Carlo method. The Conjugate Gradient is the fastest and
preferred method if the objective function has only one minimum or maximum. If the objective
function has several local minima or maxima the more general Monte Carlo method has to be used, to
ensure that the global minimum or maximum are found.
4. Example: Weight optimization
The total production costs, as well as the weight, of a ships hull are most strongly influenced by the
structural design of the mid-ship portion for most types of commercial ships. Optimization of midship scantlings therefore offers the greatest potential for cost and weight saving, Rahman and Caldwell (1992).
The objective of this example is to demonstrate the capabilities, Fig.9, of the DNV Rule Framework
with application to a simple weight optimization. In this simple example the specific weight in the
mid-ship area is calculated as function of the spacing between the web-frames for a typical shuttle
tanker. The calculations are based on a preliminary rule set under development, so the results should
not be used as a comparison against other rule sets. Minimum thicknesses, local requirements and
buckling criteria are used as structural constraints and drive the solution. The shuttle tanker cross
section and particulars are as shown in Fig.10.

Length between
perpendiculars
Rule length, L
Breadth moulded, B
Depth moulded, D
Draught moulded, T
Block coefficient, Cb

240 m
240
43
21
15
0,888

m
m
m
m

Fig. 9: Shuttle tanker cross-section and particulars

The Conjugate Gradient method is used to minimize the specific weight. The objective function that is
target for the optimization can be expressed as:

237

[t/m]
Where:
W(l)
Weight pr. m of ship as function of web frame spacing.
[t/m]
Wweb
Steel weight of typical web frame.
[t]
CSAreaReq Sum of area using required plate thicknesses and area of stiffeners satisfying [cm2]
required section modulus.
l
Spacing between web frames used as span of longitudinal.
[m]
7.8
density of steel
[t/m3]
Table 2: Result of minimising the Objective function using rule-based constraints
CSAreaReq
l
Weight CS/m
WebFram/m
W(l)

66130 69394 72320 74704 76028 77416 78964 82180 88402 96898 100566 114824 244450
3200 3800 4200 4400 4500 4600 4700 4800 4900 5200 5250 5350 6000
51,6
54,1
56,4
58,3
59,3
60,4
61,6
64,1
68,9
75,6
78,4
89,6 190,7
171,4 144,4 130,6 124,7 121,9 119,2 116,7 114,3 111,9 105,5 104,5 102,5
91,4
223 198,5
187
183 181,2 179,6 178,3 178,4 180,8 181,1 182,9 192,1 282,1

Fig. 10: Lightship steel weight/m ship (t) as function of frame spacing
The result of the weight optimization is shown in Fig.10 and Table 2. A framespacing of 4700 mm
gives the minimum ship weight/m in this example. In order to prove real value to the yard/designer,
the objective functions need to be extended to a least cost objective including including labor and
material costs, Rigo and Fleury (2001b). However, the example demonstrates the strong capabilities
of the DNV Rule Frameowrk to use the Nauticus Hull rule-based cosntraints in an optimization
problem.
5. Future work
5.1 Extending the ship domain model
Variations of the rule parameters it-self are readily available through the Rule Framework interface,
but the Nauticus Hull domain model cannot automatically be updated. This is an extension to the
domain model that will be considered in future work. In addition, work is on-going to interface the
DNV Rule Framework to 3D Computer Assisted Engineering (CAE) environment utilising firstprinciples methods.

238

5.2 Cloud computing

Performing automated design optimization, along the lines described above and with a parameter
space of more than one parameter, quickly becomes extremely computational intensive and
impractical, given the limited resources of a single desktop computer. The advent of cloud computing,
however, changes the formerly unattainable solution of multi-parametric design optimization into an
attainable solution and therefore, a big opportunity. The challenges are now of a more practical
character of how to organize the computational work in ways that allow a large array of
computational resources to be used efficiently. A range of security measures need to be taken in order
to guarantee the appropriate level of information protection.
5.3 Rules as a Service
As described above, the DNV Rule Framework is externalized from the application to an extent that it
could be offered as a stand-alone service. A possible next step is to offer it as a cloud service,
accessible to any external application. This service should have two interfaces:

Rule publishing
Rule execution

The publishing interface allows new versions of a rule set to be published and made available for
execution. The rule execution interface allows published rule sets to be executed.
When publishing a rule set, it must be possible for the publisher to declare its applicability and set
restrictions for use, such as access restrictions. This would enable a designer to publish rule sets that
are only accessible to his company, or only applies to a particular type of designs. Therefore, a direct
effect of this decoupling of the engineering knowledge domain from the application domain and
deploying rules as a service is the obvious benefit of enabling continuous improvement of
engineering knowledge.
6. Conclusions
Rule-based systems offer a means to increase automation and standards compliance within the design
stage of detailed ship structural design. Hence, the workload of the engineer is eased such that more
time can be spent on innovative work. Also, series effects can be explored and the design quality can
be improved. Solutions with optimal performance can be achieved. In case of violations of the design
standards, the user is informed accordingly. Therefore, this approach can not only be applied with the
objective of a reduction of design time, but can also be used for quality control.
With the application of a rule-based approach, the development of IT-based design algorithms does
not require actual programming skills but is performed with the rule dialect presented. Hence,
development complexity is reduced as only the logics describing the design standards and not
complete software architecture needs to be formulated. Therefore, rule-development might be
performed by trained engineers, i.e. by the personnel who is directly involved in the design process
and hence most familiar with the design problems and design standards. Also, the reuse design
patterns from one design to another support experience transfer and learning. .
The DNV Rule Framework can capture and store knowledge in the form of best engineering practices.
Being able to capture and store best practices as formalised electronic knowledge can provide huge
advantages to the shipbuilder and designer throughout the design process, and from one design to the
next.

239

References
ASTRUP, O.C.; WIEN, E. (2006), A workflow implementation supporting the commercial ship
design process, Workflow Handbook, Layna Fisher (Ed.)
BRACHMAN, R.; LEVESQUE, H. (2004), Knowledge representation and reasoning, Morgan Kaufmann
BUCHANAN, B.C.; SHORTCLIFFE, E.H. (1984), Rule-based expert systems - The MYCIN
experiments of the Stanford heuristic programming project, Addison-Wesley, Reading
COCHRAN, K. (2007), Rule-based ship design, RINA Int. Conf. Computer Applications in
Shipbuilding, pp.133-140.
KRGER, S. (2003), IT in Shipbuilding, 2nd Int. Conf. Computer and IT Applications in the Maritime
Industries, Hamburg
RAHMAN, M.K.; CALDWELL, J.B. (1992), Rule-based optimization of midship structures, Marine
Structures 5(6), pp.467-490
RIGO, P.; FLEURY, C. (2001a), A module-oriented tool for optimum design of stiffened structures Part I, Marine Structures 14, pp.611629
RIGO, P.; FLEURY, C. (2001b), A module-oriented tool for optimum design of stiffened structures Part II, Marine Structures 14, pp.631649
SHIP STRUCTURE COMMITTEE (2007), Comparative study of ship structure design standards
ZIMMERMANN, M. (2010), Knowledge-based design patterns for detailed ship structural design,
PhD Thesis, Univ. Rostock

240