International Journal

on Marine Navigation

and Safety of Sea Transportation

Volume 5

Number 3

September 2011

401

1 INTRODUCTION

The one stop shop business model has been exhaust-

ively researched and applied in the context of e-

business and e-government service provision over

the last decade (Wimmer, 2002; Lambrou et al.,

2008). In a similar vein, in the trade, transport and

shipping sector, the “Single Window” (SW) concept

was formalized by the United Nations Centre for

Trade Facilitation and Electronic Business

(UN/CEFACT 2005) to enhance the efficient ex-

change of information between trade and govern-

ment agencies. The Single Window concept has its

origin in the Trade Facilitation and Customs field

focusing upon efficient import and export institu-

tions and mechanisms, where declarations of goods

related to regulatory information must be reported in

cross border activities.

A SW primarily addresses the need for efficient

and collaborative electronic transactions between

governmental and business entities; however the co-

coordinating SW authority and the core functionality

may differ, thus we typically observe a customs-

centric, import and export oriented approach, a port

and ship oriented (maritime focus), and a safety and

security centric approach. In both cases pertinent

SW service design aspects include the SW owner-

ship model (public, private or public-private partner-

ship - PPP), and the SW cost model (e.g., free use,

membership or transaction fee). The organizational

level of the SW competent authority, e.g., interna-

tional, national, regional, or local is an important dif-

ferentiating factor, as well. Often, vested interests

and policy choices dictate the dominance of one

model implementation over the other.

In this paper we discuss different types of single

window systems and enabling development method-

ologies and platforms, focusing in particular on a

maritime centric model where ship clearance, cargo

import/export, and port clearance services are sup-

ported. This means that we extend the Single Win-

dow Concept to conver not only regulatory infor-

Maritime Transport Single Windows: Issues

and Prospects

K. E. Fjortoft, M. Hagaseth

MARINTEK-SINTEF, Norwegian Marine Technology Research Institute

M. A. Lambrou

University of the Aegean, Department of Shipping, Trade and Transport, Chios, Greece

P. Baltzersen

Wilhelmsen IT Services, Norway

ABSTRACT: In the trade, transport and shipping sector, the Single Window (SW) concept has been evolved

over time in a number of forms, reflecting respective policy, regulatory, market and technological regimes of

the domain. A SW primarily addresses the need for efficient electronic transactions between governmental

and business entities; however the SW service model adopted by the responsible authority and the offered SW

system functionality differ; currently at least two distinct approaches are observed, namely a customs-centric

SW approach, and a maritime and port centric approach. In all respective cases, the SW service model, the

SW ownership model (public, private or Private-Public-Partnership), legal and regulatory aspects and the SW

revenue model (free or with a fee) consist pertinent SW service design issues. Thus, different types of SW

systems evolve in terms of offered service bundle, namely ship clearance, cargo import/export, or port clear-

ance SWs, where often vested interests and policy choices dictate the dominance of one model implementa-

tion over the other. Modern ICT tools may significantly help to organize and improve the efficiency of a SW

design and implementation process. In this paper, admissible development frameworks and methodologies are

examined towards the efficient implementation of SW service models that are explained. Our analysis is

based on experiences gained in the Norwegian SW national initiative (http://www.sintef.no/Projectweb/MIS/)

and the EU eFreight project (http://www.efreightproject.eu/).

402

mation, but also other information related to mari-

time transport.

2 A TAXONOMY OF SINGLE WINDOW

SYSTEMS

There are different reference models of existing and

emerging SW systems supporting intermodal

transport activities, as explained in Table 1. A SW

system can cover the cargo reporting activities

where import and export declarations are the main

processes supported, another SW model is organized

around ship or vessel clearance activities offered by

national governments, whereas a third model is a

port clearance oriented SW. The purpose of a ship

oriented SW is to support all mandatory information

reporting concerning a ship sailing from abroad to a

EU or associated country, as based on the

SafeSeaNet (SSN) system notifications and formali-

ties.

All countries in EU and Associated countries are

connected or will soon be connected to the central

SSN system. Every country has to dedicate an inter-

nal authority as a National Competent Authority that

will be the official connection between the country

and the central SSN system that is under the respon-

sibility of the European Maritime Safety Agency,

EMSA.

A Port Single Window (PSW) can in many cases be

defined as a Port Community System (PCS). It is a

community system which based on an integrated se-

ries of procedures, rules, standards and ICT solu-

tions supports the automatic exchange of data and

documents related to the port authorities’ clearance

of ships and cargo upon arrival, stay and departure

of vessels.

A PSW is primarily supporting the requirements of

governmental agencies, but also the requirements of

the cargo parties’ interests. So a PSW covers Cus-

toms requirements and document handling, and the

information exchange dealing with the necessary

services in a port and the handling of ship and cargo.

It is also likely that a PSW will have a stronger focus

upon private information and more commercial ori-

ented regarding sale and ordering of port services

than the one for ship clearance.

Figure 1. Single Window Taxonomy

EPC (Electronic Port Clearance) is the concept

used to refer to vessels visiting a port and their elec-

tronically (without the use of paper documents) deal-

ing with all formalities, documentary requirements

and procedures associated with the arrival, stay and

departure of ships engaged on international voyages.

On the one hand, EPC aims to replace the paper

documents such as the FAL Forms currently in use;

on the other hand EPC tries to make the exchange of

information more efficient, through the rationaliza-

tion of the procedures and simplifying the related

data. Figure 1 gives an overview of the three dimen-

sions of Single Window systems and how each of

them relates to each of the actors. Note that the ac-

tors Ship Owner and Charterer only interacts with

the Single Window through other systems, not as

separate actors. The actor Other Port Parties/ 3

Party Systems includes parties involved in the port

business other than the port authorities, for instance

systems to handle resource bookings.

One of the challenges in the specification of SW

system is to decide the dimensions and geographical

areas the SW system should cover.

Examples of such dimensions are:

− International dimension

− National dimension

− Regional dimension

− Local dimension

Another dimension could be an Ad-hoc solution.

uc Use Case Model

Cargo Clearance Single Window

Port Clearance Single Window

Ship Clearance Single Window

Customs

Other

Import/Export

Authority

Other National Authorities

SafeSeaNet

Ship Agent

Ship and Ship

Systems

Cargo Agent

Other Port Parties/3rd

Party Systems

Ship Ow ner

Charterer

403

Table 1. Types of Single Window

For all those dimensions there are different needs

and a different legal basis to follow that also differs

within one dimension. An example can be that with-

in a port, which is defined as a local dimension solu-

tion, there are some port specific regulations to fol-

low regarding mandatory reporting and the

configuration of the SW must therefore follow the

properties defined at the port where also the private-

public partnership relations must be placed, Fig-

ure 2. This means that a Single Window system for

one port may differ in several respects to a Single

Window system in an adjacent port.

It is likely that the different systems that represent

the different solutions must exchange information

with each other. A ship normally crossing the de-

fined dimensions where coming from an abroad

country and visiting a port, is mirroring the process

when returning to an abroad port. In such a case, the

ship must first follow the local dimension from de-

parture port, where regulations and other procedures

are followed (reporting time, place, etc). Then, in

some cases, new reporting and procedures must be

followed when sailing in a certain region such as a

fjord or vulnerable regional areas. Then, when the

ship is leaving the national waters, information must

be reported to the NCA (National Coastal Authori-

ties) or the Coast Guard of the departure nationality,

and finally follows international conventions in open

international waters. The same approach will be rel-

evant when sailing into the arriving port.

Figure 2. Geographical dimensions of SW

3 DEVELOPMENT METHODOLOGIES FOR

SINGLE WINDOW SYSTEMS

Several methodologies relevant for the development

of Single Window systems can be exploited. A

number of available methodologies focus on the

analysis and design phase using various process

modeling techniques, while other methodologies are

related to the technical implementation of a SW sys-

tem (e.g. SoaML).

3.1 Zachman Framework

The Zachman framework (Zachman, 1997) was first

presented in 1987 and has since then evolved in sev-

eral directions and several versions. For maritime

Single Window development, it is most relevant to

view it as a taxonomy for organizing architectural

artifacts, design documents, specifications and mod-

els. The framework addresses the question of who is

the target for the description and also what is de-

scribed, for instance data and functionality. In this

sense, the Zachman Framework is not a methodolo-

gy since it lacks methods and processes for collect-

ing the information, and also for managing or using

the information. Rather, Zachman describes the

framework for enterprise architecture as follows:

“The Framework as it applies to Enterprises is

simply a logical structure for classifying and organ-

izing the descriptive representations of an Enter-

prise that are significant to the management of the

Enterprise as well as to the development of the En-

terprise’s systems.” A key point in the Zachman

framework is that the same complex item can be de-

Description

A SW for customs clearance normally contains information about cargo

for either import or export.

Users

The users are Consignor’s and Consignee’s, the Customs, as well as cargo

agents

Characteristics

The goods to be defined for import and export will need a release number

before the transport can progress from an import area at a terminal. A

main functionality for this SW is the cargo clearance process.

Objects

Cargo information and definition, Ownership, The itinerary of the goods,

Handling instructions, General statusinformation about the cargo

Functionality

Registers: Goods group, Location register, Tax code

Automation: XML and Web-based user interface

Accessibility control

Hand-over mechanism with other SW-solutions

Description

A SW for Ship clearance contains information about the ship, the voyage,

the cargo, the passengers, the crew and information that is required by the

SafeSeaNet directive.

Users

The users are the ship it self, agents, the providers on the ship, or the

governmental bodies that need statuses and information for controlling

duties, for mainly safety/security purposes. Governmental bodies can be

Police, Coast Guard, Navy, Coastal Administration, Health authorities, or

the ports.

Characteristics

The main purpose of such a SW is to have a good overview of the safety

and security issues regarding sea transport. It could be either a site where

information about a ship transport could be achieved in a distressed

situation, or it could be more used in a controlling purpose where i.e. the

crew and passenger list is matched with the list of criminals by the Police

authorities. A main functionality for this SW is the ship clearance process.

Objects

Ship information, Cargo information, Crew and Passenger information

(also effects), voyage information. Notification messages (hazmat,

security, alert, ship) between the different states should also be considered

Functionality

Registers: Goods group, Vessel, Location

Automation: XML and Web-based user interface (both ways)

Acceptance report/Clearance notification (automatic)

Use of sensor data for report purpose

Ordering of transport services such as pilot age services

Hand-over mechanism with other SW-solutions as well as commercial

systems from service providers

Description

A SW for port clearance is a reporting site for needed information

regarding an entrance to a port. The information could also be about

information classified as private, and used within a commercial aspect.

Users

The ship, the ship operators, the agents, the port management, the port

service providers

Characteristics

This SW is used to achieve a port clearance of a ship. The information is

both of a private and a public character. The ports are using the

information to plan the ship entrance, to achieve the port safety and

security regulations, and to calculate the fees to be sent to the users. A

main functionality for this SW is the port clearance process.

Objects Ship, Cargo, Load units, Service needs, Security information

Functionality

Registers: Goods group, Vessel, Location, Port services. XML and Web-

based user interface (both ways). Acceptance report/Clearance

notification (automatic), Use of sensor data for report purpose, Safety and

security,

Ordering of port services, Accessibility control, Hand-over

mechanism/communication mechanisms with other SW-solutions as well

as commercial systems from service providers, Statistics, General port

information, Site for laws and regulations.

Single Window for cargo

Single Window for ship clearance

Single Window for port clearance

National

Region

Local

port

Pre-notification Post-notification

Updates

404

scribed for different purposes in different ways using

different types of descriptions.

The framework has 36 categories for completely

describing anything related to the enterprise, orga-

nized with six columns and six rows. Each row rep-

resents a total, distinct and unique view of the solu-

tion from a particular perspective. Each column

represents a category of the enterprise architecture

component, called focus. These are data description

(what), function description (how), network descrip-

tion (where), people description (who), time descrip-

tion (when), and motivation description (why).

Some aspects of the Zachman framework that are

convenient for analyzing SW systems include:

1 Analysis of several organizations that have to co-

operate in an interoperable SW system:

A SW is an environment which has to support in-

teroperability among highly heterogeneous envi-

ronments. This means that a structured way to

present the analysis of the organizations with dif-

ferent viewpoints is important. The Zachman

Framework for systematically describing changes

to an organization based on various viewpoints

and various abstraction levels is very useful in the

analysis phase of a SW development.

2 Clarification of different views of the same arti-

fact:

The Zachman Framework focuses on different

views of the same artifact (process, data), which

is important in a SW system covering processes

and data originating from various applications,

both cargo, port, and ship clearance, but also orig-

inating from both public and private organiza-

tions.

3 Presentation of analysis results throughout several

organizations:

The Zachman Framework can be useful to present

the analysis of a SW system. Important here is the

fact that new third party systems that want to col-

laborate with the SW may have easier access to

the taxonomy of the SW.

Some aspects of the Zachman framework that are

missing for SW systems:

1 Lack of a structured methodology:

The Zachman Framework does not include a

methodology per se, however, a methodology is

needed for the Single Window design and imple-

mentation process, for instance for describing

how to integrate a third party system with the

Single Window, and how to handle and share data

that is specific for the third party systems.

2 Description of both the SW and the third party

systems are needed:

The Zachman framework seems to focus on the

description of a single enterprise, however, when

designing a SW system, we have to consider sev-

eral organizations and environments as a whole.

This is because each service provider and service

user may represent distinct organizations with

their own Zachman matrix related to Single Win-

dow. What is needed, is a Zachman Framwork

analysis of the Single Window itself, but in addi-

tion, we would need to have descriptions of the

third party organizations, at least the parts that are

most relevant for the Single Window system.

3.2 CIMOSA

CIMOSA (Computer Integrated Manufacturing

Open System Architecture) is an enterprise model-

ing framework, which aims to support the enterprise

integration of machines, computers and people. The

framework is based on the system life cycle concept,

and offers a modeling language, methodology and

supporting technology to support these goals. Three

dimensions of CIMOSA are outlined (Zue-

songdham, 2009):

1 The generic dimension (Instantiation of Building

Blocks) is concerned with the degree of particu-

larisation. This dimension differentiates between

Reference Architecture and Particular Architec-

ture.

Reference Architecture resembles a catalogue of

reusable building blocks which contains generic

and partial building blocks applicable to specific

needs.

Particular Architecture serves the use of a specific

case in process modelling which is not intended

to be reusable for other models.

2 The modelling dimension (Derivation of Models)

provides the modelling support for the system or

work life cycle starting from requirements to im-

plementation.

3 The view dimension (Generation of Views) offers

the users to work with partial models representing

different aspects of the enterprises: function, in-

formation, resource and organisation with the op-

tion for other views to be defined as needed.

Advantages of CIMOSA:

1 Strong inter-organizational process modeling:

The CIMOSA is strong on modeling complex or-

ganizations and has constructions to model dif-

ferent views of the same things in an organiza-

tion.

2 Use of reference architecture:

The reference architecture can be used to build up

an library of Single Window concepts which may

be useful when new third party systems are to

connect to a Single Window. Then, reuse of

common descriptions and concepts may be facili-

tated through the use of CIMOSA.

3 Focus on common understanding of terms:

CIMOSA has focus on defining a glossary for

common understanding of terms and definitions.

405

Problems with using CIMOSA:

1 Process descriptions separate from implementa-

tion aspects:

CIMOSA does not cover the technical implemen-

tation phase, for instance related to ICT architec-

ture or software services. However, attempts have

been made to extend this framework (Zue-

songdham, 2009)

2 Complex framework:

The framework may look complex, since it has a

three dimensional matrices describing the model-

ing framework.

3.3 SOA and SoaML

SOA (Service Oriented Architecture) is an architec-

tural paradigm whose goal is to achieve loose cou-

pling among a collection of interacting software ser-

vices. Services are usually defined as autonomous,

platform-independent computational elements that

can be described, published, discovered, composed

and consumed using standard protocols for the pur-

pose of building distributed, collaborative applica-

tions within and across organizational boundaries

(Manolescu et al., 2005, Rødseth et al., 2011).

SoaML (Service oriented architecture Modeling

Language) is an open source specification project

from the Object Management Group (OMG), de-

scribing a UML profile and metamodel for the mod-

eling and design of services within a service-

oriented architecture (Casanave, 2009). SoaML

meets the mandatory requirements of the UPMS

(UML Profile and Metamodel for Services). SoaML

includes descriptions of how to identify services, the

requirements they are intended to fulfill, the func-

tional capabilities they provide, what capabilities

consumers are expected to provide, the protocols or

rules for using them, and the anticipated dependen-

cies between them.

Advantages of using SoaML for Single Window

Systems:

1 Closer connection between the design and the

implementation phases of the Single Window de-

velopment:

SoaML ensures a close connection between the

description and the implementation of services,

since SoaML works at the level of services. This

means that the connection between for instance

web services to implement the services can be

very tight to the description of the service archi-

tecture of the Single Window system.

2 Focus on services both at the design and imple-

mentation level:

Using SoaML means that both analysis and im-

plementation will focus on services. This is im-

portant in at least two aspects: to avoid silo think-

ing regarding the systems, and to facilitate the

creation of complex services based on basic, al-

ready existing services in the Single Window en-

vironment.

3 Intuitive way to describe third party systems:

This is important in the sense that the third party

systems can be described as legacy systems being

wrapped up in a new service. The third party sys-

tems can be described with a clear interface to the

Single Window system regarding information ex-

change, functionality and payment regimes.

4 Reuse of services in new, complex services:

A SW system will make more information than

before available as a whole. This means that the

information can be combined in new ways offer-

ing new services. This leads to the need to com-

bine new and existing services into complex ser-

vices. SoaML is suitable for describing such

complex services.

Difficulties of using SoaML for SW Systems

1 Unclear notion of data model since the focus is on

services and processes:

The semantics of data in a Single Window envi-

ronment is very important since several systems

with heterogeneous data models have to cooper-

ate. In this context, the notion of three level ar-

chitecture for data model is important, that is, the

conceptual schema describing all concepts (enti-

ties and relationships) in the Single Window, and

the external schema describing only the part of

the data that is relevant for each third party sys-

tem. Separate from this, we have the internal

schema describing the implementation. SoaML

does not contain explicit description of this.

2 Complex syntax:

The notation and syntax of SoaML may appear to

be complex for those who are not familiar with it.

This may lead to difficulties in the communica-

tion with practitioners in the port and logistics

domain.

In (Zuesongdham, 2009), it is argued that a com-

bination of CIMOSA and SOA modeling is the most

attractive approach to develop interoperable port

community systems. This is because the inter-

organizational process modeling capabilities from

CIMOSA is needed in addition to the more techno-

logical related implementation view.

4 CONCLUSIONS

Several definitions of Single Window exists, most of

them are focused on handling regulatory infor-

mation. The future will show a more integrated in-

formation society between public and private sys-

tems as this paper has shown. However, we have

argued that the taxonomy and the use of commonali-

ties between them must be in place to have a harmo-

406

nized way of doing trade and transport. If each of

them will be developed as a proprietary system than

lots of engineering between them is needed to get

any valuable benefits of using the Single Window

concepts as described. One of the key points is use

of standard information and code values.

Several initiatives related to the development and

operation of maritime Single Window systems exist,

including the description of Single Window frame-

works by IMO (IMO/FAL36/1 2010,

IMO/FAL/36/2 2010), UN/CEFACT recommenda-

tion on Single Window (UNCEFACT 2005, 2010),

and (APEC 2009), and the description of several

data models related to Single Window including

(ISO/FDIS 28005-2 2010) on Electronic Port Clear-

ance (EPC), and (ISO 7372 2005) on TDED data

model. However, it is important to further proceed in

obtaining a distinct and unified framework and

methodology for developing Single Window sys-

tems, which will crucially support a smooth and

manageable integration of heterogeneous systems in-

to a Single Window environment. Single Window

systems need to be developed based on the compati-

ble standards regarding formal descriptiona of logis-

tics processes, interfaces and information content.

Cooperation between several national and regional

Single Window solutions will be simplified if the

systems are developed based on a unified framework

and compatible methodologies. Also, integration of

the numerous third party systems into the different

national Single Window environments will be more

efficient as based on a unified methodological back-

ground, and if systematically applied.

ACKNOWLEDGEMENTS

This work has been partially funded by the EU

eFREIGHT 7FP DGTREN Project

(www.efreightproject.eu) and by Norwegian Re-

search Council MIS project (Maritime Information

Centre- http://www.sintef.no/Projectweb/MIS/).

REFERENCES

Casanave, C. 2009. Enterprise Service Oriented Architecture

Using the OMG SoaML Standard, white paper on

www.modeldriven.com

CIMOSA home page: http://www.cimosa.de/

IMO/FAL/36/1 2010. Electronic Means for the Clearance of

Ships: The use of the Single Window Concept, Submitted

by Brazil.

IMO/FAL/36/2 2010. Electronic Means for the Clearance of

Ships: Justification for Single Window Guideline for Mari-

time Transport, Submitted by the Republic of Korea.

ISO/FDIS 28005-2 2010. Security management systems for the

supply chain -- Electronic port clearance (EPC) -- Part 2:

Core data elements

ISO 7372 2005. Trade data interchange -- Trade data elements