asian transport studies, volume 5, issue 4 (2019), 694–719
TRANSCRIPT
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).
Iida, J., et al. / Asian Transport Studies, Volume 5, Issue 4 (2019), 694–719.
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.
Iida, J., et al. / Asian Transport Studies, Volume 5, Issue 4 (2019), 694–719.
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.
Iida, J., et al. / Asian Transport Studies, Volume 5, Issue 4 (2019), 694–719.
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
Iida, J., et al. / Asian Transport Studies, Volume 5, Issue 4 (2019), 694–719.
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).
Iida, J., et al. / Asian Transport Studies, Volume 5, Issue 4 (2019), 694–719.
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?
Iida, J., et al. / Asian Transport Studies, Volume 5, Issue 4 (2019), 694–719.
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
Iida, J., et al. / Asian Transport Studies, Volume 5, Issue 4 (2019), 694–719.
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.
Iida, J., et al. / Asian Transport Studies, Volume 5, Issue 4 (2019), 694–719.
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
Iida, J., et al. / Asian Transport Studies, Volume 5, Issue 4 (2019), 694–719.
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.
Iida, J., et al. / Asian Transport Studies, Volume 5, Issue 4 (2019), 694–719.
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
Iida, J., et al. / Asian Transport Studies, Volume 5, Issue 4 (2019), 694–719.
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.
Iida, J., et al. / Asian Transport Studies, Volume 5, Issue 4 (2019), 694–719.
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】
2) Customs clearance
Iida, J., et al. / Asian Transport Studies, Volume 5, Issue 4 (2019), 694–719.
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
Iida, J., et al. / Asian Transport Studies, Volume 5, Issue 4 (2019), 694–719.
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
2) Customs clearance
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
Iida, J., et al. / Asian Transport Studies, Volume 5, Issue 4 (2019), 694–719.
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.
Iida, J., et al. / Asian Transport Studies, Volume 5, Issue 4 (2019), 694–719.
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
Iida, J., et al. / Asian Transport Studies, Volume 5, Issue 4 (2019), 694–719.
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
Iida, J., et al. / Asian Transport Studies, Volume 5, Issue 4 (2019), 694–719.
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
Iida, J., et al. / Asian Transport Studies, Volume 5, Issue 4 (2019), 694–719.
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)
Iida, J., et al. / Asian Transport Studies, Volume 5, Issue 4 (2019), 694–719.
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)
Iida, J., et al. / Asian Transport Studies, Volume 5, Issue 4 (2019), 694–719.
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
Iida, J., et al. / Asian Transport Studies, Volume 5, Issue 4 (2019), 694–719.
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.
Iida, J., et al. / Asian Transport Studies, Volume 5, Issue 4 (2019), 694–719.
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).
Iida, J., et al. / Asian Transport Studies, Volume 5, Issue 4 (2019), 694–719.
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
Iida, J., et al. / Asian Transport Studies, Volume 5, Issue 4 (2019), 694–719.
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