769

1 INTRODUCTION

1.1 Background

The shipping industry currently goes through a rapid

development in terms of digitalization and process

automation. This applies to onboard systems as well

as data collection on the ship for operational efficiency

or environmental monitoring purposes. Today, this is

sometimes referred to as Shipping 4.0, or the adoption

of Industry 4.0 technologies to the shipping sector,

A New Architectural Framework for Digitalization of

Maritime Intelligent Transport Systems

M. Hagaseth

, Ø.J. Rødseth

, T. Krogstad

& M. Bakke

SINTEF Ocean AS, Trondheim, Norway

ITS Norway, Trondheim, Norway

Grieg Connect, Kristiansund, Norway

North Sea Container Line (NCL), Haugesund, Norway

ABSTRACT: Digitization in international shipping is an increasingly important topic, but for many years, the

lack of accepted international standards and the usage of many different regional solutions, especially for

communication between ships and ports, has made the introduction of digitalized solutions difficult. Since

2020, important work has been done in IMO to harmonize international standards supporting ship-port

interactions, and this work has now been supported by both shipping, ports, and international standardizations

organizations. IMO, through its facilitation committee (FAL) and EGDH (Expert Group on Data

Harmonization) is developing the IMO Reference Data Model that covers mandatory reporting requirements

related to port calls. This conceptual data model is mapped to three technical data models in three different

domains, namely, UNECE (trade), WCO (customs) and ISO 28005 (maritime) to ensure the interoperability

between the different ICT systems participating in the data exchange. The IMO Reference Data Model has also

been extended with operational data to handle Just-In-Time arrival and departure and also nautical information

to ensure that the specification of the locations in ports (berths, pilot boarding places, bollards etc) are the same

for different usages. Several international organizations as BIMCO (the largest ship owners' organization) and

international port organisations as IAPH, IPCSA and IHMA are strongly involved in this work. This paper

summarizes work done by IMO and others to clarify the roles, functionalities and ICT-systems (

Information and

Communications Technology)

that are needed to support the various processes needed to be performed during

a port call. These definitions will form the basis for defining a Maritime ITS (Intelligent Transport System)

Architecture which will also need to be related to road ITS and also to e-Navigation functionalities. The

Maritime ITS Architecture described in this paper contains three levels, namely the Domain Definition

(generalized roles that represent people, organizations and equipment in the system), the Processes (definitions

of processes and functions that need to be supported to make the domain work), and the Information model (a

generalized information model covering the information elements that are required by the functions and

processes). In addition to this comes the layers to describe the physical implementation architecture, and the

layers to describe the service implementation (e.g. APIs) and the protocols.

http://www.transnav.eu

the

International Journal

on Marine Navigation

and S

afety of Sea Transportation

Volume 17

Number 4

December 2023

DOI: 10.12716/1001.17.04.

770

and this is explored with great interest by many large

companies in the sector [1].

However, these developments also include more

conventional digitalization and automation of

administrative and other work processes. This has a

history back to the 1970s when computers started to

be introduced on ships and in offices. This

corresponds to what one can look at as the third

industrial revolution [2]. This includes digitalization

of the information exchanges between ships and ports

where port clearance to national authorities, port

approach navigation, just in time arrival negotiation,

cargo handling and ship supplies are among the

processes that are changing.

A characteristic of ship and port operations is that

several very different domains overlap. This includes

nautical operations and e-navigation, authority

reporting, general ship and port operations, trade

related data exchanges as well as cargo logistics. This

has made it difficult to coordinate developments of

data communication standards, but an initiative from

IMO has started to resolve some of the differences:

This is the IMO Compendium and the IMO Reference

Data Model (IRDM) that harmonize standards from

ship operations (ISO), authority reporting (World

Customs Organization) and international trade and

transport (UN/ECE). The IMO Compendium has also

been extended into more operational areas, such as

just in time arrivals in port, waste delivery and more.

We refer the interested reader to an earlier paper for a

more detailed discussion of the IRDM and the IMO

Compendium [3].

To make the harmonized ship-shore information

exchange useful in practise, it is also necessary to have

a clear view of the typical ICT landscape in seaports

as well as the processes that make use of the ICT

systems. Work to identify this has now been

completed by a correspondence group in IMO [4].

This group has developed a first taxonomy for the

most common systems seen in the port: PCS (Port

Community System), TOS (Terminal Operating

Systems), VTIS (Vessel Traffic Information System),

PMIS (Port Management Information Systems), and

MSW (Maritime Single Window). However, the actual

configuration and the capabilities of each system type

differs between ports and particularly between large

and small ports.

Another issue of concern is the integration of the

general geospatial information with operational

information. It is important that the identification

codes, for instance for bollards and other quay-side

infrastructure, are harmonized between the

operational and geospatial standards. For instance,

when a ship master plans a berth arrival based on

operational instructions received for instance through

an ISO 28005 XML message [5], the locations should

be specified in the same was as in ECDIS chart

overlays, provided in the IHO S-131 format [6].

The geospatial overlap continues into the terminal

area where cargo and cargo transport locations are

important for logistics and hinterland transport. This

brings the ship operations into the intelligent

transport system (ITS) domain. Initiatives are also

under way to see if it possible to define a maritime ITS

architecture that further links ship operations into the

overall transport chain [7].

1.2 A Maritime ITS Architecture

There are several ITS architectures that has been

proposed over the years. These architectures attempt

to create an overall structure for development of

compatible digitalization standards in the selected

domain. Also, an ITS architecture is a special case of

the more general information technology (IT)

architecture [8]. We have previously suggested a

structure for a maritime ITS architecture as illustrated

in Figure 1 [9]. This has been updated with a physical

architecture layer since first published.

Figure 1. A Suggested Maritime ITS Architecture [9]

The grey rectangles represent the actual ITS

architecture and are respectively:

− Domain definition: This is the definition of the

domain and its delimitation, including the

generalized roles that represent people,

organizations and equipment in the system.

− Processes: This layer contains the definition of the

processes and functions that need to be supported

to make the domain work.

− Information model: This is a generalized information

model covering the information elements that are

required by the functions and processes.

The white rectangles represent the services, e.g. as

application programming interfaces (API), used to

connect processes together, and the protocols that are

used in a distributed implementation of the system.

We have also added a physical architecture layer

above these layers as that is needed to define how

functions are distributed in the actual system. The

physical architecture will normally be different in

different implementations of the system, e.g. in

different ports or countries.

The purpose of the ITS architecture is that the

physical architecture, the services and protocols can

be developed independently to suit specific functional

requirements, but that the overall architecture ensures

a minimum interoperability between them.

As one may already have guessed, the IMO

Reference Data Model is already a start on the

information layer in the architecture. The rest of this

paper will give an introduction to the other parts of

the architecture as well as to some concrete parts of

the physical implementation.

1.3 Paper Structure

This paper gives an overview of the levels Domain

Definition, Processes and Information Model in the

Maritime ITS Architecture. It also describes some

relevant technical standards to be used for ship-shore

771

interactions, and it also describes some ICT systems

relevant to support the processes.

2 DOMAIN DEFINITION

2.1 Domain delimitation

The domain of Maritime ITS is not fully defined yet,

but the preliminary definition is that it at least should

include the ship and the entities that are directly

interacting with the ship as exemplified by Figure 2.

Figure 2. The Proposed Maritime ITS Domain [from [17]]

In addition to this definition, it may also be

necessary to define the delimitation of the shore side

extension of the domain. This delimitation is most

relevant for the port and ship operations as these have

significant interaction also with other shore side

functions such as international trade and transport.

This model is also preliminary as it may be extended,

e.g. to ship building, repair and decommissioning.

2.2 Maritime ITS Roles

From the IMO FAL correspondence group on

developing Guidelines on Electronic Signature

Systems and Operational Port Data [1], we have the

parties defined as described in Table 1. Each party

represents a group of stakeholders fulfilling a certain

role before, during and after the port call.

3 PROCESSES

Table 2 gives an overview of the tasks and processes

needed to be performed by each role during a port

call. The tasks are divided into the phases

Marketing/Contracting, Planning, and Execution. This

table is based on work done by the IMO FAL

correspondence group on developing Guidelines on

Electronic Signature Systems and Operational Port

Data [1] and also on work done in the AEGIS project.

The Marketing/Contracting phase includes

creating the contact between the stakeholders that

have a need for transport or a service, and those who

can offer transport and services that fulfil the demand.

It consists of publishing the needs or offered services,

establishing contact between the parties, agreeing on

the terms of the service and the sale of the service. For

container transport, this will take the form of a

booking (carriage contract), meaning that information

about the container handling must be agreed with the

vessel and cargo service providers in the terminal. For

bulk, this will involve chartering of a ship and

deciding on which ports to call at for this type of bulk

and the chosen ship (sale of goods contract). If there is

no fixed contract with the terminal, this must be

arranged with the vessel and cargo service providers

in the terminal.

In the Planning phase, the transport and services

are planned and managed based on actual and

foreseen demands and information about the

infrastructure and the traffic conditions. The planning

includes decisions about

− Voyage/Passage planning

− Berth arrival planning, including VTS (Vessel

Traffic Service)/pilotage area planning

− Port arrival planning, including VTS/pilotage area

planning

− Vessel and cargo service planning

− Nautical service planning

− Request clearance

− Berth departure planning, including VTS/pilotage

area planning

− Port departure planning, including VTS/pilotage

area planning

Voyage/Passage Planning: According to SOLAS

Chapter V Regulation 34, the master shall ensure that

the intended voyage has been planned by using

appropriate nautical charts and nautical publications.

This is done based on nautical charts and publications

from the hydrographic service provider, port

information from the port planner, and berth

information from the berth planner.

Berth planning arrival: The ETA Berth (Estimated

Time of Arrival) is normally sent by the ship master to

the ship agent by e-mail, which then forwards this to

all parties ashore on behalf of the vessel [3]. More

generally, the party having the role of the ship

manager provides the ETA Berth to the berth planner,

which decides on the RTA Berth (Requested Time of

Arrival), and provides this back to the ship manager.

If the ship manager accepts the RTA Berth, this

becomes the PTA Berth (Planned Time of Arrival).

Port arrival planning: The vessel (via the ship

manager role) advises the port planner on the ETA

pilot boarding place based on the PTA berth. The port

planner provides back a RTA pilot boarding place to

the ship manager, which becomes the PTA pilot

boarding place, if accepted.

Vessel and Cargo service planning: The timing and

location of vessel and cargo services during the ship

visit to a berth is very important to be able to

complete all necessary services on time, before

departure from the berth.

Nautical service planning: The ship manager role

(eg. vessel or agent) orders nautical services from

nautical service providers, like pilots, tugs and

linesmen at a certain time before they are needed, to

avoid financial consequences or unavailability at the

time when the services are required.

Request clearance: The ship manager (e.g. ship

agent on behalf of the ship master) requests clearance

to enter the port, and the port authorities give

clearance to a ship to call at a specific berth in the

port. The port authorities forward the clearances to

772

other authorities, as customs, immigration, and

health. The timing of clearance is important; some are

given prior to the port call (e.g. pre-arrival notification

and health), while others are needed prior to the start

of the operations (e.g. customs). Certain services also

need to be reported to the authorities, for instance

waste (due to MARPOL (The International

Convention for the Prevention of Pollution from Ships

(IMO))), bunkers, and vessel repairs (e.g. main

engines).

Berth and Port Departure Planning: This involves

similar information exchanges as for arrival planning.

Execution: The exchange of operational data

during the port call includes times for actual arrivals

and departures to and from port (pilot boarding place,

VTS area) and berth, and the actual start time and

completion time for vessel and cargo services

performed during the port call.

Based on Table 2, relevant ICT functionalities

related to nautical, operational, and administrative

data are summarized in Table 3. The left-most

columns list the typical functionalities that need ICT

support, while the right-most column lists typical

systems that cover the various functionalities.

Table 1 Port Call Parties from IMO FAL guideline on Electronic Signature Systems and Operational Port Data

___________________________________________________________________________________________________

Logical Party/Role Description Stakeholders (examples)

___________________________________________________________________________________________________

Authorities Party that receives information related to the port Harbour master, Customs, Immigration, Port

call and provides clearance to the ship's arrival health, Port VTIS, Coastguard

and departure

Berth planner Party that plans the berth call Terminal operator, Berth operator, Port authority,

VTIS

Hydrographic Party that provides hydrographic data and all National hydrographic office, Regional charting

service provider nautical information necessary for safe navigation agency

during passage and berthing of the vessel

Nautical service Party that provides nautical services to the ship Pilots, Tugs, Linesmen, Boatmen, VTIS

provide

Port planner Party that plans the port call port Port authority, Harbour master, Terminal

operator, VTIS, Pilots, Coast guard

Ship agent Party that represents the interests of the ship owner Ship agent

and/or charterer while the ship is at any port

Ship charterer Person or company who hires a ship from a Ship charterer

shipowner for a period of time

Ship manager Party responsible for the day-to-day management, Shore side ship manager, or other party acting on

operation and maintenance of the ship, handles behalf of the shore side ship manager: Port

authorities' reporting requirements, or other captain, Ship master or Ship agent

information requested by other parties

Ship operator Party that decides how the ship is employed and Ship charterer, Shipowner, Cargo owner/trader,

where a vessel is to call Ship manager, Carrier, Parties representing/acting

on behalf of before mentioned parties

Vessel or cargo Party that provides vessel services to the ship Vessel or Cargo service providers

service providers (bunkers, lube oil, potable water, provisions, stores,

waste per IMO/MARPOL Class, repairs vetting, flag

survey, periodic maintenance etc) or cargo services

(cargo handling, cargo lashing, cargo survey etc).

___________________________________________________________________________________________________

Table 2 Port Call Tasks for relevant parties

___________________________________________________________________________________________________

Party/Role Marketing/Contracting Planning Execution

___________________________________________________________________________________________________

Authorities Handle requests for clearance to port call,

Forward notifications and declarations to other authorities,

Forward declarations needed regarding certain services.

Berth planner Provide berth Provide berth information for voyage/passage planning,

information to berth planning of arrivals,

ship charterer provide RTA Berth to ship manager during berth planning,

Hydrographic Provide nautical charts and nautical publications for

service provider voyage/passage planning

Nautical service Plan safe and efficient port approach and port call

providers

Port planner Provide port Provide port information for voyage/passage planning,

information to Provide RTA pilot boarding place to ship manager,

ship charterer Provide RTD berth to ship manager

Ship charterer Contract for

chartering ships

Ship manager Voyage/Passage Planning (IMO Res893(A21)), Ship master notes

Provide ISPS information to berth planner and port ATA pilot boarding

planner. place in log book,

Provide ETD Berth from previous port for berth planning ATA given by AIS,

at the next port, Provide ATA Berth,

Provide ETA Berth for berth planning, Provide ATD Berth,

Accept RTA Berth (confirm PTA Berth), Provide ATD pilot

Provide ETA pilot boarding place to port planner, boarding place.

Accept RTA pilot boarding place (confirm PTA pilot

boarding place),

773

Request clearance for port call,

Report on certain services,

Order nautical services,

Order vessel and cargo services,

Set RTS of service based on ETS,

Set RTC service based on ETC service,

Provide ETD from current berth,

Confirm PTD berth

Ship operator Carriage contract, Contract for hiring terminal services, Ship owner sends

Sale of goods contract notice of readiness to

ship charterer to

confirm ATA pilot

boarding place (for

tramp shipping)

Vessel or Provide ETS for vessel or cargo services, Provide ATS service,

cargo service Confirm PTS for service, Provide ATC service

providers Provide ETC service to ship manager,

Confirm PTC service.

___________________________________________________________________________________________________

Table 3. ICT Functions for Port Calls

________________________________________________

ICT Functions Systems

________________________________________________

Nautical functions

________________________________________________

Provide nautical charts and nautical ECDIS

publications for voyage/passage planning

Plan safe and efficient port approach and ECDIS, VTIS

port call

Booking of nautical services (e.g. pilots, VTIS, PMIS,MSW

tugs, linesmen, boatmen)

________________________________________________

Operational functions

________________________________________________

Provide berth information for voyage/ PCS, TOS

passage planning,

Provide port information for voyage/ PCS, PMIS

passage planning,

Port planning at arrival (exchange ETA, PCS, PMIS

RTA, PTA for pilot boarding place)

Berth planning at arrival (exchange ETA, PCS, TOS

RTA, PTA for berth)

Berth planning at departure (exchange PCS, TOS

ETD, RTD, PTD for berth)

Port planning at departure (exchange PCS, PMIS

ETD, RTD, PTD for pilot boarding place)

Booking of vessel and cargo services PCS, TOS, PMIS

Cargo manifest: Generate import & export PCS, TOS

cargo manifest

Hazardous cargo declaration PCS, TOS

Payments and invoices PCS, PMIS

________________________________________________

Administrative functions

________________________________________________

Handle requests for ship clearance to port PCS, PMIS, MSW

call,

Report on certain vessel/cargo services PCS, PMIS, MSW

Forward notifications and declarations to PCS, PMIS, MSW

relevant authorities,

Forward declarations needed regarding PCS, PMIS, MSW

certain services.

Port state reporting/reporting to MSW PCS, PMIS, MSW

Crew/passenger reporting PCS, PMIS, MSW

Handle ISPS information PCS, PMIS, MSW

________________________________________________

4 INFORMATION MODEL

The data that is needed for the planning and

execution of a port call can be divided into Nautical

data, Administrative Data, and Operational Data [1].

4.1 Nautical Data

Nautical data is data that is provided by

Hydrographic Offices in electronic navigational charts

(ENC), nautical publications (sailing directions), coast

pilots, and tide tables [1]. They are used for safe

navigation during the port approach and also in port

basins and waterways. The challenge with nautical

data in ports is that different data sources use

different datums, which make them difficult to

compare. Also, the vessel and cargo service providers

may not use the same geographical information to

describe the location of their services, meaning that

the navigation in the port area may be unclear. [2]

gives testimonials from operational people regarding

this: In most ports the berth is not identified in the

nautical chart. Frequently, the berth is not displayed

at all, and sometimes even the port is not displayed.

Often the identification of the terminals and berths in

the ENC is different from the sailing directions or

other publications.

4.2 Administrative Data

Administrative data is data that is submitted by ships

or other non-authority parties to authorities in

notifications and declarations [1]. Administrative data

is based on legislation or regulations. This data can

normally be shared between the authorities covered

by the relevant regulations, but normally not with

others. Administrative data is typically provided by

the ship manager role to the authority role, Table 1. A

good overview of administrative data is given in the

IMO Reference Data model, based on the IMO FAL

Compendium (see Section 4.1). This reference data

model contains harmonized data elements required to

be exchanged during arrival, stay, and departure of

the ship, and includes information about crew,

passengers and cargo. This means that IMO reference

data model is an important starting point for the

implementation of the digital data exchange done

through the national single windows that will be

mandatory from January 1st 2024 as decided by IMO

FAL 46.

4.3 Operational Data

Operational data is data that is submitted to non-

authority parties as part of planning and execution of

774

certain operations during a port call [1]. Operational

data can normally not be shared with other parties.

This data is typically provided by the ship manager

role in collaboration with the port planner, berth

planner and vessel and cargo service providers. To be

able to cover the overlap between administrative and

operational data, the IMO reference data model has

been extended with data sets for operational data, that

goes beyond the IMO FAL regulations. The most

important data set is the one for just in time port calls,

covering definitions of arrival and departure times to

pilot boarding places and berths, and the starting and

completion times for vessel and cargo services. Also,

the IMO Reference data model covers the concepts of

locations in ports, namely the description of the

location for berths, terminals, pilot boarding places,

ISPS facilities, and vessel and cargo services. In this

regard, the IMO Reference model is closely related to

the IHO standard S-131, and work has begun through

the IMO group EGDH (Expert Group on Data

Harmonization) to harmonize these data elements.

5 STANDARDS FOR PORT CALL DATA

EXCHANGE

5.1 IMO Reference Model

At their 43rd Plenary meeting in April 2019, the IMO

FAL Committee approved the revised and updated

IMO Compendium on Facilitation and Electronic

Business, to support harmonization and

standardization of electronic messages for exchange of

information when ships arrive at and depart from

ports. This covers mandatory reporting formalities for

ships, cargo and persons as defined by the following

by IMO:

− All FAL standard declarations (FAL 1 to 7) as

defined in the IMO FAL Convention:

− General Declaration;

− Cargo Declaration;

− Ship's Stores Declaration;

− Crew's Effects Declaration;

− Crew List;

− Passenger List;

− Dangerous Goods Manifest;

− Security-related information as required under

SOLAS regulation XI-2/9.2.2 (ISPS)

− Advance Notification for Waste Delivery to Port

Reception Facilities; and

− WHO Maritime Declaration of Health (FAL

43/INF.3)

This is related to the mandatory requirement in the

FAL Convention saying that national governments

must introduce electronic information exchange

between ships and ports, from April 2019. In the

revised Compendium , an updated IMO Data Set

identifies and defines all data elements related to this

reporting information requirements, and the

underlying hierarchical data structure is described in

the IMO Reference Data Model.

The IMO Reference Data Model (RDM) and the

IMO Data Set give a conceptual model of the ship-

shore authority reporting requirements. This model

supports the semantic harmonization between the

various reporting requirements and relevant

international standards from various domains related

to ship-shore reporting. The IMO Data Set is mapped

to three different technical standards, namely to the

customs domain (the World Customs Organization

(WCO) data model), the trade domain (the United

Nations Economic Commission for Europe

(UNECE/UNCEFACT) Core Component library) and

the standard for electronic port clearance (ISO TC8's

28005 standard). This harmonized list of data

elements and the related reference data model,

together with the mapping to the technical standards

(WCO, UNECE and ISO 28005), support the

interoperability among maritime single window

systems.

The IMO Reference data model and data set are

maintained by IMO through EGDH . The current

compendium

was approved by IMO FAL 47 March

2023 and the following data sets has been added after

the initial version:

− Port logistic operational data related to just-in-time

concept (FAL 43/INF.3).

− Stowaways according to the FAL Convention,

Recommended Practice 4.6.2

− Ship and Company certificates according to

FAL.2/circ.131 covering requirements from IACS

Rec.75

− Acknowledgement receipts (FAL 44/7)

− Maritime Services

− Ship Registry and Company Details

− Inspections

− PCS Inspection History Data

− Maritime Reporting Scheme (MRS): All general

ship reporting requirements as defined in IMO

Resolution A.851.

− Ballast water arrival reporting

− Waste delivery receipt

− Advanced Passenger Information

− Verified Gross Mass

The just in time data set is especially important

when it comes to covering operational data and to

ensure a clear overlap between administrative,

operational and nautical data. This is needed for the

IMO RDM to be a conceptual model that can be used

across several reporting schemes and domains to

ensure interoperability among systems and improved

information exchange in addition to reduced

administrative burden for maritime transport

stakeholders. More data sets are to be included, for

instance for ship particulars (IMO Safety information),

for noon reporting, and others. Note that the IMO

RDM is not a new standard but rather a tool to

harmonize existing standards across various domains

and systems.

5.2 ISO 28005 on Electronic Port Clearance

The ISO 28005-series of standards maintained by

ISO/TC8/SC11/WG2 Maritime operational data model

contains data elements to cover the requirements for

ship-to-shore and shore-to-ship reporting of authority

information as defined in the following:

− Most required information sets as defined in the

FAL Convention to be sent at arrival or departure:

− General Declaration (FAL Form 1)

− Cargo Declaration (FAL Form 2)

− Ship’s Stores Declaration (FAL Form 3)

− Crew’s Effects Declaration (FAL Form 4)

775

− Crew List (FAL Form 5)

− Passenger List (FAL Form 6)

− Dangerous Goods Manifest (FAL Form 7)

− The document required under the Universal Postal

Convention for mail (a reference to the physical or

electronic document)

− Maritime Declaration of Health as based on the

Maritime Declaration of Health (MDH) from

WHO, 58th World Health Assembly, WHA58.3.

− Security-related information as required under

SOLAS regulation XI-2/9.2.2 (ISPS code).

− Advanced electronic cargo information for

customs risk assessment purposes

− Advanced Notification Form for Waste Delivery to

Port Reception Facilities, based on the

recommended reporting on ship-generated waste

as defined in MEPC 644, which is mandatory

within the European Union, as described in

EU/2000/59.

− Required reporting as defined in the bulk loading

and unloading code IMO Resolution A.862.

− Mandatory ship reporting system (MRS)

requirements as defined in IMO Resolution A.851.

− ETA reporting to pilot station as defined in IMO

Resolution A.960.

− All data sets contained in the IMO Reference Data

Model

The information is described as XML types in an

XSD and also as classes in UML diagrams. The ISO

28005 standard (Part 1) describes messages and the

protocol for how to exchange these different

messages, including clearance, update, cancellation,

receipt and acknowledgement messages. The ISO

28005 series of standards was first defined in 2011

with a second version in 2021. This version contains a

mapping to the IMO Reference Data Model and cover

all data elements as approved by IMO in FAL 44 in

Sept/Oct 2020 . An updated version of Part 1 plus a

new Part 3 covering the remaining data sets contained

in the IMO Reference Data Model up till FAL47 are

due in 2023.

5.3 IHO S-131 Standard

IHO is developing the S-131 Marine Harbour

Infrastructure product specification together with the

International Harbour Master Association (IHMA).

Some of the data elements for berth, berth position

and terminal have commonalities with the IMO FAL

Compendium:

− Berth: terminal ID and port facility Number and

port facility LOCODE (for ISPS) are common.

− Berth Position is described by: Port facility number

and port facility LOCODE (for ISPS)

− Terminal is described by: Port Facility Number,

Port Facility LOCODE, Terminal ID.

6 PORT CALL ICT SYSTEMS

The IMO FAL correspondence group on developing

Guidelines on Electronic Signature Systems and

Operational Port Data for the Purpose of Digital

Information Exchange [1] mentions the following ICT

systems as playing an important role during a port

call, see Figure 3. This section will further describe

these systems.

Figure 3. ICT Systems Overview for Port Calls [from [4]]

Table 4 lists typical users for various port ICT

systems.

Table 4. Users for Port ICT Systems

________________________________________________

ICT System Users

________________________________________________

Port Community Systems Ship Manager, Other systems

(PCS) (TOS, VTIS, PMIS, MSW, SPS,

SPSWS)

Terminal Operating Berth planner

Systems (TOS)

VTS Information Systems Nautical service provider, VTS

(VTIS) Operators, Coast state

authorities

Electronic Chart Display Ship crew, Hydrographic

Information System service provider

(ECDIS)

Port Management Port planner, Port Authority,

Information Systems (PMIS) Vessel and cargo service

provider, Harbour master,

MSW, berth planner

Voyage Planning Systems Ship manager, Ship crew

Maritime Single Window Port State Authorities

(MSW)

Service Provider Systems Vessel and cargo service

(SPS) provider

Ship Principal Software Ship Manager

Systems (SPSWS)

________________________________________________

6.1 Port Community Systems (PCS)

A Port Community System (PCS) is an ICT system

used to facilitate communication, coordination, and

collaboration among all parties involved in port and

logistics operations during a port call, typically with

the following functionalities:

− Provide real-time data on vessel movements and

cargo status,

− Automate administrative processes, such as

document processing, invoicing, and payment,

− Track cargo movements,

− Ensure regulatory compliance.

Figure 3 shows that a PCS can be viewed as the

portal to all the different ICT systems in the port. The

user of the PCS is then the ship manager role. For

ports that do not have a PCS, the port users will access

each of the different ICT systems in the port directly.

To generalise this, the term "PCS" can be used as a

generic name for an ICT system in the port [1].

Several different types of PCSs exist, from small to

large systems, from systems covering only port

operation to systems also operating as a national

MSW. The IMO FAL committee (FAL 48 in 2024) is

working on guidance for PCS especially to be able to

draw the line and responsibilities between PCSs and

776

MSWs, and at the same time ensure the reporting only

once principle related to the port call. In the IMO

MSW guidelines, it is opened up for MSWs to extend

beyond authority reporting: MSW should be

considered as a technology neutral and trustworthy

platform for public private data collaboration to

expand its scope beyond regulatory framework to

include nautical and operational information and data

as a best practice for trade agnostic port call

automation [4].

IPCSA (International Port Community Systems

Association) defines PCS as follows [5]: A Port

Community System Is a neutral and open electronic

platform enabling intelligent and secure exchange of

information between public and private stakeholders

in order to improve the efficiency and competitive

position of the sea and airports’ communities. A PCS

optimises, manages and automates smooth port and

logistics processes through a single submission of

data and by connecting transport and logistics chains.

[6] describes PCS as "an electronic platform that

connects the multiple systems operated by a variety of

organisations that make up a seaport or airport

community. It is shared in the sense that it is set up,

organised and used by firms in the same sector – in

this case, a port community. A good collaboration

between all the parties involved is one of the success

factors of a PCS. Distinctive for all PCSs is the link to

Customs and port authorities and other institutions

such as veterinary offices or coastguard, for example."

The most important users of a PCS are typically

shipping lines and freight forwarders, but cargo

importers and exporters in general, and customs and

shipping agents are important users. Typical

functionalities of PCSs are [6]:

− Customs declarations

− Electronic handling of all information regarding

import and export of containerised, general and

bulk cargo

− Status information and control, tracking and

tracing through the whole logistics chain

− Processing of dangerous goods

− Processing of maritime and other statistics

[7] also recognizes the role that a PCS can have as

being a National Single Window (MSW) or as a

system that are integrated into a National Single

Window, for instance as a Safe Sea Net-node .

[6] recognizes that (national) single window

systems cover the information flow G2G and G2B,

while business to business data flow is covered by the

PCS.

[6] describes the relation between a PCS and a

national Single Window system as the following: A

PCS can work as a portal or gateway to a national

single window or can be an integral part of a single

window. Other possibilities are a simple information

flow from the national single window to the PCS, for

instance regarding notification of port calls. As the

port calls may often be known to the PCS before it is

known to the national single window, this

information flow may also be the other way, from

PCS to the NSW. Further, PCSs can support B2B

information exchange as well as being a portal for

B2G information exchange.

6.2 Terminal Operating Systems (TOS)

A Terminal Operating System (TOS) is an ICT system

that manages and controls the operations of a

maritime terminal to optimize the use of resources

(berths, cranes, yard equipment) to ensure that vessels

are loaded and unloaded efficiently, including:

− Vessel planning and scheduling, including berth

and crane allocations,

− Coordinating the movement of containers, cargo,

and equipment,

− Create discharge and loading lists, often based on

EDI messages received from third party

stakeholders, that is, from cargo owners or

forwarders or cargo agents,

− Yard space and equipment (cranes, trucks etc)

planning,

− Real-time data on cargo, containers, and

equipment,

− Manage container inventories,

− Tracking the movement of containers.

Several ICT systems are used to support the

operations of a terminal. One of the most important is

a Terminal Operation System (TOS). The TOS

provides visibility, control, optimization, scheduling,

planning, analytics, and automated handling of

maritime containers, rail containers, and break bulk

for terminal operations. The terminal is a trans-

shipment point for the cargo, meaning that the cargo

will switch to a different transport mode or will be

consolidated. A TOS should support the main

transactions in the trans-shipment between sea and

hinterland transport, namely loading and discharge of

cargo to and from a ship and gate-in/gate-out to/from

land-based transport. Keeping track of carrier

equipment, e.g. multimodal containers, and cargo is

essential for efficient processing of cargo. A TOS

typically enables management and operators to

administrate containers and cargo positions on the

terminal yard.

An example of a TOS is Terminal by Grieg

Connect, which enables the operation manager to

create discharge and loading lists based on EDIs

received from third party stakeholders, that is, from

cargo owners or forwarders or cargo agents. Further,

the yard state is managed in Terminal through

internal cargo transactions, termed as moves within

the system. An internal move transaction represents a

positional change from one position in the yard to

another. There may be multiple ways of modelling

positions within a yard, either by modelling a position

in a grid-like system where each cell denotes a stack

of containers of a certain size or by exact positioning

through geo-spatial data.

There are also other relevant internal transactions

that may be managed in a TOS, such as stuffing and

stripping carrier equipment. Stuffing involves filling

the container with cargo and stripping the reverse

operation, taking cargo out.

A TOS typically enables external stakeholders,

such as the container owner or the container leaser, to

order actions on a container through EDI interchange.

This may be ordering the terminal to release an empty

container from a terminal depot to be picked up by

transport or ordering stuffing of a certain container.

777

6.2.1 Plan cargo operations

The terminal needs to plan and execute operations

related to cargo transactions, for instance planning a

discharge or loading operation from/to a ship to/from

the terminal yard. This involves exchanging data with

the ship manager regarding how the cargo is stowed

(bay plan/stowage plan), instructions on equipment

needed to do the discharging/loading, and

instructions on the discharge/loading order.

6.2.2 Users

The main user groups for the core TOS

functionality related to cargo movements, cargo

management and cargo operations are the terminal

management fulfilling the Cargo service provider

role.

6.2.3 Integration with and interfaces to other systems

In general, integration with third party systems

from stakeholders such as the shipping company or

customs is done either through EDI interchange or

public API-based interaction. The synchronisation of

data related to container transactions are mainly

based on EDI messages according to UN/EDIFACT

container message standards maintained and issued

by International Transport Implementation

Guidelines Group (ITIGG).

6.2.4 Customs

Although the UN/EDIFACT container messages

support EDI interchange of customs-related

information through the CUSCAR format, some

governments also provide self-service systems and/or

service-oriented solutions/integration points for usage

in the customs clearance process. An example from

Norway is the TVINN self-service system.

6.2.5 General purpose container transaction and tracking

systems

In 2018, Maersk partnered with IBM to create

TradeLens, a platform for sharing and streamlining

shipping information across shipping partners,

businesses, and different authorities . TradeLens is an

example of a system developed by two major global

corporations as a tool to support and centralise data

related to global sea freight cargo supply chain

transactions. By 2019, the platform covered nearly half

of the world’s shipments of cargo containers.

6.3 VTS Information Systems (VTIS)

A VTS (Vessel Traffic Service) Information System is

an ICT system used to monitor and manage vessel

traffic in a specific area, such as a port, harbour, or

waterway, including the following tasks:

− provide real-time information on vessel positions,

movements, and headings.

− Providing navigational assistance to vessels,

including information on hazards, and weather

− Coordinating vessel traffic, including vessel

routing and allocation of anchorages and berths.

− Responding to emergency situations, such as

search and rescue operations, and coordinating

with other emergency services.

− Collecting and sharing data on vessel movements

and incidents with other stakeholders, including

port authorities, shipping companies, and

government agencies.

− Managing communication between vessels, port

authorities, and other stakeholders, using various

communication channels, such as VHF radio,

email, and satellite.

6.4 Port Management Information Systems (PMIS)

A Port Management Information System (PMIS) is an

ICT system used to manage and optimize the

operations of a port or terminal, including tasks as:

− Managing and tracking the movement of cargo,

vessels, and other resources

− Managing and monitoring the use of

infrastructure, such as berths, cranes, and yard

equipment

− Providing real-time data on the status of cargo,

vessels, and other resources

− Invoicing, billing, and resource allocation.

An example of a PMIS is Port, which is developed

by Grieg Connect for efficient planning and

management of port calls and the related services and

cargo. During port call execution, the plan is adjusted

when changes occur. The execution process consists of

the different activities involved in serving the ship in

port while in the completion phase, port call relevant

information is collected before the port call is

invoiced. The users of Port typically have the port

planner role, when planning the port calls and related

services, and doing invoicing afterwards, or they can

also have the role of a vessel or cargo service provider

both when handling service delivery and collecting

data that is relevant for invoicing and documentation

purposes.

6.4.1 Planning

In the planning phase, information about port calls

is received from logistics providers and agents either

through the maritime single window (MSW) or by

email and telephone. SafeSeaNet Norway (SSN) is the

MSW system developed by The Norwegian Coastal

Administration for reporting and distribution of all

relevant information regarding shipping to

Norwegian authorities

(https://www.kystverket.no/en/sea-transport-and-

ports/safeseanet-norway/). Port has also integration

with a corresponding solution (Portnet) for Finish

ports. The deadline for reporting in SSN is 24 hours

prior to arrival and ships less than 300 gross ton is

exempted from reporting. Some port calls are

therefore manually entered in the port system. Port

receives port call information from the MSW

including ship information, ETA, ETD, preferred

quay, arrival draught, crew, passenger data, and

requested services. The port planner in the port

system processes the requests and check for available

capacity.

778

6.4.2 Berth planning

Port contains a berth planning tool that gives the

berth planner a good overview of the quay

assignments both in a Gantt-view and on a map with

detailed positions, which is used by the planner to

check for available capacities at the quays. If there is

sufficient capacity and the ship satisfies the ISPS-

requirements, the berth planner approves the request

in Port and an acceptance message is automatically

sent back to the MSW. The planner can also propose a

different quay than requested or reject the request if

there is no available capacity.

6.5 Maritime Single Window (MSW)

6.5.1 Background

A Single Window (SW) system is defined in the

UN/CEFACT Recommendation 33 as "a facility that

allows parties involved in trade and transport to

lodge standardized information and documents with

a single-entry point to fulfil all import, export, and

transit-related regulatory requirements. If information

is electronic, then individual data elements should

only be submitted once". [6]

Usually, Single Window systems for maritime

applications (MSW) cover both private and public

information exchange. The other distinction between

MSWs is whether they cover both nautical

information and cargo/trade information. For

implementation of these standards, the IMO has

developed guidelines for setting up a maritime single

window in FAL 5/Circ. 42, 16 May 2019.

6.5.2 MSW Regulations from IMO

IMO, during FAL 46 in May 2022, decided that the

amendments to the IMO Facilitation (FAL)

Convention should enter into force from 1st of

January 2024. These amendments require signatories

to the Convention to implement an electronic

maritime single window for all declarations made by

a ship in conjunction with international port calls.

Also, FAL 45 approved the revised Guidelines for

setting up a maritime single window

(FAL.5/Circ.42/Rev.1) to ensure a common

understanding of the machine-to-machine

communication related to ship calls. The IMO

Reference Model (Section 4.1) describes the

information exchange related to this MSW.

6.5.3 EMSWe

The EMSWe (European Maritime Single Window

environment) is the legal and technical framework for

the electronic transmission of information about

reporting obligations for ships calling at EU ports. It is

a network of national MSWs using the SafeSeaNet

systems and other systems. The data model is aligned

with the IMO Reference Model with additional data

sets for local legislations.

6.6 Ship Side Systems

The ship side systems include ECDIS, Voyage

Planning Systems, and Ship Principal Software

Systems. Onboard systems are used by the ship crew,

on shore systems are used by a stakeholder having the

ship manager role.

6.6.1 ECDIS

An Electronic Chart Display and Information

System (ECDIS) is an onboard navigation system

ships to display navigational information from

electronic navigational charts (ENCs) and to assist in

route planning and navigation. ECDIS currently

follows The ECDIS performance standard states that

from 2029, new ECDIS systems must follow the new

S-101 standard contained in the S-100 framework,

instead of the old S-57. This will also introduce the

possibility to add several layers of information,

including the S-421 standard for route exchange, S-131

for marine harbour infrastructure and other

standards. This also highlights the importance of

aligning the IMO Reference model with the S-100

framework, especially the GI (Geographical

Information) concept register.

6.6.2 Voyage Planning Systems

A Voyage Planning System (VPS) is an ICT system

used by ship operators and navigators to plan and

optimize a vessel's route for a particular voyage. An

example of this is the NavStation by Navtor.

7 MARITIME INTELLIGENT TRANSPORT

SYSTEMS (ITS) ARCHITECTURE

7.1.1 MITS Architecture

A Maritime Intelligent Transport System (ITS)

Architecture can be based on the definitions of roles,

functions and systems as described in this paper. In

addition to this comes the description of the

connection between Road ITS and Maritime ITS, and

also how the Maritime ITS architecture relates to e-

Navigation functionalities, Figure 4.

Figure 4. Maritime ITS Big Picture

7.1.2 Players in International Standardization

IMO is an important player in the standardization

work as it maintains the IMO Reference Data Model

779

through its Expert Group on Data Harmonization

(EGDH) in the Facilitation committee (FAL). Also

important is the agreement between IMO, ISO,

UN/ECE and WCO on the maintenance of the IMO

Reference Data Model and the updating of the

mappings from the reference model to the three

technical standards maintained by ISO, WCO, and

UN/ECE. Further, IHO is important as they are

responsible for the S-100 framework of standards, and

they have also started harmonization with the IMO

Reference Data Model. Also, several organizations are

active in giving input on new and updated data sets

to the IMO Reference Data model, for instance

BIMCO, which is the world's largest direct-

membership organisation for shipowners, charterers,

shipbrokers and agents, IAPH (International

Association of Ports and Harbours), ITPCO

(International Task Force on Port Call Optimization),

IPCSA (International Port Community Systems

Association) and DCSA (Digital Container Shipping

Association).

8 CONCLUSIONS

Harmonization of data sets are important for those

parts that are overlapping between several domains,

that is, between the nautical, administrative, and

operational domains. As an example, when referring

to arrival and departure times for a ship to a berth (in

the operational domain), the same references should

be used for administrative data: If the terminal plans

for a ship to arrive at a berth at a certain time, that

same time is equally important for both port

authorities and port operational parties, for instance

vessel service providers (e.g. pilots, bunker barges).

To achieve interoperability between ships and

shore ICT systems, not only the introduction and

usage of standards covering the data requirements are

needed, but also more technical standards for the

machine-to-machine interaction, for instance defining

Application Programming Interfaces (API) and other

common reporting protocols covering electronic data

exchange. However, neither the IMO FAL Convention

nor the IMO guidelines for setting up a maritime

single window specify specific technical standards for

the interface between ships and the MSW. This means

that a technical specification of the ship-shore

communication related to port call must be specified,

which is what is done for instance in the ISO 28805

standard on Electronic Port Clearance.

ACKNOWLEDGEMENTS

This work has been performed as part of the ISTS (funded

by the Research Council of Norway under project number

326679) and AEGIS (funded by the European Union’s

Horizon 2020 research and innovation program under Grant

Agreements 859992) projects.

REFERENCES

[1] Ichimura, Y., Dalaklis, D., Kitada, M., & Christodoulou,

A. (2022). Shipping in the era of digitalization: Mapping

the future strategic plans of major maritime commercial

actors. Digital Business, 2(1), 100022.

[2] Rødseth Ø.J. Towards Shipping 4.0, Smart Ship

Technology, Royal Institution of Naval Architects,

January 2017, London UK.

[3] H Hagaseth, M., Juhl, J. S., Rødseth, Ø. J., van

Scherpenzeel, B., & van der Wurff, A. M. (2022, July).

Ship-Shore Interaction: The Model in the Middle. In

Journal of Physics: Conference Series (Vol. 2311, No. 1, p.

012008). IOP Publishing.

[4] IMO FAL.5/Circ.52, Guidelines for harmonized

communication and electronic exchange of operational

data for port calls, March 31. 2023.

[5] ISO 28005 Ships and marine technology — Electronic

port clearance (EPC) – All parts.

[6] IHO S-131 Marine Harbour Infrastructure Product

Specification (draft for approval 2023).

[7] Intelligent Ship Transport System, Norwegian R&D

project, http://ists.mits-forum.org/ Accessed May 2023,

[Online].

[8] Britton, C., & Bye, P. (2004). IT architectures and

middleware: strategies for building large, integrated

systems. Pearson Education.

[9] Rødseth, Ø. J. (2011, October). A maritime ITS

architecture for e-navigation and e-maritime: Supporting

environment friendly ship transport. In 2011 14th

International IEEE Conference on Intelligent

Transportation Systems (ITSC) (pp. 1156-1161). IEEE.

[10] IMO FAL 47/9, “Consideration of descriptions of

maritime services in the context of e-navigation -

development of guidelines for harmonized

communication and electronic exchange of operational

data for port calls.”

[11] International Taskforce on Port Call Optimization,

“PORT INFORMATION MANUAL For ship-port

interface data Version 3.01.”

[12] International Taskforce on Port Call Optimization,

“Appendix to Port Call Process.” Apr. 06, 2020.

Accessed: Mar. 23, 2023. [Online]. Available:

https://portcalloptimization.org/images/Business%20pro

cess%20appendix%20200406.pdf

[13] IMO, FAL.5/Circ.42/Rev.2, “GUIDELINES FOR

SETTING UP A MARITIME SINGLE WINDOW.” Jun.

08, 2022.

[14] International Port Community Systems Association,

“Port Community Systems – General.” [Online].

Available: https://ipcsa.international/pcs/pcs-general/

[15] EPCSA, “The role of Port Community Systems in the

development of Single Windos.” Accessed: Mar. 10,

2023. [Online]. Available:

https://tfig.unece.org/pdf_files/A9R149C.pdf

[16] EPCSA, “How to develop a Port Community System.”

Accessed: Mar. 10, 2023. [Online]. Available:

https://tfig.unece.org/pdf_files/A9R149D.pdf

[17] Nesheim, D.A., Rødseth, Ø.J., Bernsmed, K., Meland,

P.H.: "Secure, Trustworthy and Efficient Information

Exchange -Enabling Added Value through The Maritime

Data Space and Public Key Infrastructure", Book

chapter, 2021.