International Journal

on Marine Navigation

and Safety of Sea Transportation

Volume 5

Number 2

June 2011

175

1 INTRODUCTION

Some shipboard systems and equipment (AIS,

GMDSS, ARPA, Navtex, and GPS) are used in the

automation of information acquisition and exchange.

However, these systems do not ensure exchange

of information in complex situations, where co-

operation between navigators (or coast station offic-

ers, helicopter pilots, etc.) has to be established.

The automation of the message interchange process

in maritime transport could support navigators

in this case. Moreover, such automation is a basis

for further development of more complex, agent

based navigation support system including an auto-

mated negotiation layer. Such automated negotiation

systems are well known in e-business and trading

environments and presented, among others, in Beam

1997, Paurobally 2003, Karp 2004.

Herein proposed is an approach to solve

the automation of the message interchange process

in maritime transport. This paper shows results

of the research continued after the one described in

Pietrzykowski et al. 2003, 2005, 2006. A general

concept of communication system is shown. The on-

tological structure of messages is introduced and its

description in XML Schema is proposed to formal-

ize the format of message contents and is an exten-

sion of the navigational based ontology in Mal-

yankar et al. 1999, Mingyang P. et al. 2003, Kopacz

et al. 2004 and Pietrzykowski et al. 2006.

The proposed solutions are based on an analysis

of a real process of communication between naviga-

tors presented as example in Pietrzykowski et

al. 2006.

2 A CONCEPT OF AUTOMATION OF

MESSAGE INTERCHANGE

The transformation of communication from human-

to-human to fully automated one is a continuous

process. Its purpose is not to provide the environ-

ment for fully automated communication between

machines, but rather to allow communicating be-

tween:

− humans (system operators),

− machines (e.g. exchanging information between

ships),

− humans and machines (in all possible combina-

tions and proportions).

Figure 1 shows the scheme of the proposed com-

munication between the sender and the receiver. A

message built on sender’s side can include infor-

mation from the operator (e.g. navigator), even if

their primary source is any of the available electron-

ic systems. This information - sentences - can be put

in manually by the operator. Besides, some infor-

mation contained in a message is taken directly from

external electronic systems (e.g. shipboard AIS).

The aim of the communication system is to compose

a valid message by means of the previously defined

commonly understood syntax using the information

contained in these sentences.

The receiver’s system should be able to read this

message and decompose it to small sentences shown

directly to the operator, to store it or send to any of

the available external systems. Moreover, the opera-

tor can obtain additional information from the exter-

nal systems after they process any data from the

message.

Automation of Message Interchange Process in

Maritime Transport

Z. Pietrzykowski, G. Hołowinski, J. Magaj & J. Chomski

Maritime University of Szczecin, Szczecin, Poland

ABSTRACT: The paper is focused on automation of data message interchange in maritime transport. A gen-

eral concept of communication system is proposed. The authors deal with some issues of automatic commu-

nication in marine navigation. The principles and form of communication based on the use of maritime

transport communication ontology with XML Schema are described.

176

The proposed concept is a technical communica-

tion basis for further research in the following areas:

− visualization of information,

− automated negotiations between objects of com-

munication in maritime transport,

− the latest systems on the market show the im-

portant role of efficient and ergonomic interface

(e.g. visual interfaces of mobile devices). The in-

terface for communication system in maritime

transport should support the visualization of both

source and destination objects of the communica-

tion. It should ensure that navigators understand

who takes part in this process (visual verification

of participants of the communication is provided

as support for the operator).

Figure 1. Scheme of proposed communication between two ob-

jects (e.g. ships). Note: a gray marked elements show automat-

ed data processing.

The proposed system concept can be regarded as

a basis for an automated negotiation system in mari-

time transport, which can be used, for instance,

as an expert system helping to optimize navigation

issues. In that case the automated or semi-automated

negotiation support system requires at least the fol-

lowing functionalities: information sharing among

objects (e.g. ship positions, speeds, courses) and au-

to-negotiation between them (e.g. implemented

as agents).

In Beam 1997 it is acknowledged, with a support

of several examples, that building an automated ne-

gotiation system is a challenging and difficult task.

Both the need for ontology and the need for a nego-

tiation strategy are highlighted that study. Ontology

is a way of categorizing objects in such a way that

they are semantically meaningful to a software

agent. The negotiation strategy in the navigational

environment should be clear in maritime transport

(while the strategy is a secret in known trading sys-

tems).

However, the functionalities indicated above can-

not be realized without automated communication.

The sections that follow present an ontology and its

implementation in XML Schema required to provide

for automated communication.

3 THE ONTOLOGICAL STRUCTURE OF

MESSAGES IN MARITIME TRANSPORT

Ontology plays a major role in supporting the infor-

mation exchange processes in maritime transport. In

general, it provides a shared and common under-

standing of the domain of knowledge, communica-

tion, etc. The problem of ontology for maritime

transport is mentioned, among others, in Malyankar

et al. 1999, Mingyang P. et al. 2003, Kopacz et al.

2004 and Pietrzykowski et al. 2006.

One of the ways of message interchange is the

use of radiotelephone VHF communication. The

basic element of radiotelephone dialogs between ob-

jects such as ships, coast stations, etc., is a single

message. Each message consists of at least one sen-

tence. In practice sentences are usually simple ones

and contain one piece of navigational information,

e.g. for ship encounter situation (Fig. 2.):

− Alpha: ‘Our CPA is close to 0’,

− Alpha: ‘Is it possible that we pass starboard to

starboard?’

177

Figure 2. Ship encounter situation.

The sentences shown above contain one piece of

navigational information – such piece is called an at-

tribute in this context. Complex sentences - contain-

ing more than one attribute - may also be heard, e.g.

two-attribute sentence: Beta: „I intend to alter my

course to starboard soon and cross ahead of you at

a safe distance.” In this particular example one nav-

igator informs of his intention to alter his ship’s

course to starboard and of the closest point of ap-

proach after the maneuver is completed.

In each sentence more than one attribute can be

placed if they have the same simple sentence form

when expressed separately. In other words, we can-

not announce one piece of information in a sentence

and ask about another piece of information in the

same sentence.

Figure 3. Sentence attributes divided into sentence forms.

Source: Pietrzykowski et al. 2006

Considering the forms of sentences, we should

note that they significantly affect the meaning of

formulated messages. A single message can be ex-

pressed as an interrogative and positive sentence.

However, according to the accepted rules and using

the recommendations concerning communication at

sea (IMO 2002, IMO 2005) information is designed

here as a group of attributes that can be linked to all

possible types of sentences: Questions, Answers and

Tells (statements).

Figure 3 shows that all information about inten-

tions, permissions, information, warnings and re-

quests can be expressed in the form of statements

(Tell). The set of attributes related to intentions,

permissions and information can be also provided in

form of a Question (when we ask about e.g. permis-

sion for maneuver) or Answer (when we receive the

permission for this maneuver).

The ontological structure of a message (Fig. 4)

in the proposed automatic communication results

from the structure of verbal communication

and technical conditions:

− Header – supplemental data placed at the begin-

ning of a block of data being transmitted, in-

cludes:

− Sender – object sending a message (ship, coast

station),

− Receiver – object(s) getting the message from

sender (ships(s), coast station(s), objects locat-

ed in circle- or square-shaped area),

− Sent – time of message casting,

− Other control information such as validity time,

communication ID, information about message

repetition.

− Body – information content of the message.

It is assumed that a message can be transmitted

from the sender to a single destination (precisely de-

fined address - unicast addressing), any group of in-

terested destinations (multicast) or finally geocasted

– to destinations identified by their geographical lo-

cations.

0 1 2

3 4 5 6 7

Beta

Alpha

Beta

178

Figure 4. Structure of a message for automatic communication.

In the last case the location is pointed by rectan-

gular or circular area described with geographical

coordinates, where elevation is an optional parame-

ter.

The body of the message consists of three groups

of data related to all possible types of sentences:

questions, answers and tells.

4 USE OF XML SCHEMA TO DESCRIBE

ONTOLOGY

The process of developing the ontology and its result

in the form of technical description of message syn-

tax is a cyclic one. In each iteration of this model the

following steps are required: updating requirements

and analysis, design of ontology, implementation-

testing of technical description of messages, mainte-

nance. The result of the cycle is the richer version of

both ontology and document description.

When the ontology for maritime transport com-

munication is defined (the step of designing ontolo-

gy is successfully made), it has to be described more

precisely with constraints on the syntax and struc-

ture. It will allow generating and validating XML

messages in an applied telecommunication system.

XML Schema or DTDs can be used for that purpose.

The XML Schema recommendation describes the

content and structure of XML documents in XML. It

includes the full capabilities of Document Type Def-

initions (DTDs), so that existing DTDs can be con-

verted to XML Schema. Compared to DTDs, XML

Schemas have additional capabilities.

According to the World Wide Web Consortium

(W3C), XML Schema is itself represented in an

XML vocabulary and uses namespaces, substantially

reconstructs and considerably extends the capabili-

ties found in XML document type definitions

(DTDs).

XML Schema is itself represented in an XML vo-

cabulary, whereas DTDs document is described in a

unique syntax borrowed from SGML DTDs.

The size of message generated according to the

description in XML Schema is about 50% larger

than that based on DTDs. However, it does not seem

to be a serious disadvantage, while its typical size is

still several hundreds of characters and, if necessary,

it can be compressed during transmission.

Finally, in some cases DTDs do not support the

functionality required for XML documents, i.e. they

do not ensure the compatibility with new XML

products, do not support data types, and provide less

complex constraints on the validity of XML docu-

ments. W3C recommend using XML Schema.

Therefore, in the following discussion it is as-

sumed that XML Schema applies to the ontology in

the way that allows automating building, validating

and understanding of messages for communication

in maritime transport.

<?xml version="1.0" encoding="utf-8"?>

<xs:schema elementFormDefault="qualified"

xmlns:xs="http://www.w3.org/2001/XMLS

chema">

<xs:element name="Message">

<xs:complexType>

<xs:sequence>

<xs:element name="Header">

<xs:complexType>

<xs:sequence minOccurs="1" maxOccurs="1">

<xs:element name="Sender" type="_Sender"/>

<xs:element name="Receiver" type="_Receiver">

179

<xs:element name="Sent" type="_Timestamp" />

<xs:element name="ValidTill" type="_Timestamp" />

</xs:sequence>

<xs:attribute name="CommunicationID"

type="xs:string"

use="required" />

<xs:attribute name="MessageRepeated"

type="xs:int"/>

<xs:attribute name="ConfirmationRequired"

type="xs:boolean" />

</xs:complexType>

</xs:element>

<xs:element name="Body" minOccurs="1"

maxOccurs="1">

<xs:complexType>

<xs:choice minOccurs="1" maxOccurs="1">

<xs:sequence minOccurs="1" maxOccurs="1">

<xs:element name="Answer" minOccurs="0"

maxOccurs="255">

<xs:complexType>

<xs:choice>

<xs:element ref="Information" />

<xs:element ref="Intention" />

<xs:element ref="Permission" />

</xs:choice>

<xs:attribute name="Source">

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:enumeration value="Automatic" />

<xs:enumeration value="Human" />

</xs:restriction>

</xs:simpleType>

</xs:attribute>

</xs:complexType>

</xs:element>

[…]

</xs:schema>

Figure 5. Fragment of the ontology written in XML Schema.

Figure 5 shows the fragment of the more detailed

ontology for maritime transport communication

written in XML Schema. It is the technical form of

message structure description for automatic commu-

nication that is shown in Figure 3. Its application in

the real system allows to generate and validate mes-

sages.

A note is required about some XML Schema de-

mands. All time stamps (type=”_Timestamp”) con-

sist of combined date, time and time zone descrip-

tion. However, the time format is strictly required by

XML Schema definitions. It requires storing time

value in form of hh:mm:ss.ff (hh-hours, mm-minutes,

ss-seconds, ff –hundredths of a second).

We assume that some sentences can be ful-

ly-automatically exchanged between the sender and

the receiver. Therefore, for each sentence additional

information should be provided to indicate if a hu-

man or machine is the source of information. It is

important when the communication is not only be-

tween system operators (humans) but is semi- or ful-

ly-automatic (between machines).

One of the results of the maritime transport on-

tology development is the message structure – a uni-

versal envelope that allows exchanging information

among objects of the communication process (ships

and all other types of watercraft, aircraft, coast sta-

tions, land vehicles). Although in the example men-

tioned in the next section the communication be-

tween two ships is described, more general

communication can be processed (Fig. 6: note <Ves-

sel> tags in both sender and receiver related lines in

message headers).

5 APPLICATION

Let the dialog between two ships: Alpha and Beta,

presented in the paper by Pietrzykowski at al. 2006,

be an example – a case study – showing the commu-

nication described by XML messages generated ac-

cording to the ontology described by XML Schema.

A situation. Both ships - Alpha and Beta - (Fig.

2) are in a situation that COLREGs qualify as “ships

are on opposite courses or nearly opposite courses”

– see Rymarz 1995. In this case, both ships are

obliged to alter course to starboard (pass each other

port-to-port) in order to safely pass each other.

However, in certain conditions the regulations allow

ships to alter their courses to port side, so that they

pass each other on starboard sides.

Verbal communication. In our case, the ship Al-

pha suggested to the ship Beta that both ships pass

on their starboard sides, as passing to port might

have caused a dangerous situation due to the pres-

ence of another ship. In response, the Alpha received

information that the Beta is about to alter course to

starboard (because she approaches her waypoint),

which will result in passing ahead of Alpha at a safe

distance and the encounter situation will be solved.

The Alpha accepts this solution.

Messages used in automated communication.

The above dialog can be described in the form of

XML messages built according to the ontology

structure described in XML Schema (Figure 6).

The record also illustrates the membership of in-

formation kinds which are related to a given attrib-

ute. For example, attributes “Expectation”, “Re-

quest” and “Demand” may be related to the same

kind of information.

<?xml version=”1.0” encoding=”utf-8”?>

<Message

xmlns:xsi=”http://www.w3.org/2001/XMLSchema-

instance” (View source…)>

<Header CommunicationID=”AB02”

MessageRepeated=”0” ConfirmationRequired=”0”>

180

<Sender><Vessel Name=”Alpha”

MMSI=”231002300” /></Sender>

<Receiver><Vessel Name=”Beta”

MMSI=”262998700” /></Receiver>

<Sent Date=”2010-11-01” Time=”18:00:01.00”

Zone=”UTC” />

</Header>

<Body>

<Position Latitude=”50’49,1’N”

Longtitude=”01’03,1’W” Altitude=”0” />

</Information>

</Tell>

<CPA Value=”0.1NM”>Dangerous</CPA>

<RightOfWay Whose=”Indefinite” Who=”We”

Action=”MustGiveWay” />

</Warning>

</Tell>

<Passing Type=”Opposite” Side=”Starboard”

Berth=”0.5NM” />

</Permision>

</Question>

</Body>

</Message>

<?xml version=”1.0” encoding=”utf-8”?>

<Message

xmlns:xsi=”http://www.w3.org/2001/XMLSchema-

instance” (View source…)>

<Header CommunicationID=”AB02”

MessageRepeated=”0” ConfirmationRequired=”0”>

<Sender><Vessel Name=”Beta” MMSI=”262998700”

/></Sender>

<Receiver><Vessel Name=”Alpha”

MMSI=”231002300” /></Receiver>

<Sent Date=”2010-11-01” Time=”18:00:51.00”

Zone=”UTC” />

</Header>

<Body>

<Time Date=”2010-11-01”

Time=”18:02:00.00” Zone=”UTC” />

</AC>

</Maneuver>

</Intention>

</Answer>

<Passing Type="Cross" Side="Ahead"

Berth="1.2NM" />

</Permission>

</Question>

</Body>

</Message>

<?xml version="1.0" encoding="utf-8"?>

<Message

xmlns:xsi=”http://www.w3.org/2001/XMLSchema-

instance” (View source…)>

<Header CommunicationID="AB02"

MessageRepeated="0" ConfirmationRequired="0">

<Sender><Vessel Name="Alpha"

MMSI="231002300" /></Sender>

<Receiver><Vessel Name="Beta"

MMSI="262998700" /></Receiver>

<Sent Date="2010-11-01" Time="18:01:22.00"

Zone="UTC" />

</Header>

<Body>

<Passing Type="Cross" Side="Ahead"

Berth="1.2NM" />

</Permision>

</Answer>

</Body>

</Message>

Figure 6. A dialog between two ships written in XML – all

massages validated with the ontology described in XML

Schema.

Message a) is sent by the ship Alpha, and its body

consists of two positive sentences (position and

warning against a dangerous situation) and one inter-

rogative sentence (permission for passing). Re-

sponding, the ship Beta sends message b), in which

she declares an intention of making a turning ma-

neuver to starboard soon and asks for permission to

pass ahead of Alpha at a safe distance. The ship Al-

pha sends an answer (message c)) which includes

the permission for the proposed passing.

6 CONCLUSIONS

A general concept of communication system

for maritime transport was introduced. The cyclic

development process of ontology and its result –

technical description of message syntax (XML

Schema) – allow to build the solution in iterative

steps. Therefore, these authors proposed an ontolog-

ical structure of messages and its description in

XML Schema to formalize format of contents of

messages. The general form of message envelope

was developed to support communication among

watercraft, aircraft, coast stations and land vehicles.

It is a basis for the development of the general on-

tology for maritime transport.

XML messages validated with partial maritime

ontology described in XML Schema were shown as

the example of implementation of communication

between two ships.

181

Further research will be focused on defining and

implementation of detailed ontology parallel to the

development of automatic negotiation system based

upon proposed automated communication system.

REFERENCES

Beam C., Segev A. 1997, Automated Negotiations: A Survey

of the State of the Art. In: Wirtschaftsinformatik: 263-268,

Vol. 39 (1997).

INTERNATIONAL MARITIME ORGANIZATION (IMO)

2002, Resolution A.918(22) adopted 29.11.2001, IMO As-

sembly 22nd Session 25.01.2002.

INTERNATIONAL MARITIME ORGANIZATION (IMO)

2005, Standard Marine Communication Phrases (English-

Polish edition), Maritime University of Szczecin, Szczecin.

Karp A. H. 2004, Rules of Engagement for Automated Negoti-

ation. In: proc. of the First IEEE International Workshop

on Electronic Contracting (WEC'04), San Diego, USA: 32-

39.

Klein M., Fensel D., van Harmelen F., Horrocks I. 2001, The

relation between ontologies and XML schemas. In. Linkö-

ping Electronic Articles in Computer and Information Sci-

ence, Vol. 6, No. 004

Kopacz Z., Morgaś W., Urbański J. 2004, Information on

Maritime Navigation; Its Kinds, Components and Use. In:

European Journal of Navigation, vol. 2, no. 3, Aug 2004.

Malyankar R. M. 1999, Creating a Navigation Ontology.

In: Tech. Rep. WS-99-13, AAAI Press: 48-53, Menlo Park,

CA.

Mingyang P., Deqiang W., Shaopeng S., Depeng Z. 2003, Re-

search on Navigation Information Ontology. In: proc. of the

11th IAN World Congress Smart Navigation – Systems and

Services, October 2003.

Paurobally S., Turner P. J. and Jennings N. R. (2003), Auto-

mating negotiation for m-services. In: proc. of the IEEE

Transactions on Systems, Man, and Cybernetics (Part

A: Systems and Humans), Special issue on M-services.

33(6): 709-724.

Pietrzykowski Z., Chomski J., Magaj J., Niemczyk G. 2006,

Exchange and Interpretation of Messages in Ships Commu-

nication and Cooperation System. In: Advanced in

Transport Systems Telematics, Ed. J. Mikulski, Publisher

Jacek Skalmierski Computer Studio, Katowice 2006, pp.

313-320.

Pietrzykowski Z., Magaj J., Chomski J. 2003, Sea-Going Ves-

sel Control in the Vessel Communications and Co-

Operation System. In: Scientific Papers, Silesian University

of Technology, Transport No.51, Katowice 2003, pp. 455-

462. Proc. of the 3rd International Conference Transport

Systems Telematics – 2003.

Pietrzykowski Z., Magaj J., Niemczyk G. 2002, Chomski J., A

sea-going vessel in an intelligent marine transport.

In: Scientific Papers Silesian University of Technology,

Transport No. 45, Katowice 2002, pp. 203-213. Proc. of the

2nd International Conference Transport Systems Telematics

– 2002.

Rymarz W., A handbook of Collision regulations (in Polish),

Published by Trademar, Gdynia 1995, Poland.