Asian Transport Studies, Volume 5, Issue 4 (2019), 694–719

Iida, J., et al. / Asian Transport Studies, Volume 5, Issue 4 (2019), 694–719.

694

Research Article

Sharing Procedure Status Information on Ocean Containers across

Countries Using Port Community Systems with Decentralized Architecture

Junya IIDA a, Daisuke WATANABE b, Kenta NAGATA c, Masahiro MATSUDA d

a National Institute for Land and Infrastructure Management, Ministry of Land,

Infrastructure, Transport and Tourism, Kanagawa, 239-0832, Japan; and Graduate

School of Marine Science and Technology, Tokyo University of Marine Science and

Technology, Tokyo 135-8533, Japan;

E-mail: [email protected] b Department of Logistics and Information Engineering Faculty of Maritime

Technology, Tokyo University of Marine Science and Technology, Tokyo, 135-8533,

Japan;

E-mail: [email protected] c Development Group Planning Dept, Logistics Solution Division, Sankyu Inc.,

Tokyo, 104-0054, Japan;

(Former position) International Logistics Division, Policy Bureau, Ministry of

Land, Infrastructure, Transport and Tourism, Tokyo, 100-8918, Japan;

E-mail: [email protected] d Urban Environment Division, Bureau of Community Revitalization, Department of

Construction, Hokkaido Government, Hokkaido, Japan;

(Former position) Port Management and Operation Division, Port and Harbors

Bureau, Ministry of Land, Infrastructure, Transport and Tourism, Tokyo, 100-8918,

Japan;

E-mail: [email protected]

Abstract: Consignors, consignees, and freight forwarders need procedure status information

on import and export containers, such as customs clearance, not only within a specific country

but also across relevant countries in order to optimize supply chain management. In this paper,

we review the current situation and literature on the sharing of procedure status information

using IT systems. After clarifying issues in this regard, we present an IT system we have

developed for sharing procedure status information in real time among Port Community

Systems across countries. Finally, we discuss the issues and prospects in the development of

the IT system. We conclude that, at present, it is beneficial to apply a decentralized system

architecture in the sharing of procedure status information across countries without attaching

any additional devices such as Radio Frequency Identification (RFID) tags.

Keywords: Procedures for Import/Export, Electronic Data Interchange, Container Visibility,

Information Technology, Port Community System

Corresponding author.

This is an open-access article distributed under the terms of the Creative Commons Attribution 4.0 International

License (CC BY 4.0: https://creativecommons.org/licenses/by/4.0).


695

1. INTRODUCTION

In this era of continuing economic globalization, enterprises tend to manufacture, supply, and

sell their goods across international borders. Ocean containers play a major role in shipping,

which supports business operations. To manage inventory controls or inland transportation

(i.e., to optimize supply chain management or SCM), consignors, consignees, and freight

forwarders need logistics status information on their ocean containers, such as the origin,

transshipment, and destination, not only within a country but also across relevant countries.

The logistics status information of ocean containers is divided into two types. One is the

status of movement or location of the containers (hereinafter referred to as “movement status

information”). The other is the status of the procedures that are required for importing or

exporting (hereinafter referred to as “procedure status information”). Moreover, these

procedures are divided into two categories. Some are processed by government authorities,

such as customs or ship clearances (this procedure is referred to as “Business to Government:

B-to-G”). The others are processed by the private sector, such as the filling and sending of

shipping documents, or paying ocean freights (this procedure is referred to as “Business to

Business: B-to-B”). Logistics companies must follow these two types of procedures when

importing or exporting their containers.

There are certain studies or implementations that have been performed with regard to

sharing movement and procedure status information within a port. However, few studies or

implementations have been conducted in terms of sharing movement status information

across countries. Additionally, there are almost no studies or implementations on sharing

procedure status information across countries. Iida et al. (2018) appears to be the only study

that reviews the current situation regarding the sharing of procedure status information. This

study analyzes the business processes of B-to-G and B-to-B, exemplifies certain information

technology systems (hereinafter referred to as “IT systems”) for these processes, and outlines

information technologies that could be applied in setting them up. Thus, to improve the

sharing of procedure status information across countries by using IT systems, we focus on

developing such a system across countries from a technical viewpoint. The structure of this

paper is as follows:

Section 2: The current situation of the sharing of procedure status information is

clarified. Based on this situation, we clarify that Port Community Systems

(PCSs), which are explained in section 2.3, are already being applied in the

sharing of procedure status information within port communities, and propose

the utilization of PCSs in the sharing of this information across countries.

Considering the above, we determine that the scope of this study is how to

develop an IT system for collaboration of PCSs across countries from a technical

viewpoint.

Section 3: An analysis of the system architecture for international collaboration

of PCSs is conducted based on a literature review. Considering the issues raised

by this review, we propose the adoption of a decentralized system architecture

without attaching Radio Frequency Identification (RFID).

Section 4: Based on the proposed architecture, we describe an IT system for

sharing procedure status information among PCSs across countries in the import

process, whose development the authors have significantly contributed to.

Section 5: Taking into account the aforementioned sections, the implications and

prospects for sharing procedure status information using IT systems are

discussed.


696

Note that any descriptions in this paper are the views and opinions of the authors and do

not represent the views or opinions of any organizations.

2. THE CURRENT SITUATION OF SHARING PROCEDURE STATUS

INFORMATION

2.1 The Importance of Sharing Procedure Status Information

In this section, we present the importance of obtaining procedure status information.

Abe (2015) shows the percentages of respondents that need the procedure status

information as follows:

Status information regarding the export customs clearance at ports of loading in

foreign countries: 67.2%

Status information regarding the import customs clearance at ports of discharge

in Japan: 73.8%

Status information regarding the export customs clearance at ports of loading in

Japan: 65.6%

Status information regarding the import customs clearance at ports of discharge

in foreign countries: 67.9%

These respondents primarily comprise manufacturing companies in Japan that practice SCM.

Morikawa (2015) points out that international shipping is hampered by the unexpected delays

associated with customs clearance. These studies show the necessity of status information

regarding customs clearance (i.e., B-to-G).

However, as far as we know, there is no survey or study that focuses on the importance

of B-to-B procedure status information. Some B-to-B procedures go through multiple parties,

which makes it difficult to efficiently share procedure status information (e.g., the status

information on a Delivery Order (D/O) is needed by a freight forwarder, ocean carrier,

container terminal operator, and trucking company). Thus, the necessity of obtaining B-to-B

procedure status information is evident.

2.2 The Conventional Flow of Procedure Status Information across Countries

The conventional flow of obtaining procedure status information across countries is described

in Figure 1, considering the current situation in Japan (Iida et al., 2018). Figure 1 clarifies that

sharing this information requires substantial amounts of time and cost as multiple parties are

involved in this flow and communicate through manual means such as telephone, fax, and

e-mail. Specifically, in terms of information regarding government authorities such as

customs and harbormasters in foreign countries, only companies that are located in the

country and that have a certificate of registration in the country can usually access the

government authorities’ system using the local language. Thus, it would be difficult to directly

share information with foreign countries1.

1 Note that in the case where a forwarder has its subsidiary companies in foreign countries, the forwarder

can share the information through their systems (e.g., SANKYU INC., 2018). This means that it would be

easy for the forwarder to share the information compared to the general flow in Figure 1.


697

2.3 Existing Practical Implementation of Digitization for Sharing Procedure Status

Information

In Japan, an IT system referred to as the “Nippon Automated Cargo and Port Consolidated

Systems (NACCS)” has been introduced (NACCS, 2018). NACCS processes all B-to-G (e.g.,

customs clearance, etc.,) and some B-to-B procedures or formalities such as the exchange of a

Delivery Order (D/O) electronically 2 . Other than NACCS, Japan’s Ministry of Land,

Infrastructure, Transport and Tourism (MLIT) has developed and operates an IT system called

the “Container Logistics Information Service: COLINS,” which provides logistics

information on containers at the ports of Tokyo, Yokohama, Osaka, Kobe, and so on (Iida and

Shibasaki, 2016). The port of Hakata has an IT system called “HiTS,” which provides

logistics information on containers at the port of Hakata (Hakata Port Terminal Co., Ltd.,

2018). Additionally, the ports of Nagoya and Shimizu have the same type of system3. Note

that HiTS is also used to share procedure and movement status information with foreign

countries. The details are described in section 3.1.

In the Republic of Korea (RoK), an IT system called “Port-MIS” has been introduced

(Korea Maritime Institute, 2015). Port-MIS mainly processes ship and cargo clearances

related to the RoK’s Ministry of Oceans and Fisheries (MOF). Users of Port-MIS can obtain

procedure status information via this system. Additionally, MOF operates an IT system called

Global Container Tracking System (GCTS) for tracing the location of goods within the RoK.

Furthermore, the Shipping and Port Internet Data Center (SPIDC) has been established to

provide logistics information by connecting Port-MIS, GCTS, and other stakeholders such as

freight forwarders, ocean carriers, terminal operators, and government agencies (Lee and

Cullinane, 2016).

In Singapore, PSA Singapore, which operates the container terminals of Tanjong Pagar,

Keppel, Brani, and Pasir Panjang, offers information on the movement and procedure status

through their IT system, referred to as PORTNET (PSA Corporation Limited, 2018).

In Malaysia, the Port Klang Authority operates an information sharing system “Port

Klang Net.” The Port Klang Authority also had plans to develop a function using Port Klang

2 D/O is issued by an ocean carrier at the discharge port after a consignee submits the Bill of Lading (B/L).

D/O plays a role of approving the picking up of import containers from the container yard. 3 The port of Nagoya has an IT system called “NUTS-Web.” The port of Shimizu has an IT system called

“SPNET.”

Figure 1. The general flow of obtaining procedure status information across countries Source: Iida et al. (2018)

Consignor/Consignee

(In country A)

Freight forwarder

(In country A)

Customs(In country B)

Query

Answer

Ocean carrier or Shipping agency (In country B)

Freight forwarder

(In country B)

Query

Answer

Query

Answer

Query

Answer

Country A Country B


698

Net for sharing procedure status information by 20174.

In the People’s Republic of China (PRC), an IT system called LOGINK (National

Public Information Platform for Transportation & Logistics) has been introduced. It is an

open, public, shared logistics information network sponsored by the Ministry of Transport and

the National Development and Reform Commission. Additionally, it is a government-led

transport infrastructure featuring logistics information services (LOGINK, 2017). It integrates

import and export data services from domestic ports, shipping companies, freight forwarders,

container trailers, warehouses, and so on (LOGINK, 2019).

In the United States, the Port of New York and New Jersey has introduced an online

tool called the Terminal Information Portal System, or TIPS. TIPS compiles information from

all six container terminals in the port and provides the status of ocean containers such as the

availability for pickup and the federal agency applying those holds (Field, 2015).

Some major ports in Europe have introduced an IT system called the Port Community

System (PCS). For example, the port of Antwerp operates “C-point5” (Port of Antwerp, 2019), the port of Rotterdam operates “Portbase” (Portbase, 2019), and the port of Hamburg operates

“Dakosy” (Dakosy, 2019). The International Port Community Systems Association (IPCSA)6

defines PCS as follows:

PCS is a neutral and open electronic platform that enables the intelligent and

secure exchange of information between public and private stakeholders in order

to improve the competitive position of the sea and air port communities.

PCS optimizes, manages, and automates port and logistics processes through a

single submission of data and connecting transport and logistics chains.

Additionally, the IPCSA describes that PCS provides status information regarding control,

tracking, and tracing throughout the logistics chain (IPCSA, 2018). Thus, users of some major

advanced ports that have introduced PCS can obtain the procedure status information within

the ports.

Taking into account the definition of PCS by the IPCSA and other resources (e.g., IAPH,

2011; Heilig and Voß, 2017), the aforementioned systems in and outside Europe can be

regarded as PCSs.

2.4 Scope of this Paper

Sections 2.1 to 2.3 are summarized as follows:

There is a need for obtaining procedure status information across countries.

When logistics companies obtain the procedure status information, they usually

communicate manually, which requires substantial amounts of cost and time.

Some advanced countries (or ports) have IT systems called PCSs. PCSs are used

for sharing procedure status information within the port community.

4 This information is based on an interview with the Port Klang Authority by the authors in 2016. However,

at the time of writing, we were not able to verify the implementation of this function through the Port

Klang Authority website. 5 In 2018, the Antwerp Port Community System (APCS) was converted into C-point. 6 The IPCSA is the successor to the European Port Community Systems Association (ECPSA), which was

established in June 2011 by six founding members, all European-based Port Community System operators

(IPCSA, 2018).


699

Considering the above, we illustrate the mechanism of obtaining procedure status information

using PCSs in Figure 2, corresponding to Figure 1. Figure 2 shows that the procedure status

information is shared within a PCS network. However, it is difficult to access other countries’

PCSs due to language barriers or authentication issues. Thus, to facilitate the sharing of

procedure status information, connections among PCSs are desirable. If PCSs are connected,

a consignor or consignee can obtain data across countries through these inter-PCS

connections (i.e., Users of the PCS in country A can obtain data pertaining to country B by

only accessing the PCS in country A since the PCS in country A automatically inquires about

the data of the PCS in country B.). However, there are only few existing commercial

operations of sharing procedure status information among PCSs (i.e., HiTS seems to be the

only case).

Thus, in this paper, we focus on how to develop an IT system for collaboration among

PCSs from a technical viewpoint, especially in terms of system architecture.

3. TECHNICAL METHOD FOR SHARING PROCEDURE STATUS INFORMATION

AMONG PCSs INTERNATIONALLY

3.1 Literature Review

System architecture for sharing data among systems, parties, or organizations is considered as

a technical backbone (UN/CEFACT, 2005; Srour et al., 2008). Srour et al. (2008) propose

four system architectures that enable inter-organizational collaboration by connecting two or

more organizationally disparate applications as follows: bilateral; private hub; central

orchestration hub; and modular distributed plug-and-play architecture. Boertien et al. (2002)

and Posti et al. (2011) classify the three types of system architecture for PCSs as follows:

bilateral information model; centralized information model; and decentralized information

model. Regarding the architecture of Srour et al. (2008), it is assumed that the private hub is

the same as the central orchestration hub from a technical viewpoint. Thus, considering the

studies of Posti et al. (2011), Boertien et al. (2002), and Srour et al. (2008), we classify the

Figure 2. The mechanism of obtaining procedure status information across countries using

PCSs Source: the authors

Consignor/Consignee

(In country A)

Freight forwarder

(In country A)Customs

(In country B)

Ocean carrier or Shipping agency (In country B)

Freight forwarder

(In country B)

Country A Country B

PCSPCS

A PCS network in country A A PCS network in country B

How to collaborate?


700

system architecture for sharing status information into three categories as shown in Table 1. In

Table 1, the features of each system architecture are described based on the literature review.

In addition, considering the study of Heilig and Voß (2017), Radio Frequency Identification

(RFID) is a key technology for sharing data internationally.

Therefore, by conducting a literature review, we explore which type of system

architecture is better, and whether the RFID technology should be adopted in sharing

procedure status information.

(1) Studies regarding the centralized type

Baron and Mathieu (2013) discuss the PCS interoperation at the European level. They

consider the PCS as an information platform, and analyzed payment systems such as Visa and

MasterCard as success cases of platform interoperability. They indicate that a key point of

establishing payment systems is organizing cooperation between competitors (i.e., payment

card’s company or bank). They also suggest points of cooperation as follows: the initial

7 Electronic interface indicates a rule of electronic data interchange or electronic collaboration between IT

systems. The rule is composed of grammar (or syntax) of electronic messages based on business rules and

communication protocols (such as HTTP and FTP).

Table 1. The types of system architecture for sharing status information

One-to-one type Centralized type Decentralized type

Fig

ure

Expla

nat

io

n

System A collaborates with

each system (systems B to E)

separately. The rules of

collaboration* is defined by

each combination.

Systems A to E collaborate

via the centralized system.

The rules of collaboration of

each combination are usually

common.

Under the common rule

of collaboration,

systems A to E

collaborate with each

other.

Fea

ture

-This type is convenient and

relatively cheap to implement

(Posti et al., 2011).

-It experiences scalability

problems, and therefore, it is

best suitable for situations

where the number of parties

involved in the information

network is relatively small

(Posti et al., 2011).

-Information is retrieved on

demand (Posti et al., 2011).

-A strong party is needed to

link with many parties (Srour

et al. 2008).

-Information is

exchanged when it is

needed (Srour et al.,

2008; Posti et al., 2011)

-Standardization is

critical (Srour et al.,

2008).

* Rules of collaboration refer to the electronic interfaces,7 security requirement, etc.

Note: “System” is equivalent to “PCS” in this study.

Source: edited from Iida et al. (2018); Posti et al. (2011); and Srour et al. (2008)

System A

System B

System CSystem D

System E

System A

System B

System CSystem D

System E

Centralized system

System A

System B

System CSystem D

System E


701

innovation is licensed; associations of banks appear to deal with interdependencies; and

operators become public owned. From a technical viewpoint, they note that such a payment

system has a centralized type architecture. Regarding interoperability among PCSs, they

describe, “…a European PCS could develop as an association between existing PCS operators,

and in that sense, the creation of the European PCS Association8 could be the beginning of

the story….” They also indicate that the final architecture of a European platform could be

centralized. Considering this context, it is assumed that they propose a centralized type for

interoperability among PCSs, and that an association for the operation of the centralized type

should be established. However, this study is conceptual.

Srour et al. (2008) analyze some existing PCSs and suggest that, from a technical

viewpoint, a central hub solution may be preferable for coordinating inter-organizational

parties; on the other hand, they point out that the adoption of a central hub depends on

significant levels of trust among parties.

Hesketh (2010) proposes the concept of the “electronic data pipeline,” which has the

following features:

It is web-based;

It links the seller/consignor, the buyer/consignee, and the interested economic

operators;

It offers real-time movement information of goods; and

It shares data with the systems connected to it.

The purpose of the electronic data pipeline is to promote the seamless sharing of customs

status information between the private sector and governments, and among governments.

Pugliatti (2011) proposes the creation of a Cloud Single Window (CSW) model that

plays the role of an interface for connecting with each government’s Single Window System

(i.e., National Single Window: NSW). Furthermore, he suggests that the CSW model can

connect with the electronic data pipeline that is proposed by Hesketh (2010). Thus, the CSW

model can become a central database that has all the relevant procedures’ data of all parties

that join the CSW. However, the electronic data pipeline and CSW are in the conceptual stage.

Moreover, the two studies do not clarify which organization should operate the electronic data

pipeline and the CSW model.

Czyzowicz and Rybaczyk (2017) focus on the Customs Enforcement Network (CEN)

database that is operated by the World Customs Organization (WCO). Additionally, they state

that cooperation with other government authorities is important in setting up such an IT

system. They describe the significance of cooperation between government agencies within a

country, with neighboring countries, and with large importers and exporters such as the USA,

Germany, and China. Thus, their study is helpful in setting up an IT system for sharing

information across countries in the case where an organization that can collect data exists,

such as WCO.

Helo and Szekely (2005) describe the usefulness of the Enterprise Application

Integration (EAI). They define EAI as software applications within an enterprise; however,

they emphasize that the EAI enables the sharing of information among other IT systems of

external enterprises to improve SCM. Additionally, they state that the crucial problem is how

to create a suitable standard for system collaboration. However, this study is in the conceptual

stage, so there is no discussion about issues with practical implementations.

8 “The European PCS Association” means the current IPCSA.


702

(2) Studies regarding the decentralized type

Iida and Shibasaki (2016) describe the Northeast Asia Logistics Information Service Network

(Neal-Net), which is the project sharing logistics information between Japan, the PRC, and

the RoK, as a decentralized system type of architecture. However, they only focus on the

location of containers (i.e., movement status information) and do not apply the decentralized

type to procedure status information. According to interviews with IPCSA representatives,

some IPCSA member ports have started to collaborate on a pilot project for sharing

movement status information on containers and vessels across counties using the

decentralized system type of architecture.

(3) Studies regarding the one-to-one type

Regarding the one-to-one type, Posti et al. (2011) notes its feature as shown in Table 1.

However as far as we know, there is no academic study that explores the sharing of status

information across countries using this type of system architecture. Regarding its practical

implementation, HiTS, which is a PCS used in the port of Hakata in Japan as shown in section

2.3, is connected to 13 ports in other countries, such as Shanghai, Hong Kong, and Bangkok,

using the one-to-one type to share movement and procedure status information (Hakata Port

Terminal Co., Ltd., 2019). However, it is necessary to adjust the electronic interface for the

collaboration of IT systems every time it is expanded to new partners.

(4) RFID

Oghazi et al. (2018) investigate the impact of RFID and enterprise resource planning (ERP)

systems on the SCM. They conclude that the ERP and RFID systems contribute to the SCM

by improving the supply chain integration. They classify the supply chain integration into four

levels (level 1: internal integration, level 2: integration with supplier, level 3: integration with

customer, and level 4: full integration). Considering the scope of our study, level 4 can be

used as a reference. Regarding level 4, they assume that the RFID can provide the necessary

information regarding the inventory status, and that supply chain members can have access to

this information through seamlessly interconnected ERP systems. If we consider the ERP

systems as PCSs, this concept can be helpful. However, from a technical viewpoint, there is

no explanation for the mechanisms connecting the ERP systems, deploying the RFIDs,

attaching them to containers, and harmonizing or interoperating their specification.

Sia Partners (2016) conducts a study on the Internet of Things (IoT) in the port of

Hamburg. They report that, in transportation, IoT began with the track-and-trace Global

Positioning System (GPS) technology to track shipments, and has further been advanced with

the introduction of RFID. They suggest that, thanks to the automatic radar identification and

RFID, there is a possibility that port authorities are constantly notified of all the movement in

the port, the expected delivery times, and the port services that need to be deployed for proper

handling. To create a network of IoT in the Port of Hamburg, they propose that the Hamburg

Port Authority’s IT providers need to continuously work on the development of a uniform

central intelligence system that is able to communicate with all connected devices in a

common language. They seem to conclude that it is better to adopt a centralized platform for

collecting data from RFID. However, their study focuses on the port of Hamburg only; thus,

there is no investigation on the sharing of RFID data with other PCSs. Although they describe

that RFID is useful for sharing movement status information, they have not examined the

application of RFID in sharing procedure status information. Furthermore, this is a conceptual

study.

Wang and Cheng (2015) suggest setting up the International Trade Facilitation Center

(ITFC) in Hong Kong as a central hub port for the global supply chain in Asia. They assume


703

that introducing the ITFC can reduce the institutional formalities of other ports in Asia since

some of these formalities are centralized and processed at the ITFC. Additionally, with the

assistance of the RFID-enabled locks and GPS tracking systems, containers carrying verified

and checked goods can subsequently be shipped to the importing ports after completing the

checking activities that have to be performed locally. However, this is a conceptual study and

there is no detailed explanation for the implementation of RFID.

Regarding (1) of this section, Pugliatti (2011) suggests using the RFID and GPS

installed container seals for implementation of the electronic data pipeline that was proposed

by Hesketh (2010). Additionally, Helo and Szekely (2005) demonstrate that RFID are

presenting possibilities for automated real-time traceability processes. However, a mechanism

for attaching RFID on containers worldwide has not been proposed.

Will (2011) points out that RFID does not exist in global open-loop container logistics

because of the following reasons: there are many different participants; equipping all

containers with RFID is a complicated long-term mission; the infrastructure providers have to

provide RFID reading devices; license plates need to be installed by the containers’ owners;

and shipment tags need to be affixed to the container by the shipper.

3.2 Proposing Adoption of the Decentralized Type Architecture

Taking into account the aforementioned studies, issues arising from the existing studies are

summarized in Table 2. Table 2 indicates that when an operator of a one-to-one type

architecture expands international collaboration to other countries, partners must discuss what

type of electronic interface should be applied, and whether a new electronic interface should

be developed. This requires substantial amounts of time and effort. Moreover, setting up an

international collaboration by applying centralized system architecture requires substantial

time and effort in choosing the administrator of the centralized system, although most of the

studies in section 3.1 propose the adoption of the centralized system. Furthermore, when

using RFID, it is necessary to discuss the installation of RFID devices on all containers,

harmonizing its specifications, and inputting data into it. It means that there is a gap between

concepts and implementation.

Considering these issues, we propose the adoption of the decentralized type for sharing

procedure status information among PCSs across countries, although most of the existing

studies related to our scope propose the adoption of the centralized type. Additionally, we

suggest not attaching RFID on containers. Following the system architecture, we describe the

development of an IT system which the authors are engaged in. Taking into account the

development and literature review, we investigate the possibility of the adoption of the

decentralized type for sharing procedure status information.

The academic and practical contributions of this study are as follows:

To the best of the authors’ knowledge, there is no study that analyzes the

implications of adopting the decentralized type for sharing procedure status

information across countries utilizing PCSs. Additionally, there are few existing

commercial operations of sharing procedure status information among PCSs.

Most of the studies shown in section 3.1 are conceptual and do not investigate

the implementation of their concepts. Our study, by contrast, goes further and

analyzes the adoption of the decentralized type through the development of an IT

system.


704

Table 2. Issues Arising from Existing Studies and Practical Implementations

System

architecture

type

Studies or

implementations

Issues of the study or practical implementation

One-to-one HiTS (Hakata Port

Terminal Co.,

Ltd., 2019)

It is necessary to adjust the electronic interface for the

collaboration of IT systems every time the management body

of HiTS negotiates to expand it to new partners.

Centralized European PCS

(Baron and

Mathieu, 2013)

An association for the operation of the centralized type

should be established.

This system is conceptual.

Electronic Data

Pipeline and CSW

(Hesketh, 2010

and Pugliatti,

2011)

The electronic data pipeline is at the conceptual stage. It has

not been implemented yet.

It is not clear which country or organization should operate

the Electronic Data Pipeline and CSW.

CEN (Czyzowicz

and Rybaczyk,

2017)

The centralized type is only suitable, if the responsible

organization such as the WCO, has the power to collect data

into one database.

On the other hand, in the case of sharing status information

across countries with multiple parties, selecting the best

organization for managing and controlling the database needs

to be examined.

EAI (Helo and

Szekely, 2005)

Helo and Szekely (2005) point out that one issue of EAI is

the creation of a standard for the electronic interface.

Additionally, EAI is still in the conceptual stage.

Decentralized Neal-Net (Iida and

Shibasaki, 2016)

This is an advanced implementation using the decentralized

type from the viewpoint of sharing movement status across

countries. However, the sharing of procedure status

information is out of scope and has not been examined.

Collaboration

between PCSs

coordinated by

IPCSA (Based on

an interview)

According to IPCSA, they have begun to collaborate the

movement and procedure status information between PCSs

across countries on a pilot project by applying the

decentralized type.

RFID Adoption of RFID

to Electronic Data

Pipeline (Pugliatti,

2011)

The owners of containers are located worldwide. Thus, how

to distribute and attach the RFID tags on containers needs to

be examined. This study is still in the conceptual stage.

Adoption of RFID

to the Port of

Hamburg

(Siapartner, 2016)

There is no investigation on the sharing of the RFID data

with other PCSs.

The adoption of RFID in the sharing of procedure status

information has not been examined.

This is a conceptual study.

RFID and ERP

(Oghazi et al.,

2018)

There is no explanation of the mechanisms connecting the

PCSs, deploying and attaching RFIDs to containers, unifying,

integrating, or interoperating RFID specification.

This is a conceptual study.

RFID and ITFC

(Wang and Cheng,

2015)

This is a conceptual study and there is no detailed

explanation for the implementation of RFID.

Source: the authors


705

4. DEVELOPMENT OF AN IT SYSTEM FOR SHARING PROCEDURE STATUS

INFORMATION ON IMPORT PROCESSES AMONG PCSs ACROSS COUNTRIES

4.1 Scope of the IT System

We focus on the import procedures in developing an IT system for sharing procedure status

information. The reasons are as follows:

It usually takes more time to administer the procedures of import containers

compared to the export ones. Thus, the needs for the visibility of import

containers may be higher than those of export containers.

Regarding B-to-B procedures, the status of a Delivery Order in the import

containers’ procedures is shared with multiple parties such as ocean carriers,

container terminal operators, freight forwarders, and trucking companies. The

sharing of information sometimes fails due to manual communication.

Logistics companies make use of the permission status of picking up containers

from the container yard (CY) (i.e., whether the import containers can be carried

out from the CY) in formulating inland delivery plans. Additionally,

manufacturers make use of the information in devising manufacturing and sales

plans.

The aforementioned reasons are mainly described from the importers’ viewpoint. In addition,

the first and second bullet points are also important for exporters who ship their containers

based on Delivered Duty Paid (DDP), which is a type of Incoterm.

Considering the above reasons, we specify the following data that are handled by the IT

system.

1) Quarantine for agriculture and animals

2) Customs clearance

3) Procedure for Delivery Order

4) Permission for the release of import containers

The relation between the aforementioned data and the import procedure is shown in

Figure 3.

The geographical scope covers major ports in Japan, the PRC, and the RoK at the time

of development. In the future, it is expected that the scope will be expanded to other areas.

4.2 Method of Development

The IT system for sharing procedure status information among the Japanese, PRC, and RoK

PCSs was developed in three parts. The first part (section 4.2.1) was the development of an

electronic interface for system collaboration (i.e., inter-system coordination). This was

developed through discussions among experts from the three countries9, including the authors.

The second part (section 4.2.2) was the development of a component for the inter-system

coordination mechanism based on the basic design and technical specification written by the

authors. The third part (section 4.2.3) was the development of a website for users based on the

9 The experts consisted of government officials, national institute researchers, and IT engineers from the

private sector. Additionally, sometimes, the experts consulted with other experts regarding the

UN/CEFACT standard in maritime logistic fields.


706

basic design and technical specification written by the authors. The relation between the three

parts and the system architecture, including PCSs, are described in Figure 4. In this

development, we have made use of the system infrastructure and the cooperation mechanism

of Neal-Net discussed in section 3.1 (Iida and Shibasaki, 2016) which shares the movement

status information of ocean containers between Japan, the PRC, and the RoK.

Note: the procedure surrounded by squares indicates the procedure status data handled by the IT system

Figure 3. Relation between the import procedure and status data handled by the IT system Source: the authors’ elaboration from Iida et al. (2018)

Figure 4. Relation between the outline of the system architecture and section 4.2.1 to 4.2.3 Source: the authors

Status information stored in COLINS, namely PCS for ports in Japan

(Japanese version) Component for inter-system coordination: section 4.2.2

JapanWebsite: section 4.2.3

Electronic interface : section 4.2.1

(RoK version) Component for inter-system coordination

(PRC version) Component for inter-system coordination

Status information stored in SPIDC, namely PCS for ports in the RoK

Status information stored in LOGINK, namely PCS for ports in PRC

RoK PRC

Container Yard (Bonded Area) GateQuay wall

Gate outContainer picking up

Container Storage Discharge

【Flow of movement】

1) Quarantine of agriculture and animal etc.

3) Procedure for Delivery Order(i.e., a consignee or forwarder submits a B/L and get a D/O. After that, they submit the D/O to a container terminal operator.)

Procedure of B to G:

Procedure of B to B:

4) Permission for the release of import containersGetting

a B/L

【Flow of procedure】



707

4.2.1 Development of the electronic interface

When sharing data between IT systems, we should develop (or decide on) an electronic

interface that is composed of message rules and communication protocols.

In maritime fields, an electronic interface, called the UN/EDIFACT message, is widely

and commonly adopted for communication between systems (Heilig and Voß, 2017).

Therefore, we examine the possibility of applying UN/EDIFACT messages in the sharing of

procedure status information. From a technical viewpoint, the following issues arise:

The UN/EDIFACT messages in the maritime field are typically used for one-way

communication from a sender to a receiver. (e.g., one of the UN/EDIFACT

messages is used for sharing the storage plan of containers in a vessel. The

message is referred to as VAPLIE, and is sent from a loading port to a discharge

port via an ocean carrier.) This one-way communication is usually conducted as

a batch based on a business rule that is agreed upon by the message sender and

receiver. Thus, there is basically no request message on each UN/EDIFACT

message, making it difficult for users to request the real-time status of containers.

Therefore, when applying a UN/EDIFACT message for obtaining the procedure

status information from other systems, it is necessary to define the message for

request.

The UN/EDIFACT message in the maritime field may not be used for data

transmission in real-time.

The syntax rules (grammar) of UN/EDIFACT apply variable delimiters to

separate data items contained in a message. The syntax rules such as the order

and symbolic characters are strictly defined, so that it takes time and effort to

modify a UN/EDIFACT message when adding new data items to a message.

In the case where UN/EDIFACT messages are modified, it is necessary for

message senders and receivers to modify their IT systems simultaneously.

Considering the aforementioned issues, for the time being, the use of existing UN/EDIFACT

messages would not be suitable for sharing procedure status information. Thus, another

electronic interface for sharing procedure status information should be developed. In addition,

with regard to sharing procedure status information, there is no global standard for electronic

interfaces.

Thus, we have developed an electronic interface for sharing procedure status

information applying one of the standards referred to as the Electronic Product Code

Information Service (EPCIS) as a base technology. EPCIS is an international standard that

enables trading partners to share information on movements of products throughout the

supply chain, from business to business, and ultimately, to consumers. EPCIS is defined by

GS1 which has been designated by the European Commission as the issuing entity for Unique

Device Identifiers (UDIs). The Asia-Pacific Economic Cooperation (2012) recommends the

adoption of EPICS in sharing cargo status information among entities involved in the supply

chain. Additionally, XML (eXtensible Markup Language) is applied to the EPCIS messages.

The concept of EPCIS is to share visibility event data which consists of “what,” “where,”

“when,” and “why” (they are called “Dimension”) regarding an object (GS1, 2017; GS1,

2014). In detail, “what” identifies the physical or digital objects that were involved in the

event. “When” demonstrates the time when the event took place. “Where” shows the location

where the event physically took place. “Why” describes the business context in which the

event took place. In our development process, the mapping table between the Dimension of


708

EPCIS and the data contents for sharing the procedure status information is presented in Table

3.

SOAP (Simple Object Access Protocol) over HTTPS is applied in the communication

protocol.

4.2.2 Development of the component for inter-system coordination

We have developed the component for collaborating among the PCSs of the three countries

based on the electronic interface described in section 4.2.1. The three countries agreed that

each would develop its component individually and attach it to the national PCSs operated by

each government (Japan: COLINS; RoK: SPIDC; and PRC: LOGINK). Additionally, to

ensure security, it was decided to allow only persons who were in charge of shipping to access

the status data. This was realized by making the input of the container and the B/L numbers

mandatory. Figure 5 shows an example of the request message on container number

WCGU000XXXX and B/L number SITDSHKWBXXXX, delivered by the Japanese version

of the component. Figure 6 shows an example of the response message to the aforementioned

request message delivered by the Japanese version of the component. Note that at the time of

writing this paper, the RoK and the PRC had not developed their own component yet, since

they are still holding discussions with relevant stake holders.

Table 3. Mapping table between Dimension of EPCIS and data contents in the sharing of

procedure status information Dimension

etc.

EPCIS data element Data contents Comments

What EPC List

(epcList)*

Container number Container number is defined

in ISO 6346.

When Event Time

(eventTime)*

Time when the event

happened

yyyy-mm-ddt

Record Time

(recordTime)*

Time when the event was

uploaded into database

yyyy-mm-ddt

Where Business Location

(bizLocation)*

Location of the port where

the event happened

Location of the port is

expressed in UNLOCODE

Why Business Step

(bizStep)*

Status data of the container Procedure status is shown as

follows***:

1) Quarantine for agriculture

and animals


3) Procedure for Delivery

Order

4) Permission for import

containers release

Business Transaction

(bizTransaction)*

B/L number** This is used for identifying a

container with container

number.

*() indicates the name of the tag of XML for each element.

**EPCIS Specification (GS1, 2014) exemplifies a purchase order or an invoice number as the Business

Transaction. Therefore, we apply a B/L number to the Business Transaction.

***These data correspond to section 4.1.

Note: except for the above dimension, extension fields are added to the data elements (e.g. container size etc.)

Source: the authors


709

4.2.3 Development of the website

The component described in section 4.2.2 enables data to be shared through electronic

messages. These electronic messages are converted to a display that humans can read via

systems or applications that are owned by each logistics company. However, it is difficult for

the companies that do not own these systems or applications to read and understand the data.

Thus, in order to improve the utility of the system for all users, we have developed a website

that can convert XML messages to easily readable expressions on web browsers. Figure 7

Figure 5. An example of a request message Source: the authors

Figure 6. An example of a response message to the request of Figure 5 Source: the authors

・・・・・Abbreviated・・・・・<queryName>SimpleEventQuery</queryName>

<params><param>

<name>eventType</name><value xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ns3:ArrayOfString">

<string>ObjectEvent</string><string>AggregationEvent</string>

</value></param><param>

<name>EQ_bizTransaction_urn:un:unece:uncefact:codelist:standard:UNECE:ReferenceTypeCode:BM</name><value xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ns3:ArrayOfString">

<string>SITDSHKWB02826</string></value>

</param><param>

<name>MATCH_epc</name><value xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ns3:ArrayOfString">

<string>urn:un:unece:uncefact:codelist:standard:UNECE:ReferenceTypeCode:ALP:WCGU0001368</string></value>

</param></params>

・・・・・Abbreviated・・・・・

・・・・・Abbreviated・・・・・<ObjectEvent>

<eventTime>2017-03-21T11:40:00.000+09:00</eventTime><recordTime>2017-03-21T11:41:25.508+09:00</recordTime><eventTimeZoneOffset>+09:00</eventTimeZoneOffset><epcList>

<epc>urn:un:unece:uncefact:codelist:standard:UNECE:ReferenceTypeCode:ALP:WCGU0001368</epc></epcList><action>OBSERVE</action><bizStep>urn:un:unece:uncefact:codelist:standard:UNECE:StatusCode:379</bizStep><bizLocation>

<id>urn:un:nealnet:codelist:standard:SubLocationCode:JPKWSKHC1C</id></bizLocation><bizTransactionList>

<bizTransaction type="urn:un:unece:uncefact:codelist:standard:UNECE:ReferenceTypeCode:BM">SITDSHKWB02826</bizTransaction></bizTransactionList><nealnet:ContainerOperatorCode xmlns:nealnet="http://www.nealnet.org/tracking/extensions/">12PD</nealnet:ContainerOperatorCode><nealnet:ContainerSizeType xmlns:nealnet="http://www.nealnet.org/tracking/extensions/">20TN</nealnet:ContainerSizeType><nealnet:CapID xmlns:nealnet="http://www.nealnet.org/tracking/extensions/">Colins2011</nealnet:CapID>

</ObjectEvent>・・・・・Abbreviated・・・・・

379 means “Cleared for container release”, which is explained in Table 3.


710

shows an example of a web-browser page that converts the message in Figure 6. Additionally,

we have developed another page for providing procedure and movement status information,

with its history, as shown in Figure 8.

5. DISCUSSION ON THE IMPLICATIONS AND PROSPECTS FOR THE

DEVELOPMENT

5.1 System Architecture

As shown in Table 1, the system architecture for sharing procedure status information is

divided into three types. Each type has certain issues as follows:

One-to-one type: This type experiences scalability problems (Posti et al., 2011).

Every time it collaborates with a new system, it is necessary to decide the type of

Figure 7. An example of a web-browser page that shows the Figure 6 message Source: the authors

Figure 8. An example of a web-browser page that provides the procedure and movement

status information that corresponds to the Figure 7 data Source: the authors

Procedure status information

History of the data

Movement status information


711

electronic interface that should be applied.

Centralized type: All participants must agree on the management and operating

body of the centralized system (i.e., central database). Additionally, Srour et al.

(2008) point out that a strong party is needed to link with other parties.

Decentralized type: When updating or modifying the electronic interface, all

participants must agree. Namely, standardization is critical (Srour et al., 2008).

In the case of applying the one-to-one type in the sharing of procedure status

information among PCSs internationally, it would be difficult to expand the collaboration

network to many countries in a short period due to the necessity for negotiations with each

partner; when an operator of the one-to-one type expands the collaboration to other countries,

partners must discuss which type of electronic interface should be applied, and whether a new

electronic interface should be developed. This requires substantial amounts of time and effort.

In other words, this type has scalability problems.

In the case of applying the centralized type to sharing procedure status information

internationally, it would be difficult to agree upon the central management or the operating

body since multiple parties are involved in the procedures such as government authorities,

consignors, consignees, freight forwarders, ocean carriers, container terminal operators, and

trucking companies across countries. If the central management or operating body is chosen,

it would be necessary to have further discussion regarding the budget sustainability for

operating the centralized system. Therefore, it is necessary to set up a strong international

organization funded by stakeholders in all countries that are connected in the centralized

system. However, there is a study that implies the difficulty in establishing such a strong and

centralized organization. Sia Partners (2016) points out that many competing firms that use

the port of Hamburg are often very hesitant to share information with a central authority that

could aggregate this information with that of competitors. Taking this study into account, it is

not easy to establish a central organization.

Because of the aforementioned disadvantages of the one-to-one and centralized types,

we recommend the adoption of the decentralized type. The advantages of the decentralized

type are its scalability compared to the one-to-one type, and that, in terms of sharing, there is

no need to designate a central operating body for the IT system. Additionally, Posti et al.

(2011) and Srour et al. (2008) note that another advantage of the decentralized type is that

information is exchanged when needed (that is on demand); thus, only necessary data are

shared. Furthermore, from a cost or economic perspective, the decentralized type is better

than the other types. Using Table 1, in the case of the one-to-one type, the operator of system

A has to develop four patterns’ modules for sending/receiving messages to/from systems B-E.

The other operators of systems B to E also have to develop similar modules as system A. In

the case of the centralized type, primarily, a centralized system has to be developed.

Additionally, each system has to develop a module for sending/receiving messages to/from

the centralized system. In the case of the decentralized type, each system has to only develop

a module for sending/receiving messages to/from the other systems since there is only one

electronic interface among systems A to E. A summary of the total cost for the collaboration

of each type in the case of Table 1 is as follows: the one-to-one type would need to cover the

cost of twenty modules (four modules multiplied by five systems); the centralized type would

need to cover the cost of the centralized system and five modules (one module multiplied by

five systems); and the decentralized type would only need to cover the cost of five modules

(one module multiplied by five systems). It is obvious that the decentralized type has a cost

advantage compared to the other types. Note that, in addition to the above cost for the

development of the modules or centralized system, the coordination or negotiation cost is


712

necessary for the three types. On the other hand, the disadvantages of the decentralized type

are the necessity for guarantee of data synchronization and standardization of system.

Considering the advantages of the decentralized type and disadvantages of the other

types, there is a high probability that the decentralized type may become a mainstream of the

system architecture in the inter-system coordination of procedure status information across

countries. However, as more countries join the network, it would become more difficult to

reach a consensus on the electronic interface. In the system introduced in section 4, Japan, the

RoK, and the PRC were able to successfully agree on the electronic interface; however, it

might have been more difficult to reach an agreement if many countries had been involved.

This implies that when the geographical scope is expanded to other areas, reaching a

consensus on the electronic interface would become a future subject. Thus, standardization is

necessary to facilitate more involvement of stakeholders in other countries. For the

standardization, an organizational framework that supports continuous dialogue among

stakeholders across countries should be established. This requires time and effort, although it

might be easier than the establishment of a central management or operating body of the

centralized type. Note that new issues regarding the adoption of the decentralized type other

than the aforementioned ones could emerge in the future since, at present, there are only a few

studies or trial implementations on the decentralized type.

Additionally, the base technology concept of the system described in section 4 is

regarded as the Web Application Programming Interface (Web-API). The authors have

applied XML for the Web-API electronic interface in this system. However, recently, the

National Strategy office of Information and Communications Technology, Cabinet Secretariat

of Japan (2017) has recommended that JavaScript Object Notation (JSON) be applied to

Web-API electronic interfaces (This recommendation is for all business fields). To improve

the convenience for users of IT systems, it is important for developers to provide an electronic

interface that is easy to apply. XML can provide multiple functionalities compared to JSON;

however, the XML syntax rules (grammar) are complex compared to those of JSON. The

number of items of the shared data, which we discuss in section 4, is limited, so that the

adoption of JSON might have been suitable for the system described in section 4.

5.2 RFID

Considering the RFID issues identified in section 3, we do not apply RFID technology in the

system described in section 4. However, we would like to have further discussion on the

possibility of adopting RFID in sharing procedure status information based on its features,

including its merits and demerits.

RFID is an automatic recognition technology with wireless communication. It is

suitable for tracing goods since the data in RFID can be updated. Additionally, some types of

RFID readers can simultaneously read multiple RFID tags with non-contact. Furthermore,

some organizations are moving to standardize the specifications associated with RFID tags.

The international standards associated with the RFID tags in maritime fields are summarized

in Table 4.

On the other hand, metal and water affect the accuracy and capacity for receiving RFID

radio waves. Additionally, if RFID are applied in sharing procedure status information,

various issues, such as determining the responsibility for updating data in real time and

attaching as well as maintaining the RFID tags worldwide, must be addressed.

Thus, at present, it appears that it would be difficult to apply the RFID tags in sharing

procedure status information across countries. However, if they are used within a limited

scope, they could be adopted. For example, Will (2011) classifies the benefits of RFID tags


713

into four categories: data quality, inventory management, process efficiency, and security. To

clarify the benefits, he conducts a Delphi study by questioning experts. The results show that

the experts estimate a low degree of benefit in the areas of inventory management and

security. Conversely, they estimate a high degree of benefit in the areas of data quality and

process efficiency. Based on these results, the study focuses on introducing RFID to optimize

the transshipment process, such as in the ship-container terminal-truck/train, from the

viewpoint of movement status information. Will (2011) demonstrates the efficiency of this

introduction.

5.3 Adoption of EPCIS

Two issues regarding applying EPCIS in the sharing of status procedures information arise

from the development described in section 4. The first issue, strictly speaking, is that the

EPCIS standard was originally developed for the movement of goods (GS1 Japan, 2016), so

that the use of the procedure status information would be out of expectation. The second issue

is that the Electronic Product Code (EPC), which consists of identifier-codes standardized by

GS1, was supposed to be used for identifying goods in the EPCIS specification (GS1, 2007)10.

However, container terminal operators or ocean carriers do not use EPC to specify their goods

(i.e., containers).

To address the first issue, we introduce a design to input the procedure status

information into the movement status information data-field in the database since both

movement and procedure status information have the same meaning from the viewpoint of the

change in status. To address the second issue, we substitute container number for EPC, taking

into account the way of identifying the container by container terminal operators or ocean

carriers.

Additionally, based on discussions by the experts from the three countries, the

UN/CEFACT11 Recommendation 24 (Rec. 24), which is an international standard list for

trade and transport status codes (UN/CEFACT, 2017), has been adopted as the code for

expressing the procedure status information, such as the approval of customs clearance (i.e.,

we adopt Rec. 24 to “why,” which is described in section 4.2.1). We found suitable code

numbers for 1) and 2) written in section 4.1 in Rec. 24; however, there were no code numbers

regarding 3) and 4). Thus, the authors applied to the UN/CEFACT to add new status codes

regarding 3) and 4). The UN/CEFACT approved the proposal of adding the new codes to

UN/CEFACT Rec. 24 at the end of March 2017, and published the new code list in June 2017.

Table 5 shows the code used in this development, including the newly added code.

10 GS1 (2017) notes that EPCIS does not require the use of EPC. It seems that GS1 changes the stance of

the adoption of EPC from mandate to not-mandate. 11 UN/CEFACT is an abbreviation for the United Nations Centre for Trade Facilitation and Electronic

Business, which is a subsidiary intergovernmental body of the UNECE (the United Nations Economic

Commission for Europe) Committee on Trade.

Table 4. The international standards associated with RFID tags in maritime fields

The number of ISO Name

ISO 10891 Freight containers -Radio frequency identification (RFID) -

License plate tag

ISO 17363 Supply chain applications of RFID-Freight containers

ISO 18185 Freight containers-Electronic seals

ISO 18186 Freight containers-RFID cargo shipment tag system Source: https://www.iso.org/home.html (ISO)


714

To summarize, regarding the electronic interface, we verify that the EPCIS standard can

be used for sharing procedure status information; however, it is necessary to consider

modifying the standard to match the business procedure.

5.4 Mandatory Inputting Data for Requesting the Procedure Status Information

As shown in section 4.2.2, when system users request the data on containers, it is necessary to

input the container and B/L numbers. In the development shown in section 4.2, the B/L

number indicates an ocean B/L, issued by ocean carriers. However, in the case that consignors

or consignees outsource the shipping procedures to freight forwarders, the consignors or

consignees only know the house B/L number issued by the freight forwarders. Taking into

account that in most cases consignors or consignees outsource their shipping, including its

procedures to freight forwarders, easing the requirements for requesting data will be suitable

(i.e., either inputting the container or the B/L numbers), although that might heighten security

risks.

5.5 New Technology for Sharing Data –Blockchain–

In the development described in section 4, a decentralized type with a Web-API has been

adopted as the base technology. In addition to the Web-API, we explore the possibility of the

adoption of new technology, namely, blockchain. In recent years, blockchain is increasingly

becoming an emerging information technology for sharing data between stakeholders.

Blockchain can be defined as an immutable distributed ledger for recording transactions

between multiple participants maintained within a distributed network of participants (nodes).

When a transaction is noted, the blockchain entities execute a consensus protocol to validate

the transaction. Transaction information is grouped into blocks, and hash (cryptographic)

functions are attached to the blocks forming transactions chains (Lambrou et al., 2019). In

maritime fields, certain platform systems using blockchain have been developed, tested, and

launched. For example, TradeLens, which is a platform that enables the sharing of maritime

Table 5. The code applied to the IT system described in section 4

The status

numbers

written in

Figure 3

Code

numbers

of

Rec.24

Name of Rec.24 Descriptions of Rec.24

1) 10 Cleared by

agriculture, food, or

fisheries authorities

The goods/consignment/equipment/means

of transport has been cleared by

agriculture, food, or fisheries authorities.

2) 12 Cleared by customs The goods/consignment/equipment/means

of transport has been cleared by customs.

3) 378* Delivery Order Issued Delivery Order for the

goods/consignment/equipment/means has

been issued.

4) 379* Cleared for container

release

The procedures of containers’ release

from container yard have been cleared by

all authorities and private sectors.

* The authors applied to UN/CEFACT for new addition of these code in conjunction with the development

described in section 4.

Source: edited from the List of Trade Facilitation Recommendations N°. 24 (UN/CEFACT)


715

logistics’ documents such as B/L, certificates of origin, dangerous goods declaration, customs

declaration etc., and movement status information such as container gate out/in, has been

jointly developed by Maersk and IBM (TradeLens, 2019). The Global Shipping Business

Network (GSBN) is a platform which enables the sharing of immutable records with other

shipment stakeholders. GSBN is based on a consortium of nine companies, which include

ocean carriers (CMA CGM, COSCO, etc.), terminal operators (DP world, etc.), and a

software provider (CargoSmart) (CargoSmart, 2018). CargoX, which is a startup project, is a

platform focusing on the exchange of B/L (CargoX, 2019).

Regarding TradeLens, according to interviews with IBM Japan, the hash data, which are

calculated by documents or other data (e.g., certificates of origin), are shared on blockchain

nodes in the platform to ensure secure, auditable, and non-repudiation transactions. These

documents or data themselves are stored in the conventional database on the TradeLens

platform to share information between stakeholders. These documents or data are shared only

with business processing related parties, that is, access limitation is set. The blockchain nodes

are owned by ocean carriers and administrators of the platform. Participants other than the

ocean carriers can easily access the platform by using an API.

From a system architecture perspective, the encrypted data in TradeLens could be

categorized into the decentralized type in Table 1. The documents or data themselves in

TradeLens could be categorized into the centralized type in Table 1. Therefore, the TradeLens

platform might be regarded as a combination of the decentralized and centralized types.

Regarding other platforms, their system architectures have not been disclosed in detail on

their websites to date. However, considering that blockchain technology is adopted to their

systems, the architecture of the decentralized type could be applied to certain parts of their

platforms.

Considering the various types of existing and expected platforms using the blockchain

technology, sharing data with all stakeholders worldwide is difficult. To tackle this issue,

these platforms should be fully harmonized or have interoperability. Schmahl et al. (2019)

explain that the non-for-profit association that is planned to be set up by five major ocean

container carriers (CMA CGM, Hapag-Lloyd, Maersk, MSC, and Ocean Network Express) to

promote digitalization, standardization, and interoperability could help to develop a common

interface and an industry-wide ecosystem, if blockchain is among the digital solutions

considered. If it is realized, using the common electronic interface, the system architecture of

collaboration between the platforms could become the decentralized type in Table 1.

Considering the aforementioned situation, the decentralized system architecture is

becoming the trend in setting up systems for sharing data related to ocean containers.

5.6 Driver for Development from a Policy Perspective

From sections 5.1 to 5.5, implications are discussed from a technical viewpoint. In this

subsection, we discuss them from a policy perspective. When implementing the sharing of

information across countries, official agreements between countries (or ports across countries)

become a key driver. In the case of the Neal-Net (see section 3.1), it has been promoted under

the framework of Japan, the RoK, and the PRC’s ministerial conference on transport and

logistics (Iida and Shibasaki, 2016). Additionally, in the case of HiTS (see section 2.3), the

Fukuoka City Office and Hakata Port Terminal Co., Ltd., who operate and manage HiTS,

have concluded agreements on the memorandum of understanding (MOU) for sharing

procedure and movement status information with other ports (e.g., Fukuoka City Office,

2015).

In addition, it is necessary to establish an organization that can coordinate opinions


716

from members or participants of the network. In the case of Neal-Net, with the establishment

of the Neal-Net framework, the Neal-Net technical meeting has been organized by technical

experts from the three countries to discuss technical and engineering issues. Additionally, in

the case of Europe, which is described in section 3.1, the IPCSA plays a role in promoting

collaboration and coordinating opinions from members.

Considering the above, in the case that many participants or members collaborate or

share networks, it would be better to reach an official agreement, and establish or assign an

organization to coordinate opinions from members. If there is no such agreement or

organization, when issues arise, it might be difficult to reach an agreement or middle ground

on not only technical issues such as electronic interface but also basic plans, business

processes, and so on.

6. CONCLUSION

In this paper, we review the current situation and literature on sharing procedure status

information among PCSs across countries. After analyzing the system architecture for sharing

based on the literature review, we propose the adoption of a decentralized system architecture

without attaching RFID, and the development of an IT system for sharing information in real

time following the proposed architecture. Finally, we discuss the implications and prospects

through the implementation (development) and literature review. We conclude that, at present,

it is beneficial to apply decentralized system architecture in sharing procedure status

information among PCSs across countries in real time, without attaching devices such as

RFID tags. Additionally, other implications and prospects are summarized as follows: EPCIS

can be used for sharing procedure status information, although it is necessary to fix or modify

the standard when implementing it with a matching business process or practice; when

requesting data from other systems, the mandatory input data should be simplified for users’

convenience; some platforms that adopt blockchain technology are emerging, and the

decentralized type could be adopted to enable collaboration among such blockchain

platforms; and finally, in the case that many participants or members collaborate or share a

network, it would be better to reach an official agreement and establish or assign an

organization to coordinate opinions of members.

ACKNOWLEDGEMENT

The authors would like to thank Mitsui E&S Holdings Co., Ltd. for their cooperation in the

implementation of section 4.2.2 and section 4.2.3.

REFERENCES

Abe, M. (2015). Current status of SCM by Japanese firms and future direction of port

logistics service improvements. Technical Note of NILIM, No. 852. (in Japanese)

APEC (Asia-Pacific Economic Cooperation) Sub-Committee on Standards and Conformance,

APEC Committee on Trade and Investment (2012). APEC implementation for cargo status

information network for enhancing supply chain visibility, APEC#212-CT-03.1.

Baron, M. L., Mathieu, H. (2013). PCS interoperability in Europe: A market for PCS

operators? The International Journal of Logistics Management, 24(1), 117–129.


717

Boertien, N., Goedvolk, E-J., Hammink, E., Hulsebosch, B., Kolff, T., Koolwaaij, J., Linde,

M., Middelkoop, E., Oosterhout, M., Posthuma, P., Salden, W., Zandbelt, H. (2002).

Blueprint for a virtual port, an integrated view on next generation Internet in the Port of

Rotterdam. Virtuele Haven Consortium, June, 2002.

CargoSmart (2018). Top ocean carriers and terminal operators initiate blockchain consortium.

(https://www.cargosmart.ai/en/blog/top-ocean-carriers-and-terminal-operators-initiate-bloc

kchain-consortium/; Accessed February 26, 2019).

CargoX (2019). Smart B/L™ Features. (https://cargox.io/platform/Smart-BL/; Accessed

February 28, 2019).

Czyzowicz, W., Rybaczyk, M. (2017). Customs Enforcement Network (CEN) database

perspective: A case study. World Customs Journal, 11(1), 35–46.

Dakosy (2019). Dakosy (https://www.dakosy.de/en/; Accessed February 26, 2019).

Field, A. F. (2015). Port of NY and NJ inaugurates TIPS system. IHS Maritime and Trade.

Fukuoka City Office (2015). About the IT collaboration between Hakata port and Bangkok.

Press release (http://www.city.fukuoka.lg.jp/data/open/cnt/3/47926/1/hakatabankok.pdf;

Accessed July 30, 2018).

GS1 (2007). EPC Information Service (EPCIS) Version 1.0 Specification. GS1 Global Office,

Belgium

(https://www.gs1.org/sites/default/files/docs/epc/epcis_1_0-standard-20070412.pdf;

Accessed June 19, 2019).

GS1 (2014). EPC Information Service (EPICS) Version 1.1 Specification. GS1 Global Office,

Belgium (https://www.gs1.org/epcglobal; Accessed April 23, 2018).

GS1 (2017). EPCIS and CBV Implementation Guideline. GS1 Global Office, Belgium

(https://www.gs1.org/docs/epc/EPCIS_Guideline.pdf; Accessed February 21, 2019).

GS1 (2019). GS1 designated as Issuing Entity for Unique Device Identification (UDI) by the

European Commission.

(https://www.gs1.org/articles/2514/gs1-designated-issuing-entity-unique-device-identificat

ion-udi-by-european-commission; Accessed June 19, 2019).

GS1 Japan (2016). Visibility of Supply Chain by EPCIS.

(https://www.dsri.jp/standard/epc/pdf/guidebook201612.pdf; Accessed February 21, 2019).

Hakata Port Terminal Co., Ltd. (2018). HiTS ver.3: Container Information.

(http://www.hits-h.com/index.asp; Accessed April 23, 2018).

Heilig, L., Voß, S. (2017). Information systems in seaports: A categorization and overview.

Information Technology and Management, 18(3), 179–201.

Helo, P., Szekely, B. (2005). Logistics information systems: An analysis of software solutions

for supply chain co-ordination. Industrial Management & Data Systems, 105(1), 5–18.

Hesketh, D. (2010). Weaknesses in the supply chain: Who packed the box? World Customs

Journal，4(2), 3–20.

Iida, J., Shibasaki, R. (2016). Enhancement strategy for visualization of port logistics

information through domestic and international collaborations in case of Japan.

Proceedings of the 6th International Conference on Transportation and Logistics (T-LOG

2016), A-0042.

Iida, J., Watanabe, D., Nagata, K., Matsuda, M. (2018). The current situation and issues of

information systems for sharing procedure status information of ocean container across

countries. Japanese Association for Coastal Zone Studies, 31(1), 21–32. (in Japanese)

International Association of Ports and Harbors (IAPH) (2011). Port Community Systems

Benchmark survey.

International Organization for Standardization (ISO) (2018) (https://www.iso.org/home.html;

Accessed April 23, 2018).

https://www.cargosmart.ai/en/blog/top-ocean-carriers-and-terminal-operators-initiate-blockchain-consortium/

https://www.cargosmart.ai/en/blog/top-ocean-carriers-and-terminal-operators-initiate-blockchain-consortium/


718

International Port Community Systems Association (2018). Port Community Systems

(http://ipcsa.international/; Accessed April 23, 2018).

Korea Maritime Institute (2015). Logistics Information System in the Republic of Korea

–Port-MIS–, UNESCAP Expert Group Meeting held on December 10, 2015 (Bangkok)

(http://www.unescap.org/sites/default/files/06%20-%20PortMIS.pdf; Accessed April 23,

2018).

Lambrou, M., Watanabe, D., Iida, J. (2019). Maritime blockchains. decoding diverse

strategies for value extraction. Proceedings of IAME 2019, Paper ID 114.

LOGINK (2017). Introducing LOGINK (http://english.logink.org/col/col1852/index.html;

Accessed June 13, 2019).

LOGINK (2019). International Trade Products (http://english.logink.org/col/col1846/index.

html; Accessed June 13, 2019).

National Strategy Office of Information and Communications Technology, Cabinet

Secretariat of Japan (2017). API technical guidebook. (in Japanese)

Nippon Automated Cargo and Port Consolidated System, Inc. (NACCS) (2018). The

specifications for export and import and port-related information processing system

(https://bbs.naccscenter.com/naccs/dfw/web/system/ref_6nac/; Accessed April 23, 2018).

(in Japanese)

Morikawa, K. (2015). Issues and requirement on global supply chain. Strategic SCM, Union

of Japanese Scientists and Engineers, 251–258. (in Japanese)

Oghazi, P., Rad, F. F., Karlsson, S., Haftor, D. (2018). RFID and ERP systems in supply

chain management. European Journal of Management and Business Economics, 27(2),

171–182.

Lee, P. T. W., Cullinane, K. (2016). Dynamic Shipping and Port Development in the

Globalized Economy: Volume 2: Emerging Trends in Ports, Springer.

Portbase (2019). The port community system (https://www.portbase.com/en/; Accessed

February 26, 2019).

Port of Antwerp (2019). C-point (https://www.portofantwerp.com/en/my-poa/services/apcs;

Accessed February 26, 2019).

Posti, A., Hakkinen, J., Tapaninen, U. (2011). Promoting in-formation exchange with a port

community system – case Finland, HICL 2011 - Hamburg International Conference of

Logistics - Maritime Logistics and International Supply Chain Management, 453–473．

PSA Corporation Limited (2018). PORTNET (https://www.portnet.com/; Accessed April 23,

2018).

Pugliatti, L. (2011). Cloud single window: Legal implications of a new model of cross-border

single window. World Customs Journal, 5(2), 3–20.

SANKYU INC. (2018). SANKYU-Logistics Information CISS (Website) (https://webciss.

sankyu.co.jp/portal/e/own/index.asp?nc_id=; Accessed April 23, 2018).

Schmahl, A., Mohottala, S., Burchardi, K., Egloff, C., Govers, J., Chan, T., Giakoumelos, M.

(2019). Resolving the blockchain paradox in transportation and logistics. Boston

Consulting Group (http://image-src.bcg.com/Images/BCG-Resolving-the-Blockchain-

Paradox-in-Transportation-and-Logistic-Jan-2019_tcm56-212394.pdf; Accessed February

28, 2019).

Sia Partners (2016). The Internet of Things in Transportation: Port of Hamburg Case Study

(http://www.google.co.jp/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=2ahUKE

wjCgZe1wuXiAhUby4sBHXZQC0wQFjAAegQICRAC&url=http%3A%2F%2Ftransport.

sia-partners.com%2Fsites%2Fdefault%2Ffiles%2F5._insight_internet_of_things_in_transp

ortation.pdf&usg=AOvVaw3fvTJKi6xCGBMfRfpiqqMC; Accessed June 13, 2019).

Srour, F. J., Oosterhout, M. V., Baalen, P. V., Zoudwijk, R. (2008). Port community system


719

implementation: Lessons learned from an international scan. Presented at the

Transportation Research Board 87th Annual Meeting, 08-2041，2008．

TradeLens (2019). Solution Brief. (https://www.tradelens.com/wp-content/uploads/2018/12/

TradeLens-Solution-Brief_Edition-One.pdf; Accessed February 28, 2019).

UN Centre for Trade Facilitation and E-business (UN/CEFACT) (2017). List of Trade

Facilitation Recommendations N°. 21 to 24 (https://www.unece.org/tradewelcome/un-

centre-for-trade-facilitation-and-e-business-uncefact/outputs/cefactrecommendationsrec-in

dex/list-of-trade-facilitation-recommendations-n-21-to-24.html; Accessed April 23, 2018).

UN Centre for Trade Facilitation and Electronic business (UN/CEFACT) (2005).

Recommendation and Guidelines on establishing a Single Window: Recommendation 33.

Wang, J. J., Cheng, M. C. B. (2015). Mature hub ports in the free trade environment, the way

forward from a global supply chain perspective: An Asian case. Maritime Policy &

Management, 42(5), 436–458.

Will, T. (2011). RFID in Maritime container logistics –participant-specific benefits and

process optimization. Eul Verlag.

World Customs Organization (WCO) (2018). Customs Enforcement Network

(http://www.wcoomd.org/en/topics/enforcement-and-compliance/instruments-and-tools/ce

n-suite/cen.aspx; Accessed April 23, 2018).

Received March 14, 2019; Accepted August 14, 2019

Asian Transport Studies, Volume 5, Issue 4 (2019), 694–719

Documents