Space Assets in the Physical Internet

(1)

A preliminary design study of the Physical Internet Communication Infrastructure

Nick Moesker

A thesis presented for the degree of Master of Science: Technology and Operations management &

Supply Chain Management First supervisor: Dr. N. B. Szirbik

Second supervisor: Dr. G. Heron External supervisor: O. Becu MSc Faculty of Economics and Business

University of Groningen The Netherlands

(2)

Abstract

(3)

List of Figures

1 Classification model of Intelligent Products. Source: Meyer et al. (2009) . . . 11

2 Enabling technologies model . . . 16

3 Design Science Research cycle. Source: Hevner and Chatterjee (2010). . . 18

4 The Modulushca Common Data Model or Colored Data Model. Source: Modulshca (2018). . . 22

5 Multi-level container interaction. Source: Sallez et al. (2016) . . . 24

6 Multi-level π-container activeness. Source: Sallez et al. (2016) . . . 25

7 Position of LP ULTRA WAN in the matrix of energy consumption and cov-erage. Source: ESA (2016) . . . 30

8 Agent Based Model with a remote cloud layer . . . 34

9 Theoretical model . . . 38

10 Hierarcy of Function A.-1: Physical Internet Context Functions . . . 39

11 Interaction Diagram of function A.-1: Physical Internet context functions . . 40

12 Hierarchy of function A.0: Decision making and Control . . . 42

13 Interaction Diagram of function A.0: Decision making and control . . . 42

14 Interaction between physical and digital elements of the Physical Internet . . 43

15 Hierarchy of function A.2: Transfer information . . . 44

16 Interaction Diagram of function A.2: Transfer information . . . 45

17 Modes of communication for function A.2.2: Execute and control transfer . . 45

18 Interaction Diagram of function A.2.2: Execute and control transfer . . . 46

19 Hierarchy of function A3: Monitor and control container . . . 48

20 Interaction Diagram of Function A.3: Monitor and control container . . . 48

21 Time line for the implementation of the Physical Internet . . . 57

22 Alternative Functional Architecture for function A.0: Decision making & Con-trol . . . 69

(6)

List of Tables

1 Characteristics of current and future terrestrial networks. Source: Cremers and Diedenhoven (2018) . . . 14 2 Types of data and their required bandwidth. Source: European Space Agency

(7)

1 Introduction

“The way physical objects are moved, handled, stored, realised, supplied and used throughout the world is not sustainable economically, environmentally and socially” (Montreuil et al., 2010, p.8). The author challenges this problem by introducing the Physical Internet (PI, or π): an innovation in logistics which is based on the working principles of the digital Internet. The author envisages an internet-like network for goods where no data is encapsulated in data packets, but goods are encapsulated in PI-containers. Furthermore, PI-containers are routed through the network via PI-hubs, like data packets are routed through the internet by routers. These are just a few analogous examples of the interactions within the PI where modular containers will autonomously find their optimal path through the network by latching and unlatching to and from other modular PI-containers in an automated fashion. Autonomous reasoning capabilities will enable PI-containers to find their optimal route, to engage in auctions, to report on their status, and so forth.

Autonomous reasoning requires the containers to have computational capabilities and to be connected to the internet in order to access the required decision making data. Since the PI is still an envisaged system, no such communication infrastructure (CI) for PI containers exists yet. Therefore, research on the communication functionality of PI-containers is required to take the envisaged system a step further towards implementation.

Although the PI is a novel concept, some informational aspects of PI have been covered in literature. Sallez et al. (2015) identified informational aspects related to π-containers, elab-orated on the activeness of the containers, and proposed a communication hierarchy within a π-container. Also, a study by Sallez et al. (2016) explored the activeness of π-containers. That is, whether containers should be passive, monitor conditions, make decisions, or that the whole fleet should be self-organised. Furthermore, the fields of telecommunication and cloud computing are highly related to the PI, yet have not been studied in relation to each other. Therefore, telecommunication and cloud computing are central topics within the research.

In this paper, Design Science Research (DSR) is used to develop a preliminary and high level functional architecture for the PI Communication Infrastructure (PI-CI), based on cloud computing and various telecommunication technologies such as Narrow-band IoT, satellite communication, and mesh networking. DSR is used as a research method to reconcile academic findings and findings from practice into an abstract functional architecture. Case studies at the European Space Agency (ESA) are input to the empirical findings, which are reconciled with academic findings from a literature review within the field of PI, in order to answer the research question that was presented by ESA:

(8)

The validation of the preliminary high level functional architecture is performed by means of a validation workshop with telecommunication technical officers at ESA. By doing so, this paper contributes to literature by presenting an Agent Based Model approach for the PI with a remote cloud layer and a physical layer. It also concludes on the necessity of real-time continuous communication in critical zones of the PI. Contributions to practice are centred around the presented time-line for the implementation of various PI functionality, which gives direction to technological research and development, and to novel use cases for logistics companies.

(9)

2 Theoretical Background

The theoretical background section will elaborate on the two main theoretical cornerstones of the paper. First, the Physical Internet is elaborated on, then, communication infrastructure literature is explored. The intersection of the first two concept areas is key in developing the preliminary design and the requirements for a PI-CI design. This is further clarified by means of the enabling technology framework, which is presented at the end of this section.

2.1 Physical Internet

Terms that are used within the paradigm of PI are amongst others: next-generation logitics, intelligent product or intelligent logistics, Holonic and Multi-Agents Systems, Cyber Physical Systems (CPS), or Physical Internet (Borangiu et al., 2016). Physical Internet will be used as a descriptive term in this paper.

2.1.1 Physical Internet and Self-organising Logistics Systems

PI is further elaborated on by dividing it into four foundational principles: Decentralisation, Openness, Modularity, and Autonomy and Automation. Then, the informational aspect of PI is explored.

Autonomy and Automation Montreuil et al. (2012) indicate that containers should be capable of interacting with other π-containers, devices, carriers, and virtual agents to select their optimal route. In other words, π-containers should have autonomous reasoning capa-bilities. A French research project called PI-NUTS is currently studying this informational aspect of containers. Rahimi et al. (2016) propose a framework which distinguishes between the level and location of intelligence for the π-containers. Futhermore, Sallez et al. (2016) propose an autonomy solution in the Holonic paradigm, in which every container consists of the head, which is the informational part, and a body, which is the physical part. The au-thors propose that the first transport container to be loaded on a -carrier proposes a grouping for other transport containers. The degree of activeness of containers is intersting since it will greatly influence the requirements for the PI-CI. Lastly, the concept of Autonomy is introduced to indicate the high degree of automation within the PI. According to Montreuil (2011), the PI generalises unloading, storage, and loading operations in a smart automated and/or human-assisted way. Therefore, highly automated π-hubs will greatly depend on instructions, which is also an informational an communicational concept within the PI.

(10)

under-mine managerial predictability and work routines”. Decentralisation is therefore a critical concept to consider within the PI. Montreuil (2011) indicates that the PI should exploit the Internet of Things (IoT) to enable distributed self-control of objects through the supply networks. However, Choi et al. (2001) indicate that too much control detracts from inno-vation and flexibility. Therefore, the systems could benefit from functioning with rules and protocols. This thought is further developed by Borangiu et al. (2016), they determined that rule-based decentralised control within SoLS helps to avoid unpredictability and undesirable outcomes, and leads the individual agents in the system toward a system-wide common goal. Decentralisation does not necessarily mean that decisions are made within the container, in-stead, they can also be made in the cloud by an agent that represents a physical container. In the first case, decentralisation is likely to influence the intensiveness of the communication with π-containers since decisions require information that should be sent to and from the container.

Openness Montreuil et al. (2012, p.26) define openness as “the accessibility, willingness and availability of actors and networks to deal with any actor or network”. More explicitly, the author describes that all actors in the PI have to implement and exploit PI components in an open way, so that other actors can use the service. Therefore, it is not a private, nor a closed or member-only system. The result is that organisations will not be limited to the transportation assets that they own, or where they have long-term contracts in place (Mon-treuil et al., 2012). The openness of the system could for example influence the availability of data for actors in the system, which is related to the π-CI.

Modularity The possibility of latching multiple containers together to create a trans-portable unit is referred to as modularity. It is proposed by Montreuil et al. (2010) to create containers with dimensions of combinations of 0.12m, 0.24m, 0.36m, 0.48m, 0.6m, 1.2m, 2.4m, 3.6m, 4.8m, 6m, 12m and 18m. The interlocking capability of the modules enables the creation of a transportable container. A more recent publication by Montreuil et al. (2015) proposes the use of Packaging, Holding, and Transport containers. Transport containers are the equivalent of current shipping containers. They are filled with multiple Holing con-tainers, which can be seen as the current equivalent of boxes and crates. Lastly, Packaging Containers is the equivalent of product packaging.

2.1.2 Informational aspects of the Physical Internet

(11)

et al., 2015). A related concept is a Multi Agent System, in which physical components are represented by a virtual Agent.

An approach to handle data of π-containers in an interconnected logistics scenario is pre-sented by Tretola et al. (2015). A common Data Model is proposed based on the Modulshca project (Modulshca, 2018). The authors propose message-based communication within the Physical Internet in a generalised format: XML (eXtensible Markup Language). One of the expected results of the Modulshca project is "providing a clear information handling approach, including data consistency and transport monitoring along the journey as model contributing to extend and enhance standardization developments in eFreight and iCargo” (Modulshca, 2018). eFright is a paperless logistics initiative (Modulshca, 2018). iCargo is a research project that aims to develop an ecosystem of systems that enables interoperability and cooperation between logistics services and information systems. This paper will draw on these sources of literature to support the choices made in the design phase.

2.1.3 π-container activeness

(12)

Figure 1: Classification model of Intelligent Products. Source: Meyer et al. (2009)

2.1.4 Decentralised Control of π-containers

The PI will consist of numerous π-containers, hubs, and transporters that have to be con-trolled to let the system work. Such a system can be described as a large-scale system, since it cannot be controlled by using one-shot approaches (Bakule, 2008). The reason that the systems are hard to control is that they are too large and the problems to be solved are too complex by for example only increasing computing power (Bakule, 2008). The dimen-sionality of the system is one of the well-known reasons of complexity. It is also mentioned by Bakule (2008) that a system is considered large-scale if analysis or synthesis needs to be partitioned into manageable sub-problems. As a result of this partitioning, the system is not longer controlled by a single controller, but instead by several independent controllers that together form a decentralised controller. In the case of the PI, containers are controlled via a network. According to Bakule (2014), communication and control are related, namely by Networked Control Systems (NCS). The author describes a NCS as spatially distributed components that may operate in an asynchronous manner. Their operation is coordinated in some way, however, to achieve the desired overall objective. One of the advantages of a decentralised system is the reliability. Since the system does not rely on a central controller, it is less likely that the whole system fails as a result of a failing controller. In a decentralised system, the failure of a single decentralised controller does not affect the whole system (Cai and Mitra, 2010).

(13)

1. Identification: Each π-container should have a unique worldwide identifier.

2. Traceability and tracking: The π-management system should be able to locate each π-container and to trace status, arrival and departure times, and environmental con-ditions.

3. State Monitoring: Monitoring of the condition and data integrity of the cargo. For example, obtaining legal information, the respect of the cold chain, or monitoring the opening of the container to prevent theft.

4. Data compatibility and interoperability: To coordinate containers and actors, PI coor-dinators should be able to communicate through a heterogeneous information system. 5. Confidentiality: π-containers should be treated as black-boxes. The content should

only be known by the authorized parties.

Furthermore, Sallez et al. (2015) indicate that π-containers should also contain some commu-nicational and decisional capabilities. Communication is necessary for traceability, condition monitoring, and compatibility checking between containers. Furthermore, decision capabil-ities are needed to let π-containers make decisions autonomously about their optimal route through the π-network.

2.2 Communication Infrastructure for the PI

This section elaborates on the second cornerstone of the research: communication infras-tructure (CI). It does so by making a distinction between the physical infrasinfras-tructure such as receivers and transmitters, and protocols and models, which are non-physical components.

2.2.1 Physical Communication Infrastructure

To allow π-containers to play an active role in the PI, they should be able to communicate (Montreuil, 2011). Logically, containers should be equipped with devices to send and receive data. Then, obviously, the containers should be connected to an infrastructure that allows the containers to connect to the digital internet. This section first covers the container-side infrastructure, and then covers both terrestrial and space based infrastructure.

(14)

ubiquitous connectivity of the actors. In the same line of thought, the Modulushca (Modu-lar Logistics Units in Shared Co-modal Networks) Project proposes to equip containers with communication technologies such as Zigbee, EnOcean, or LoRaWAN (Modulshca, 2018). Within the shipping industry, there are already applications of connected containers present. Maersk Line, which is one of the largest shipping companies in the world, is already equip-ping specific containers with communication technology. The so called reefer containers, or refrigerated containers, continuously monitor the status of the container and the cooling system. A modem in the container is able to communicate to a gateway on the ship, which in turn communicates via a satellite link. This application offers monitoring and follow ups to their repair vendors (Churchill, 2016).

The extent to which π-containers require intelligence also depends on the location where data will be processed. This phenomenon is related to Cloud Computing and Edge Computing. Obviously, if all the containers are continuously sending all their information to the cloud for processing, this would strain the communication infrastructure significantly. Edge computing is a concept that takes care of this issue by pushing intelligence and processing capabilities further to the edge of the network (Ai et al., 2017). This in turn reduces the amount of data that has to be sent to the cloud and improves the response time, or latency. The difference between Edge computing and Fog computing is that Edge computing pushes the intelligence to one node at the edge of the network, and Fog computing pushes the intelligence to multiple nodes at the Local Area Network (LAN) level (Ai et al., 2017).

(15)

Table 1: Characteristics of current and future terrestrial networks. Source: Cremers and Diedenhoven (2018)

Generation 4G 5G

Status Fully operational To be operational world-wide in 2025 Technology Narrow band IoT Enhanced

mo-bile broadband Ultra-reliable low latency communication Massive ma-chine type communication Coverage Extreme coverage

and deep penetra-tion Extreme cover-age Density Density of 1m devices per km2

Battery life Up to 15 years Up to 10 years

Costs Few euro’s per de-vice

Few euro’s per device

Space based infrastructure Current PI-literature does not provide any evidence of re-search into connectivity in remote locations such as on the ocean. Satellite Communication, for example via the Iridium network (Iridium, 2018), could be a suitable solution to this problem. A next generation constellation of 66 cross-linked satellites in Low-Earth Orbit (LEO) is being launched at the time of writing, enabling real-time 100 percent coverage around the world. Furthermore, amongst others, Samsung and SpaceX are also planning to launch satellite constellation to provide word wide internet connections up to broadband speeds. Therefore, satellite communication (SatCom) will be one of the relevant space assets for the PI.

Satellite navigation (SatNav) could be one of the most likely techniques to track the location of π-containers. Multiple satellite constellations like GPS (US) GLONASS (Russia), COM-PASS (China), and Galileo (Europe) in Medium Earth Orbit (MEO) could possibly be used to provide the system with positioning data.

(16)

2.2.2 Dedicated models and protocols for the PI Communication Infrastructure Apart from the physical aspects, models and protocols are needed to enable the elements in a system to communicate information with each other (Lundin et al., 1996). A communication protocol can be seen as a formal language that is specified for transmitting devices that enables them to communicate (Persson and Håkansson, 2015). This is also related to the informational aspect of the PI that has been introduced in section 2.1.2.

MODULUSHCA One of the expected outcomes of the already introduced Modulshca project is a common data model to be used within the PI that enables interoperability, or hyperconnectivity between logistics services and information systems. Since this is obviously critical to the PI, the details of this project will be used within the research.

Cloud Computing Persson and Håkansson (2015) introduce the concept of cloud com-puting within cyber phsical systems. Not only can a cloud environment provide a place to store system data, it can also be used for more heavy computations. By doing so, the authors mention that "local systems can be rather small in size, which will make implementation easier and save physical space" (Persson and Håkansson, 2015). This could be an interesting concept for the PI, since containers would not require complex hardware by using cloud computing. Since the cloud computing requires an internet connection, it is mentioned by the authors that in case of a malfunction in the Internet, the system requires offline data management. Thus, a copy of essential information should be stored on the local device, so that it can be utilised when cloud access is restricted.

Block Chain Technology According to (Hofman et al., 2017), Smart Contracts based on Block chain Technology (BCT) can be used within the PI to enable hyperconnectivity. All stakeholders with a certain role would have immediate access to status data about for example a container, because of immediate synchronisation in near real time across entities. Block chain could potentially offer a safe common data model since it is a distributed system and is making extensive use of cryptography.

2.3 Enabling technologies framework

(17)

(18)

3 Methodology

To answer the research question concerning the role of space assets in the Physical Internet, it is divided into sub questions. This section will elaborate on the research questions, research design, data gathering, and data analysis, which is used to answer the research question.

3.1 Research questions

The research question is as follows:

What could be the role of space assets in the envisioned Physical Internet Communication Infrastructure?

To properly answer this question, it is divided into sub questions:

1. What is a suitable preliminary design of the Physical Internet Communication Infras-tructure?

(a) What are the requirements for a PI-CI design?

(b) What interaction takes place between PI-components?

2. What space based technologies could be used in the Physical Internet Communication Infrastructure?

(a) What relevant space asset based technologies are used or expected to be used by 2050?

(b) Are the space asset based technologies likely to be capable of handling the PI-CI requirements?

3.2 Research Design

(19)

Figure 3: Design Science Research cycle. Source: Hevner and Chatterjee (2010).

Szirbik (2018) introduced four steps for a DSR project which is related to existing systems which are applicable to the case studies at ESA:

1. Observing the industrial systems via case studies

2. Reverse engineer the architectures of the systems observed in practice and identify the critical aspects

3. Validating these generic architectures and their critical aspects by more similar case studies

4. (Optional) Continuously searching for new cases and new contexts via surveys.

Furthermore, Szirbik (2018) also introduced four steps in a DSR project related to envisaged systems wich are applicable to the PI literature review:

1. Reviewing the existing literature about the envisaged system

2. Envisaging novel use cases, scenarios, and the physical architectures to support future systems

3. Creating and evaluating functional architectures, making virtual reality models, testing simulations of the future systems

4. Identifying new critical aspects and encourage engineering disciplines to find solutions - which are published and open the door for new use cases.

(20)

3.3 Data and requirements collection

Data and requirements collection refers to step one of both processed described above. Ob-serving the industrial systems via case studies is done by explorative interviews which are used to collect data and requirements from relevant existing projects by ESA. Three projects related to SatCom and logistics have been selected to collect data and requirements about the communications aspects for the PI. This small number of case studies does not enable one to make generalisations, however, in this early stage, it does provide the research with valuable information for initial high level designs.

For the PI requirements collection, the Design Science approach for an envisaged system is used. Therefore, a literature study is used as suggested by Szirbik (2018): Reviewing the existing literature about the envisaged system.

3.4 Data and requirements analysis

The second step in the Design Science process for existing systems as proposed by Szirbik (2018) is to reverse engineer architectures of existing systems that have been observed in practice to identify the critical success factors. These critical success factors that are der-rived from the ESA projects will be input for the next phase. Furthermore, the third step concerns validating the generic architectures and their critical success factors my more simi-lar case studies, which is realised by performing four case studies at ESA concerning satellite communication.

For the envisaged PI system, novel use cases have to be envisaged, scenarios have to be developed and physical architectures have to be designed for the envisaged system. This is done by means of an analysis and evaluation of the critical success from both the existing systems and the envisaged system in respectively section 4 and 5. A functional Architecture of the Physical Internet Communication Infrastructure, based on this analysis and evaluation is developed in section 6, as suggested as the third step in the Design Science process for envisaged systems (Szirbik, 2018).

3.5 Design validation

(21)

engineering disciplines to find solutions - which are published and open the door for new use cases.

(22)

4 Analysis of relevant applications of architectures and

systems

Design Science is a process of combining new and existing knowledge from both the environ-ment and the Knowledge Base by means of the relevance and the rigour cycle (Hevner and Chatterjee, 2010). The theoretical background gave an introduction into the topics of the Physical Internet and Communication Infrastructure. This analysis section will continue to complement the needed information for the design cycle by looking into the Knowledge Base and the Environment, as suggested by Hevner and Chatterjee (2010). The environment may consist of relevant applications of systems and architectures that can be valuable for the new design. This section first reports on relevant applications of architectures by looking into literature, and then looks at relevant applications of systems in ESA projects. Every review and case study will result in a set of CSFs of the application that will be used in the design phase.

4.1 Relevant applications of existing architectures

Within PI literature, several authors made an effort to conceptualise parts of the PI that are related to the communication infrastructure. These architectures are discussed in this subsection.

4.1.1 Literature review 1: Physical Internet

The concept of the PI was already elaborated upon in the theoretical background section. The Critical Requirements for the PI, which are CSFs for the system, are summed up below. 1. Decentralisation: The PI should be able to function without significant intervention of a centralised control system. (Montreuil, 2011; Borangiu et al., 2016). This incurs that there will be numerous autonomous agents that have to work together and thus communicate.

2. Openness: This is also referred to as data compatibility and interoperability. All actors in the system should be able to deal with any other actor in the network by means of heterogeneous information systems (Montreuil et al., 2012; Sallez et al., 2016).

3. Autonomy: Also referred to as decision capabilities. π-Containers should be capable of interacting with other actors in the network to select their optimal route, or optimise handling and sorting at π-hubs (Montreuil et al., 2012; Sallez et al., 2016).

(23)

5. Traceability and Tracking: The location of π-containers should be known, along with status information, arrival and departure dates, environmental conditions, information on legal agreements, status of the cold chain, and information on the opening of the container (Montreuil et al., 2012; Sallez et al., 2016).

6. Continuous communication: To enable traceability and condition monitoring, contain-ers should be equipped with communication abilities. Also, π-containcontain-ers should be able to do compatibility checking for transport and storage purposes (Sallez et al., 2016). These functions require the container to be connected to the internet all the time.

4.1.2 Literature review 2: MODULUSHCA

The MODULUSHCA project, short for Modular Logistics Units in Shared Comodal Net-works, was to contribute to the development of interconnected logistics at the European Level, in close collaboration with the Phisical Internet project. One of the five working fields of the project regards the establishment of digital interconnectivity of the units.

The MODULUSHCA project assumes that there will be one type of active container, namely the MBox, that is equipped with devices (RFID, or other IoT) and/or a Universal Unique IDentifyer (UUID) like a QR code or a Bar Code. The project proposed a Common Data Model, which presented in figure 4.

(24)

Within the Common Data Model, four data categories are present. The green category possesses information that is required to handle the container in the system, while the yellow, orange, and red categories possess information that is not directly needed to handle the container within the system. Therefore, the authors propose that only the data in the green category is present at the container level, while all the data is available in a distributed database at the cloud level. Although the authors do not mention this, this construction releases strain from the communication infrastructure. Namely, this data does not have to be sent to and from the container, but instead exists in the cloud. This idea is also shared by Sallez et al. (2016), as they mention that the cost of reading the large flow of data, which is required to achieve real-time information is still too high for widespread adoption.

For tracking purposes, the project proposes a "Russian Doll" approach. This means that only the carrier will be tracked. Since it is known which container is located on which carrier, the location of every container will be known.

It is interesting to see the contrast between the MODULUSHCA project, which has a rather centralised view with a rather inactive container, and the view of Sallez et al. (2016), which considers the role of a PI-container as more active in terms of management and operations of the system. Also, for example, they propose to implement intelligence such as defining new goals, adapting current goals, communicating with other containers, and learning form individual and collective experience (Sallez et al., 2016).

Critical Success Factors

1. Only carrying data at the container level that is needed to handle the container will reduce strain on the communication infrastructure. Other information can be stored remotely.

2. Tracking with the Russian doll approach could simplify the system.

4.1.3 Literature review 3: Container Activeness

Sallez et al. (2016) take as a starting point that by increasing the communicational and descicional capabilities of π-containers, they can play an active role in the management of the Physical Internet. Therefore, the PI is to exploit the capabilities of smart containers connected to the Internet of Thing (Sallez et al., 2016). The authors propose a descriptive framework on the activeness of those π-containers.

(25)

scheduled reporting and event triggering, which can be classified as problem notification in the model of Meyer et al. (2009). It is mentioned that in further stages, more complex decision making intelligence from the third level can be implemented. Some examples are defining new goals or adapting to current goals, communicating with other containers, negotiating with handling and routing agents, and learning from experience.

This descriptive framework assumes three levels of π-containers: the transport container, the handling container, and the packaging container. The hierarchical interaction between these levels is presented in figure 5.

Figure 5: Multi-level container interaction. Source: Sallez et al. (2016)

(26)

Figure 6: Multi-level π-container activeness. Source: Sallez et al. (2016)

One of the active roles that is described is forming a composite transport container from multiple modular π-containers. The first container to arrive at a transportation truck can become the initiator and proposes a composition to other containers. Other containers can answer and the initiating container consequently takes the decision.

1. Digital agents can be used to represent physical containers.

(27)

4.2 Relevant applications of existing systems

This section reports on the relevant systems or architectures that can be found in the en-vironment to complement the information which is needed for the design phase. For this phase, projects from the ESA ARTES program are used. ESA’s Advanced Research in Telecommunications Systems (ARTES) programme transforms research and development investment into successful commercial products. Interviews with multiple technical officers and managers from the ARTES program resulted in the following case studies:

4.2.1 Case study 1: Satellite Monitoring for Logistics Safety: SaMoLoSa, ESA Satellite Monitoring for Logistics Safety (SaMoLoSa) is a demonstration project for monitor-ing critical parameters durmonitor-ing the transportation of hazardous goods in unpowered rail tank cars and inter modal tank containers. The absence of both power and an odometer makes it difficult to monitor the state of the assets and to plan maintenance properly. The project has aimed to develop a product and a complementary service to monitor the transport of dangerous goods on the one hand, and to improve the maintenance process on the other hand. Safety, risk reduction and operational cost reduction have been the main drivers of this project.

The device that enables this service is a small, battery powered, ATEX certified device that is mounted to the rail car. The device allows to connect different sensors, such as temperature, pressure, and shock sensors. Furthermore, GNSS is used to report on the location of the asset. The data is sent to the service by means of an energy efficient unidirectional Globalstar satellite link. If the device enters a more crowded area where a higher messaging frequency is required, a terrestrial technology called Sigfox is used. This Low-Power Wide-Area Network (LPWAN) technology enables the device to communicate more frequent while consuming very little energy.

Duplex communication This application is equipped with simplex communication since information has to flow in only one direction. This is a big advantage from the energy consumption point of view since duplex communication would consume more energy. Com-munication technology has been one of the most important design choices since it influences the battery life significantly. There were only few technologies that provided low-power satellite communication. This application ended up using Globalstar.

"Although it is technically possible to have duplex communication, it would in-crease the energy consumption by a factor of more than two since the complexity of the system will increase" (Vieira, 2018).

(28)

opportunity to such applications. Furthermore, another potentially interesting technology was mentioned:

"In the future, sat IoT, can be an opportunity for such applications" (Vieira, 2018)

Mesh Network The concept of a Mesh Network is simply a network of interconnected nodes that has redundant network paths and therefore enhances the reliability (Kim et al., 2008). In this application this concept has been considered. In this case, multiple devices would connect to each other, and one central gateway would then connect to a terrestrial network or satellite.

"This has been discussed in the development phase, but mesh networks tend to be inefficient from an energy point of view" (Vieira, 2018).

This is confirmed by Kim et al. (2008) in their prototype as they found that energy-efficiency is a key gating factor to the implementation of battery-powered mesh network devices for tracking purposes.

Rail-car containers have a maintenance interval of multiple years, therefore, the device bat-tery should last for at least this period of time, which centres most design choices around battery life. It was indicated however that mesh networks could be a great opportunity for containers which are stacked. "In the case of shipping containers, the time that a con-ventional container is in transit barely exceeds 4 weeks, and therefore the batteries could be charged more frequently, given that the charging infrastructure is there" (Vieira, 2018). Another argument for equipping all individual assets with connection capabilities is that individual assets can get lost. Also, "shipping containers sometimes go overboard" (Vieira, 2018), which is an important point to consider in the design of the Physical Internet.

Explosion safety (ATEX) The last design choice is centred around explosion safety. "This is imposing certain rules for design choices" (Vieira, 2018). In explosive atmospheres, only equipment with an ATEX certification can be used. This is one of the reasons that GSM technology cannot be used since GSM signals have the power to ignite explosive atmo-spheres. The Sigfox technology is very low-power and is therefore suitable to be used within ATEX zones. This is an important factor to consider in designing the Physical Internet Communication Infrastructure, since is is possible that explosive goods are carried within PI containers.

(29)

1. Simplex communication is very energy efficient, duplex will significantly increase energy usage.

2. Terrestrial Low-Power Wide-Area Networks which are used for the IoT are even more energy efficient and very suitable for the application.

3. Space based IoT networks could be an interesting solution to energy efficient duplex communication.

4. Battery life should match either the maintenance interval or the interval in which containers can be charged.

5. Mesh Networks could potentially form a solution to stacks of containers that are not able to connect to conventional networks. The energy consumption will however in-crease.

6. ATEX certifications could be needed if goods with an explosive atmosphere are trans-ported. Therefore, GSM cannot be used since it is not ATEX certified.

7. Containers do sometimes fall overboard, therefore, it would be convenient if the con-tainer can still be located if it is on its own.

4.2.2 Case study 2: Real Time Intelligent Cargo Monitoring, ESA

RTICM, short for Real Time Intelligent Cargo Monitoring, is a completed demonstration project by ESA which concerns the design, development and demonstration of a monitoring and control platform for multi modal transportation. It especially focuses on high value containers that are transported by air, road, rail, and sea. The project aims at providing the stakeholders with better awareness tools to take near-real-time actions to reduce losses and to increase the efficiency of the supply chain. This project involves both a tracking device and a platform for monitoring and tracking cargo. In contrast to the SaMoLoSa project, this project involves duplex communication instead of unidirectional communication. Also, RTICM is meant for the transportation of high value goods in any container (>e50.000 per container), whereas SaMoLoSa is mainly meant to track dangerous goods in unpowered rail cars. This project can be relevant to the Physical Internet Communication Infrastructure since it involves communication to and from containers by both terrestrial networks and satellites.

(30)

and is twice as expensive as the first device. This device takes the same measurements as the first device, but has the ability to connect more sensors by means of a Wireless Sensor Network (WSN). Furthermore, this device is using satellite communication to send its data to the platform. The devices can operate multiple months up till multiple years on one battery, depending on the settings.

Stacked Containers In the case that containers are stacked, or loaded into the hull of a ship, both terrestrial and satellite connections are likely to fail. "This problem is mitigated by an algorithm to detect when the container is loaded onto the ship. Then, AIS is used to track the ship instead of the container. Monitoring Data is being stored and sent as soon as there is a connection when the container is unloaded" (Tomassini, 2018). With this solution, customers are still able to track the location of their containers. Within the demonstration project, "there have been no customers that demanded continuous access to the sensor readings from the container" (Tomassini, 2018). Also, if there was a demand, it is probably not worth the investment.

"If continuous readings are really necessary, for example with the transport of medicine, other means of transport would be preferred" (Tomassini, 2018).

Continuous connection could be necessary for the Physical Internet since the containers must be able to continuously make decisions. The same problems as described above would appear if containers would be loaded onto an air plane. In this case, other problems that emerge are that most transmitting devices are not allowed in an air plane and not all batteries are allowed to be on an air plane.

Iridium The Mobilbox is equipped with an Iridium modem that enables the device to have duplex satellite communication. The choice for Iridium is justified by the requirements for the device in terms of length and type of messages that have to be sent, the reliability, and the price. Furthermore, the Iridium transceiver modems are efficient in size and weight, which enables the device to be as small and lightweight as possible. The choice for duplex communication is made because the device should know whether or not the message has been received by the platform. To do so, a confirmation is sent back to the device. Furthermore, the devices are configurable over the air. This feature allows the owner to set the messaging frequency and the type of readings to be sent.

(31)

1. Wireless Sensor Network to connect multiple sensors to the same device.

2. Different Narrow Band technologies are not commonly available in all countries, GSM technology is.

3. Not all types of batteries and transmitters can be used in air plane transportation. 4. In most cases, it is not needed to have communication while a container is on a ship.

Communication while the container is unloaded could also be sufficient in most cases. 5. Using an algorithm that determines that the container is loaded onto a ship, and using AIS data is a solution to track containers while they are not able to connect to a network.

4.2.3 Case study 3: SatApps, ESA

SatApps is a completed feasibility study by ESA in which satellite IoT communication is studied. Terrestrial IoT solutions are cost efficient on the device side but expensive on the network side since a large number of masts, antennas and related devices are needed. IoT communication via satellite, which is also referred to as Low-Power Ultra Wide-Area Network (LP Ultra WAN) or Satellite for Machine to Machine (SAT4M2M), could be a solution to this problem. The gap that currently exists in the matrix of energy consumption and coverage could be covered by this new technology, as presented in figure 7.

(32)

In this feasibility study, a number of stakeholders from industry have been interviewed to determine the critical requirements for this system. It can be noted that the requirements that resulted are similar to the requirements of the Physical Internet Communication Infras-tructure, namely:

1. Global 24/7 availability and service (in a first step at least trans-continental) 2. Extreme low communication cost

3. Very small bandwidth per sensor

4. Extreme low available energy at the sensor device/energy-autonomous operation 5. Harsh environmental conditions

6. Highest level of demand of data security

Compatibility Technology that is used here is compatible with the terrestrial IoT net-works. That is, SatApps is using the same frequency of 868MHz as the terrestrial LoRa network to send very small messages. Therefore, devices that are designed for terrestrial use are compatible with the satellite connection that SatApps offers.

"We bring terrestrial connections to space. So the technologies are to be compat-ible" (Schumacher, 2018).

It does so by using larger antennas in space to pick up the signals. SatApps should be available starting from 2020. In the meantime, there is a large competition going on in the market of space based IoT networks.

"Around 20 companies are competing in this ’space race’" (Schumacher, 2018).

Coverage Although SatApps can deliver a very cost effective solution, it is not designed for real-time communication. A constellation of 10 micro satellites will be used to connect ground devices to the network, however, the ground devices will not continuously have a satellite available to send data to. "It can take a few minutes before a satellite passes the device" (Schumacher, 2018).

Remote areas SatApps is mainly focussing on a specific type of users, namely users that are in remote areas where no terrestrial networks are available. It does so because terrestrial networks are better suited to cover dense populated area’s:

"A high density of signals can cause the signals to get saturated before it reaches space" (Schumacher, 2018).

(33)

Energy usage Although nowadays the energy usage of space based IoT is still higher than terrestrial IoT, this is expected to change in the near future. Space based IoT solutions can last up to 5 years on one battery, whereas terrestrial IoT solutions can last up to 15 years. By using new technology and larger antennas in space, it is expected that the energy usage at the device level will be reduced and that terrestrial and space technology will require similar amounts of energy.

1. Continuous coverage, which is not provided by all space based providers, is considered important for the PI.

2. Low-Power Ultra Wide-Area Networks are filling the gap that currently exists for IoT networks in remote locations.

3. In areas where the device density is very high, terrestrial networks are preferred over satellite based networks, since signals can get saturated before they reach the satellite in space.

4. Energy efficiency should not be considered as a problem for space IoT devices, since in the future the devices can last up to 15 years.

4.2.4 Case study 4: Satellite Communication in general

Within satellite communication, there are some general design choices to take into account while designing and developing an application (European Space Agency, 2018). Those design choices are listed below and interpreted and listed as critical success factors for the use in the Physical Internet:

1. Geographical requirements: The coverage should be world-wide to ensure that π-containers can be operated world-wide.

2. Communication Link: A two-way communication link will be needed to enable the container to report on its status and to acquire data for, or from decision making, depending on the location of the intelligence (Sallez et al., 2016).

(34)

Category Throughput Typical application

Basic 10bps - 10 kbps Message transfer, SMS, Machine-to-machine communication, SCADA, remote monitoring Low bit rate 10 - 100 kbps Voice, fax, email, basic internet

(low graphic content webpages) Basic Broadband 100-3000 kbps Internet, multimedia

Broadband 3-10 Mbps Terrestrial quality Internet and multimedia

upper-end broadband 10 - 50 Mbps Terrestrial quality fast Internet and multimedia

Table 2: Types of data and their required bandwidth. Source: European Space Agency (2018)

It is most likely that the messages to be sent will be of the Basic type, consuming around 10kbps to 10kbps. This is also referred to as Machine-to-Machine communication. This is however the case for single containers. A set of containers communicating through one channel would result in a greater throughput.

4. Volume of data to transfer: The total volume of data to be transferred determines the total strain on the communication infrastructure. This will determine the feasibility of millions of containers that are communicating.

5. Latency: The latency for Geostationary Orbit (GEO) satellites is 250ms, 55-80ms for Medium Earth Orbit (MEO) and 3,5-15ms for Low Earth Orbit (LEO). The system should be designed so that it can operate with the latency that is chosen.

6. Continuous Coverage: Some satellites pass over only in certain times, therefore, no continuous connection is possible. There are also satellite constellations, which offer continuous coverage.

7. Data Loss: The acceptability of losing data, for example in cases of heavy rainfall. 8. Costs: Costs range from $200 for simple modems up to $20,000 for aeronautical

(35)

5 Evaluation of the critical success factors

After the derivation of CSFs from relevant applications of systems and architectures, this subsection will evaluate the CSFs and combine them into themes that will play a central role in the design phase. For the process of creating categories, a coding tree is used which can be found in appendix A.

5.1 Decentralised control by autonomous agents

Π-containers should be capable of interacting with other actors in the network in a decen-tralised manner to select their optimal route, or to optimise handling and sorting at π-hubs (Montreuil et al., 2012; Sallez et al., 2016). Furthermore, the PI should be able to function without significant intervention of a centralised control system. (Montreuil, 2011; Borangiu et al., 2016). Sallez et al. (2016) introduced the idea of an agent that represents the physical container in the digital world. Agents are able to work within a digital environment, not needing to connect to physical containers first to get into contact. Giordano et al. (2016) refer to these systems as Cyber Physical Systems (CPS). "CPS are combinations of physical entities controlled by software systems to accomplish specified tasks under stringent real-time and physical constraints" (Giordano et al., 2016, p. 115). In line with Sallez et al. (2016), Giordano et al. (2016) metion that the complexity of a CPS and the large number of elements that are involved make data analysis and operation planning very difficult. Therefore, the authors also introduce the approach to use a physical layer and a remote (cloud) layer, so that the latter can produce a suitable operation plan. This principle is depicted in figure 8.

(36)

The concept of using an agent for every container has the advantage that only data that is essential to handle the container is needed at the container. That is, all data which is not directly needed at the container can be stored in the agent, which can be located remotely in the cloud. The advantage that comes with this concept of the digital twin is that only a small message has to be sent over the network, instead of all information that is required to take a decision. This in turn decreases the strain on the communication infrastructure. All complex system interactions between agents will then happen in the cloud, where all the information is centralised. In this concept, it would also be possible to equip the container with an identifier only, which is used to retrieve information from the digital agent. This is however likely to reduce the reliability of the system since it will then heavily depend on the internet. That is, some actions such as compatibility checking should probably still (also) happen within the container to ensure a proper and safe working of the system.

5.1.1 X-ability: Continuous communication

Within systems design, an x-ability is an ability of a system that is critical to ensure a correct working of the system. From this analysis chapter, it follows that continuous communica-tion, or non-interruptability of the communication channels is such an X-ability. Namely, decentralised control by autonomous agents requires a continuous connection to the internet, since the processing of this CPS is done in a remote layer. This remote layer is proposed to keep the hardware in the container, and therefore the energy usage, at a minimum. Also, compatibility checking heavily depends on this continuous connection. Giordano et al. (2016) mentions that a CPS with a physical and a remote layer cannot be applied when there are constraints in response time, for example, when a system needs to react fast to critical events. "Communication lag and remote processing can cause delays that a system simply cannot bear" (Giordano et al., 2016, p.116). This confirms that the X-ability of this system is continuous communication.

5.2 Location monitoring using the Russian doll approach

(37)

5.3 Internet of Things communication channels

A two-way communication link will be required to enable the container to report on its status and to acquire data for or from decision making, depending on the location of the intelligence (Sallez et al., 2016). In current systems that require bidirectional communication world-wide, GSM technology is used because narrow band technologies are not commonly available world-wide. GSM technology is not the most energy efficient technology, nor does it comply to the ATEX certification. It would therefore be beneficial to use a commonly available IoT narrowband technology like 5G in the future. Multiple companies are in the race to launch satellite constellations for Space IoT networks. These so-called Low-Power Ultra Wide-Area Networks would be able to provide world-wide IoT coverage from space. However, in densely populated areas, terrestrial networks are still preferred since signals can get saturated before they reach the satellite in such areas.

5.4 Mesh communication channels

The way that containers connect to a satellite or terrestrial network is not always straight-forward. Containers can be out of reach if they are composed into a composite container or when they are loaded into a ship or plane. A solution within one of the ESA projects was a Mesh Network, in which each device can connect to its neighbour device. This way, containers can always find a route to a container that is connected to the internet. Using Mesh Networks will however increase energy usage.

5.5 Simple π-container Hardware

If the concept of the agent based model is chosen, it will not be necessary to equip the con-tainer with extensive computing power. Instead, it should be able to receive basic messages such as its next destination so that the next hub knows where it should be going. Further-more, the container should be able to send its monitoring data back. Since a composite container will mostly exist of multiple π-containers, it would be redundant to equip every π-container with satellite communication devices. Since π-containers are either at a carrier, a hub, or a smart rack, it would be more logical to connect to one of these components, which is in turn connected to the internet.

(38)

5.6 Communication Infrastructure hardware for World-Wide

com-munication

Apart from the devices at the container level, the rest of the infrastructure on the ground and in space also has come critical requirements. Firstly, to ensure a continuous connection, the networks should work world-wide. This means that a constellation of satellites should be able to cover the whole planet continuously, like in case of the Iridium constellation. The Low-Power Ultra Wide-Area Network is a promising technology that should be able to cover these requirements. In densely populated areas, terrestrial networks are preferred since it prevents signals from getting saturated before they reach the satellite. Secondly, the technology that is used should be energy efficient, because, needless to say, charging or replacing batteries in containers should be kept to a minimum to reduce operational costs and to increase availability.

5.7 Low energy and battery usage

One-way communication, also referred to as simplex communication, is more energy efficient than two-way or duplex communication. However, in the PI it is expected that duplex communication is needed because containers should be able to receive instructions on their routing and for example on what data to monitor. With the introduction of space based IoT networks, energy usage is expected to reduce to levels comparable with terrestrial IoT networks. It is likely that the devices will last multiple years. Nevertheless, batteries will have to be either charged or replaced some time. Replacing batteries is likely to be required since certain types of rechargeable batteries are not allowed to go on board air planes.

5.8 Theoretical model of the conceptual fields

(39)

(40)

6 Preliminary high-level design of a π-Communication

Infrastructure Functional Architecture

The analysis and evaluation in the previous sections examined previous work from the knowl-edge base and existing systems from the environment that are related to communication within the Physical Internet. After having analysed both the Knowledge Base and the Environment, the two can be combined to design a General Architecture as suggested by Hevner and Chatterjee (2010). This section takes the evaluation as a starting point and starts building the Functional Architecture in a top-down manner. Hierarchical diagrams and interaction diagrams in the IDEF0 modelling language are used to depict the system. To be able to cover the main design decisions, first the higher level context functions are covered.

6.1 Function A.-1: Perform Physical Internet context functions

The first function A-1 is modelled to show the context of the focal A.0 function. This function, which is depicted in figure 10 performs several PI functions which are modelled as very broad functions to show the interactions between the A.0 function and its sibling functions. In this model, function A.-11 Environmental functions delivers environmental decision support information to the A.0 function. This could be information on for example traffic and weather, which can impact the PI system. Furthermore, function A.-12 Economic functions handles customer orders and monitors the market, so that the A.0 function can take decisions based on this information. The focal A.0 function concerns the Decision Making and Control of the Physical Internet. This function actually provides the instructions for containers, hubs, and carriers to ensure a proper working of the system.

(41)

The interaction between A.0 and both A.11 and A.-12 is straightforward. External phenom-ena such as the weather, the economy and the PI system form the controls for all functions. The data of the environmental and economic function form the decision control inputs for the A.0 function.

(42)

6.2 Function A.0: Decision making and Control

Initially, the focal function was intended to be the Transfer Information function since this research mainly centres around communication. However, since this function is closely in-terrelated with the Monitoring and Control function, it is required to make Decision Making and Control the focal function A.0. Many of the design choices that are made in the A.3 Decision Making and Control function influence the A.2 Transfer Information function.

(43)

Figure 12: Hierarchy of function A.0: Decision making and Control

(44)

The Agent Based Model (ABM) approach as discussed in the analysis section would suit this functional architecture well since every container can still act as a decentralised unit as proposed by Montreuil et al. (2012), while container hardware and communication is kept at a minimum. In the case of an ABM, the container Agent would fulfil the A.1 Take Decisions function in the remote cloud layer, the communication infrastructure would fulfil the A.2 Transfer Information function and the π-containers would fulfil the A.3 Monitor and Control container function in the physical layer.

It is proposed to represent every physical actor in the PI by an Agent in the cloud. This concept is visualised by means of figure 14. This digital twin will take care of the complex system interactions between the actors. Container Agents might fulfil tasks such as bidding on shipments, arranging new compositions with other containers, and booking a spot on a specific carrier. Also, π-carriers can be represented by an Agent. The Digital Twin of a truck can for example accept containers or take in the bidding process. By fulfilling these computationally heavy tasks that require a vast amount of communication amongst Agents, the physical container hardware can be capt at a minimum while reducing the communi-cation to and from the physical container, thus reducing the strain on the communicommuni-cation infrastructure. Not without importance, human interaction is present in this diagram, since human actors such as border control can interact physically with containers. It would make the most sense to communicate about these actions directly to the agent via the Digital Internet, instead of via the container. Lastly, human decision making might still be part of the PI. Container owners might want containers to operate in a certain area for example. Also in this case, it would make sense to communicate directly to the Agents.

(45)

6.3 Function A.1: Take decisions

The decision making function determines what the optimal path for each container is, or what suitable customers are (Horst, 2018). While the functions A.2 Transfer Information and A.3 Monitor and Control container are interrelated in terms of the functional design, function A.1 Take decisions does not directly influence the functional design. Therefore, this function is mentioned in the design but further left out of scope.

6.4 Function A.2: Transfer information

Transferring information is an integral part of the PI-CI. Decisions that are made by the agent in the remote layer should be communicated to the container in the physical layer. Any actor in the π-system can then read the instructions from the container. Besides sending data to the container, transferring information is also required to get monitoring data from the container. Hence, a two way communication channel is required.

The mode selector function A.2.1 Choose channel selects the most appropriate communi-cation channel based on the available and preferred networks as described in the analysis section. The actual transfer is performed by function. A.2.2: Execute transfer, as modelled in figure 15. Its inputs and outputs are straightforward and modelled in figure 16. The third and last function A.2.3: Check transfer, makes sure that the messages are transferred to prevent communication failures. The transfer via terrestrial or satellite networks are straightforward. However, the transfer via a mesh network is added. This function provides the possibility to connect to a terrestrial or satellite network through a (set of) neighbouring containers. This functionality is needed for cases where containers are packed together and are therefore unable to connect to neither terrestrial nor satellite networks. The three modes that can be selected by the mode selector function A.2.1 is modelled in figure 17.

(46)

Figure 16: Interaction Diagram of function A.2: Transfer information

(47)

Figure 18: Interaction Diagram of function A.2.2: Execute and control transfer

Design Decision 2: Means of communication From the analysis is section, it became obvious that a mix of terrestrial and satellite connections is required to provide a continu-ous connection. Furthermore, a mesh network could provide a communication channel for containers that are on the bottom of a stack and therefore have no connection to neither terrestrial nor satellite networks. This mesh networking functionality however seems to in-crease the energy usage and complexity of the container devices. An inin-crease in energy usage creates the demand for a π-container charging infrastructure.

(48)

reasons, it is assumed that the connection should be non-interruptible.

Components At the lowest level of a Functional Architecture, components can be dedi-cated to the functions. In this case it is fairly straightforward which components should be dedicated to each function. From the analysis section it also became clear what technology is relevant to these components.

All functions within the A.2 function could be executed by one communication device. The integral parts are the transceiver and the processing unit. Decisions should be made about which channel to use and to check whether or not the transfer has been successful. The trans-mission could be performed by means of an Narrow Band IoT transceiver that is compatible with the 5G standard. As described in the analysis section, terrestrial Narrow Band IoT technology will most likely be compatible with Space Based IoT technology. Therefore, the transceiver should comply to this standard to ensure a good integration between terrestrial and space technology.

6.5 Function A3: Monitor and Control container

(49)

Figure 19: Hierarchy of function A3: Monitor and control container

(50)

Design Decision 3: Redundant on-board compatibility checking Compatibility checking should make sure that a combination of containers does not result in dangerous situations. In principle, the agents in the cloud layer will make sure that non-compatible containers are not put together. However, to ensure a safe operation, it would be an option to also perform compatibility checking at the container in the physical layer. This redundant system can prevent non-compatible containers from being put together in case of a loss of connection. The container can signal the π-handler in case of a non-compatibility error. The alternative design would be to not include this functionality at the physical layer, however, this could result in dangerous situations.

Components Again, at the lowest level of the functional architecture, components can be allocated to the functions. For function A.3.1: Monitor conditions, location, and compatibil-ity, a device like the Visioboxx or the Mobilbox from the RTICM project would be required. These devices can monitor conditions and the location. The mesh network functionality of the containers can possibly be used to take care of the compatibility checking functionality. Furthermore, simple rule-based decisions have to be made about the compatibility, therefore, a simple processing unit would be required. In the case of RTICM, simple decisions can be taken within the device. Lastly, containers should be able to communicate to the hub. Mesh networking and RFID would be suitable to fulfil this requirement.

Space Assets in the Physical Internet

Abstract

Contents

List of Figures

List of Tables

1

Introduction

2

Theoretical Background

2.1

Physical Internet

2.2

Communication Infrastructure for the PI

2.3

Enabling technologies framework

3

Methodology

3.1

Research questions

3.2

Research Design

3.3

Data and requirements collection

3.4

Data and requirements analysis

3.5

Design validation

4

Analysis of relevant applications of architectures and

systems

4.1

Relevant applications of existing architectures

4.2

Relevant applications of existing systems

5

Evaluation of the critical success factors

5.1

Decentralised control by autonomous agents

5.2

Location monitoring using the Russian doll approach

5.3

Internet of Things communication channels

5.4

Mesh communication channels

5.5

Simple π-container Hardware

5.6

Communication Infrastructure hardware for World-Wide

com-munication

5.7

Low energy and battery usage

5.8

Theoretical model of the conceptual fields

6

Preliminary high-level design of a π-Communication

Infrastructure Functional Architecture

6.1

Function A.-1: Perform Physical Internet context functions

6.2

Function A.0: Decision making and Control

6.3

Function A.1: Take decisions

6.4

Function A.2: Transfer information

6.5

Function A3: Monitor and Control container