**3.3 Deployment of automated terminals at ports**

The unmanned and automated handling of cargo at container terminals is expected to increase productivity per worker, improve the working environment and safety, and reduce the effects of weather conditions such as fog and wind. On the other hand, the introduction of the system is not without its challenges, such as high initial investment costs, maintenance costs (e.g., power consumption), and coordination with trade unions. At the ECT Delta Terminal in the Port of Rotterdam, the world's first automated terminal, an Automated Guided Vehicle (AGV) and an Automated Stacking Crane (ASC) were introduced in 1993. However, the introduction of these systems did not proceed due to technical and economic problems and difficulties in coordinating with labor unions, and there were only a few cases until the mid-2000s. However, since the mid-2000s, and especially since the 2010s, the number of automated terminals has been increasing rapidly, with nearly 60 terminals worldwide having installed the system so far. The number of automated terminals has increased rapidly since the mid-2000s, especially in the last decade. **Table 4** summarizes the status of the introduction of automated terminals, focusing on the level of automation. The symbols in the table indicate: ◎: mainstream status with many cases of introduction, ○: diffusion stage with several cases of introduction, and △: early stage with limited cases of introduction. In the case of marshaling yards and land-side container handling, remote control and automation are the basic systems. On the other hand, the manned operation is the mainstream for quay cranes, and full automation has been introduced only recently in a limited number of cases. In the case of horizontal transport within the premises, although there is a high degree of automation, various types of cargo handling machines have been introduced, and the level of automation differs greatly between ports.

In Japan, AGVs and remote-controlled ASCs were introduced at the south side container terminal of Tobishima Pier in the port of Nagoya in December 2005, which


#### **Table 4.**

*The introduction of automated terminals with the level of automation.*

is a relatively early stage in international perspective, but it is the only automated terminal in Japan at present. Currently, efforts are being made to promote the introduction of remote-controlled ASCs, mainly at strategic international container ports, and to improve the efficiency and optimization of terminal operations by using AI-based on container cargo information.

## **4. A case study of PI and blockchain technology for smart ports**

In the following, a specific case study of a blockchain technology application, in a Logistics 4.0 Physical Internet environment, is explicated, as a representative system implementation for innovative, digital maritime logistics environments, with automated ships and terminals constituting flagship applications of Industry 4.0.

Three recent representative studies on the application of PI and BC in the supply chain are available [16–18]. Meyer et al. [16] proposed a conceptual framework for the exchange of value and physical assets in logistics networks that proposed a BC-based conceptual framework and provides a solution to the fundamental barrier of PI. As the main contribution, they identified barriers to transforming current logistics systems into PI networks through case studies. The key barriers included the creation of a network with equal participation, robustness of the framework, assurance of integrity and resilience, rewards in the operational process, and reliable data exchange. By further describing the key features of the technology, they discussed how the BC would address the barriers to PI adoption. They proposed Ethereum BC, implemented smart contracts based on the ERC721 standards11, and evaluated the transport process in PIs. The authors conclude that BC technology can solve the barriers in PI because it enables a reliable and secure exchange of value in an untrustworthy environment. The authors propose a PoS based BC environment in order to save computational resources. In the case of small-scale PIs, the proposed solution already works, but the scalability12 problem as a whole needs to be solved before PIs can be widely adopted.

Hassan et al. [17] presented a permitted BC architecture suitable for the integration of BC technology with PI. They discussed how to take advantage of the interoperability13 between two permitted BCs. They demonstrated the applicability and practicality of the PI architecture to be built on top of a permitted BC and presented a case study of its application. The authors pointed out the scalability of both BC and PI networks as an issue to be solved.

Tan et al. [18] presented a framework of green logistics based on BC to realize sustainable logistics by integrating IoT and big data. The authors propose a framework with seven layers: physical layer, perception layer, network layer, blockchain layer, management layer, application layer, and user layer. The authors pointed out three issues: data storage and transmission, implementation cost, and risk. Then, for future research, the authors suggested to focus on the following: (1) developing a way to effectively connect the physical and perceptual layers to collect logistics data, and

<sup>11</sup> ERC721 is a common standard for smart contracts proposed by Ethereum. The feature of ERC721 is that nonfungible tokens (NFTs) can be handled in smart contracts. By using the ERC721 standard, the ownership and transaction history of NFTs will be able to be recorded on Ethereum BC.

<sup>12</sup> Scalability is the possibility of expanding the functionality of a system, even if it is small at first.

<sup>13</sup> Interoperability refers to the ability to collaborate and interoperability between different BC platforms.

(2) designing an incentive mechanism to encourage logistics companies to participate in the BC platform.

In contrast to the various advantages of BC, this technology requires a transformation of digital systems. First, existing processes need to be digitized. Currently, there are many tasks in logistic operations that are done by hand on paper or on computers that are not connected to a network. In order to effectively accumulate and utilize data in these tasks, it is necessary to digitize the tasks themselves or use AI (e.g., Optical Character Reader) services to digitize them.

Next, in order to work with platforms such as BC, existing systems need to have a mechanism to use APIs14. In the logistics field, many existing systems are still based on EDI15, which supports only batch sending and receiving, while APIs support real-time sending and receiving. In the logistics sector, there are still many existing EDI-based systems; EDI supports only batch sending and receiving, while APIs support real-time sending and receiving, and the development cost is higher than APIs [3]. Making EDI-based core systems API compatible is an important task. The issue of standardization is important in the diffusion of APIs. At present, there is a bunch of standards at the level of international organizations, governments, and industries. Some of the standards conflict with each other. These standards need to be unified. Organizations like Digital Container Shipping Association (DCSA) help to expedite the process. DCSA aims to develop digital standards for the containership industry and has compiled and published electronic standards such as vessel schedules, port operations, and electronic B/Ls. The PoV should follow the standards and protocols published by DCSA. In addition, the API is an architectural style that can be easily manipulated and can flexibly respond to the unique standards of countries and industries, for example, 10-ft container, low floor chassis.

Munim et al. [19] identified the main challenges in the practical application of BC in the maritime sector as lack of standardization of data elements, lack of interoperability and scalability between systems, delay in legislation, lack of understanding of the technology, and lack of training facilities and materials. PiChain is facing the same challenges as it uses BC technology. In addition, it is necessary to solve the issues of attracting participating logistics companies and infrastructure development in the implementation of PI. The search for solutions to these issues remains a future task.

These previous studies pointed out the issues of scalability after conducting smallscale demonstrations. In this study, we propose a framework for building innovative Logistics 4.0 systems and applications to solve these issues.

#### **4.1 Scope of application**

We propose the following scope of application of BC technology in PI. PI contains three flows, namely physical (logistics) flow, information flow, and financial flow. BC technology is indispensable for two of the three flows: information flow and financial flow (**Figure 3**).

<sup>14</sup> API is an abbreviation for Application Programming Interface, which is a data exchange specification used by software components to exchange information with each other in real time.

<sup>15</sup> An abbreviation for Electronic Data Interchange, also known as "electronic data interchange," a technology that emerged in the 1970s and is mainly used for information interchange for electronic commerce between companies.

**Figure 3.**

*The scope of BC technology application in PI.*
