DEVELOPMENT OF SHIPHANDLING SIMULATOR BY OBJECT ORIENTED SOFTWARE DESIGN

Han-Jin Lee, KRISO/KORDI, Taejeon, KOREA Chang-Min Lee, KRISO/KORD1, Taejeon, KOREA Gyeong-Joong Lee, KRISO/KORDI, Taejeon, KOREA In-Young Gong, KRISO/KORDI, Taejeon, KOREA

Abstract
In this paper, the design process of a shiphandling simulator developed by authors is briefly introduced. The software for the simulator was designed and developed by adopting object oriented software design technique. Authors used Unified Modeling Language (UML) to express design. The design process carried out by authors is divided into four phases, which are Analysis, System Design, Object Design, and Implementation. In addition, authors used Local Area Network (LAN) for the data communication between programs of the simulator. The shiphandling simulator, which was designed and developed by this technique, seems to have sufficient flexibility to meet any modification requirements imposed on the system.

Introduction
Authors have developed a shiphandling simulator by adopting object oriented software design technique, and detailed descriptions are given in this paper. In case of shiphandling simulators, the ship's features and functions are varying with the advance of shipbuilding technologies. Furthermore, the applicable range of shiphandling simulator itself is increasing. To meet the various requirements imposed on modem simulators, it is strongly recommended that the simulator system, especially the software for the system, have as much flexibility as possible. Therefore, authors used the object oriented design method to develop the shiphandling simulator. To be concrete, Unified Modeling Language (UML) was used to design and develop it. Object oriented method is known as an effective tool in designing and implementing various types of complex modem systoms. The design process carried out by authors is divided into four phases, which are Analysis, System Design, Object Design, and Implementation. The analysis on the requirement and various features of the system is carried out in Analysis and System Design phases. The real system is realized through Object Design and Implementation phases. In each phase, the

319

system is described by using the objects that constitute it. In addition, as each phase is completed, the objects are described in more detail.

Design Process
In the software design, many diagrams are needed to describe objects, class hierarchies, and so on. In the design of the software for shiphandling simulator, authors used UML notation developed by Grady Booch, Ivar Jacobson, and James Rumbaugh. UML is a modeling language, not a method. Most methods consist, at least in principle, of both a modeling language and a process. The modeling language is the notation that methods use to express design. The process is their advice on what steps to take in doing design. Each phase of the design process adopted by authors is as follows.

Analysis
The target of this phase is the analysis on the requirements. In this phase, the real world situation is modeled without considering technical aspects such as operating systems or programming languages. The functions that the shiphandling simulator has to have were discussed here. Furthermore, it was described that which parts of real ship would be implemented.

OwnShip

ShipName Motion 1 I Hull PdncipaJDim lJ l!!II'~

2.1
/~tchor AilchorChar

MeneuverDev Engine ManeuverForce EngineChar

WIn~ WinchChar

.[

PropRudder

- -WaterJet 1
WaterJetChar

Thruster

ThrustChar

1--21
! Propeller Rudder

PropDim

RudderDim

Figure 1. Class Diagram of Own Ship in Analysis Phase The most important target of our design is expandability. When a new device has to be added to ship model, the expandability means the ability that the system can manage it without many

320

modifications of the software. On considering it, the requirements and the main structure of the simulator were analyzed. Fig. 1 is the result of the discussion about the implementation parts of own ship. In the analysis phase, authors analyzed the target simulator, described the requirements, and objectified the results of analysis.

System Design
In the previous phase, the requirements of end users are weighted. However, in this phase, the structures when the system is implemented are weighted.
OwnShlp

1 Ship 0 Ship 1 O'----'Ship

Ship ~PS e ~ 1 Ixx IZZ Ship xg 1 Bredth Draft Ship Trim CB SurgeVel SwayVe~ HeavE, Vet Ro~lVel YawVel PitchVel DepthRatio pDepth pTidalCurrent Initialize Output ComdL~te Motion 1 ManeuverDev'--

1 Hull Hull

1 UpperStruct UpperStruct AreaT AreaL AreaSS Lea [w )Wind nitialize Force

" Winch

2_" Anchor Ancho._._~r

EtcStruCl EtcStruct

ManeuverDev1 ~ ~

Winch
Initialize Force output

Initialize Force Out~t

Initializ~ 1Parent Force ~

Output

c~u~e I
PropRudder idder

I Parent

[ Force

Initialize

J
I

c~L~x~te i
1.2

Output ComdUpdate

Initialize Force Output ComdUpdate

Output

I WlterJet

0_2 [ Thruster I Thrueler SHP Diameter Pitch xtu ztu Direction MedtCoeff Ratio Initialize Force Output ComdUpdale

I Engine

Eric Engine
initialize

TwinHull Initialize Force Get.~ddedMass

GMAreaMMnHull zh DeepMx DeepMy DeepJxx DespJzz Mx My Jxx Jzz I~B wave ank pSerth Initialize Force .MdedMass Resistance YawResist YawDamping RotiCoeff CFIowDrag PureDrfft YawRo~l WaveForce BankForce EtcForce Get.~,dedMass ~tialize Force Output CorndU~te ~tialize Force Output ComdUpdate

Torque Output ComdUpdate

1.. Parentl(~ P._~_] 1~ ent 1..2 Propeller Propeller Diameter XP Ipp JPP Pitch ThrustOeduction Wake RPM Initialize Force RPMChange ComdLJpdate
NoSlades

1.2 [ Rudder

I Rudder

D~I

Turbine
GearRatio SHP COmdRPM Initialize Torque ComdUpdate

Area ASpectRatio xr ,~e Wake InteractionCoeff Initialize Force AngleChange ComdUpdate

MaxTorque CorndTerque initialize Torque ComdUpdate

Figure 2. Class Diagram of Own Ship in System Design Phase

321

The target of this phase is to create a high level structure of the system, figuring out the objects required to build the functionality and organizing them so that related groups are defined. In the phase, the functions and rolls of the objects that are roughly defined in the previous phase are described in more detail. In addition, the associations between objects and the structure of the system are designed in detail. Fig. 2 shows the result of the detail design of the objects that were created in the analysis phase to express the each part of ship. In the figure, the attributes and the operations that each object has to have are briefly described. Furthermore, the associations between objects are showed clearly.

Object Design
The previous phases are for the design of the system structure. On the other hand, the remaining phases are for the coding. The target of this phase is to add to object model the implementation details necessary for successful coding. Firstly, a programming language is selected. Then, the types of attributes and the parameters of operations for each object are described in detail.
O~lhll

~_~z

.m j E m s ~ u = ~ w ~ u , g =

2"

.ou~(~,~

v,=l~mto.=.,

.~_Co= no.== ~ S ~ = x , U . .~ r ~

.~j~WM W~

~.,o~,
.$==.t,~
b

h~pow,~S~Wp, ~NW"cnw~

o ,,~ . '
)

~ L )

P~Ir~

:T:. 0 ~ ~(=.r,OS.u= M=~r,=O.=}

~ , c + ~ ~ ~o~eS~

t
Figure 3. Class Diagram of Own Ship in Object Design Phase
In the previous description, the term 'object' was used without the definition. In the object

322

oriented programming, an object indicates a unit that has variables for its state and procedures for its behaviors. In other words, if there are ship A and ship B, each is an object. On the other hand, a class means the definition of attributes and operations of similar objects. For example, ship A and ship B are objects belong to class Ship. Strictly speaking, what were designed in the previous phases are not the objects but the classes. However, these terms are occasionally used without distinction because an object is an instance of class in the run time. Fig. 3 is an example of the detailed design of class structure and association for the programming. This is the case of own ship. C++ was selected as the programming language. In the figure, it is showed that the types of member variables and the parameters of member functions are described in detail.

Implementation
The last phase of software development is to make source code. In this phase, each function of designed class is implemented in the concrete. If the source code is edited, this modification causes the object design to change. The change of object design has an effect on the implementation of programs. In other words, the object design and implementation phases draws a design loop.

Program A

User Interface

Functional Body

"

"

Net work

'"'""" i ProgramB
"

// //
Figure 4. Software Communication Structure As stated above, the main target of the design was expandability. Therefore, the simulation software was designed for its each function to be operated as independently as possible. Firstly, each part that could exist on other computer was made as a independent program. The data communication between these programs is carried out through Local Area Network (LAN) by using Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). Secondly, the program itself was designed

323

for user interface and functional body to have little effect on each other. The functional body was designed through the design process mentioned above so that each function could exist as an object. All programs were coded by using C++.

Software for Shiphandling Simulator

The result of the design and development process mentioned above is the simulation software. Our software is comprised of many programs. The first is Motion Solver program. In order to generate the maneuvering motion of own ship, equations of ship motion are solved taking various maneuvering devices and environmental conditions into account. The next is Instructor Console program. Most controls related with simulator operations are made by this program. Through this program, all controls carried out in the bridge are displayed in the Instructor Console. In case that right of control is transferred to Instructor Console, simulation can be carried out by mouse. Tug control can be done only in Instructor Console. The last program in the instructor's room is 2D Map Display program. This program displays geographical information like shorelines, navigable areas, and so on in bird-eye's view type.

Instructor Room
Motion Solver

Bridge

TCP/IP Broadcast (UDP/IP) ~ ~ ~ !

Instructol Console

Y ,

2D Map Display Figure 5. Organization Diagram of Software for Shiphandling Simulator

324

In the bridge, there are 3D Visual Model program, H/W Interface program, Conning Display program, ECDIS program, and Radar program. Most information related with own ship is displayed by Conning Display program. Heading angle, rudder angle, propeller rpm and so on are displayed here as well as water depth, wind and so on. H/W Interface program controls all the devices in the bridge. That is, it creates analog signal necessary for the peripheral devices control, by which it controls all the devices. Fig. 5 shows the organization diagram of the programs. All programs on the simulation use network communication to change information except ECDIS program. ECDIS program use serial line to meet the standard of ECDIS itself. In addition to these programs, there are pre-processor to make scenarios and database and post-processor to examine and analyze the results of simulation. On the simulation, all information are collected and distributed by Instructor Console program. Instructor Console program receives the data from Motion Solver program and H/W Interface program. Then, Instructor Console program integrates and sends the data to all programs except itself. Especially, some programs only receive the data. They are the visualization programs like 2D and 3D Display programs. The communication between Instructor Console program and the visualization programs is carried out by using broadcasting method. Instructor Console program broadcasts the data packet without regard to the number of visualization programs. All visualization programs receive this packet and use the necessary data. In this case, connectionless transport, also called datagram service, was used. UDP/IP was used for the datagram protocol. On the other hand, connection-based transport, also called stream service, was used for the communication between Instructor Console program, Motion Solver program and H/W Interface program. TCP/IP was used for this communication.

Conclusion
In this paper, authors described the design process of shiphandling simulator based on object oriented software design. UML notation was used on the discussion and the expression of the design. Authors found that UML notation was useful on the design of the complex system like shiphandling simulator. In addition, it was found that the separation of programs by using network is effective on the maintenance. The key words of our design are expandability and objectification. The shiphandling simulator, which was designed and developed by this technique, seems to have sufficient flexibility to meet any modification requirements imposed on the system.

Acknowledgement
The content of this paper is the result of Inherent Research Project of KRISO, "Development of

325

Core Technology for Evaluating the Fairway Safety", sponsored by Korean Ministry of Science and Technology.

References
. Fowler, Martin and Scott, Kendall (1997), UML Distilled, Addison-Wesley Publishing Company Eriksson, Hans-Erik and Penker, Magnus (1998), UML Toolkit, Wiley Computer Publishing. Dumas, Arthur (1995), Programming WinSock, Sams Publishing. Boner, Pat (1996), Network Programming with Widows Sockets, Prentice Hall PTR. Quinn, Bob and Shute, Dave (1996), Windows Sockets Network Programming, Addison-Wesley Publishing Company

3. 4. 5.

326