A Common Data Model for the Physical Internet

Transcription

1 A Common Data Model for the Physical Internet Giancarlo Tretola 1, Viviana Verdino 1 and Dario Biggi 2 1. Meware S.r.l., Rome, Italy 2. Poste Italiane, Rome, Italy Corresponding author: giancarlo.tretola@meware.it Abstract: In this paper the authors describe the activities executed during the Modulushca project, for defining a common set of data and information, to be used in handling modular units in a structured logistic network. The inspiring principles for defining the data model has been the Canonical Data Model (CDM), an Enterprise Applications Integrations (EAI) pattern and the e- Freight management of data exchange. The idea is to have a common and shared format which to translate to and from the messages to be exchanged between the participants. Moreover, the authors defined roles and access rights for the participants to the modular logistics scenario. This work covers, then, the issue related to data exchange in order to enable interoperability exploiting modular containers. Authors, during the Modulushca project presented the architecture for managing the processes related to modular logistics, using the defined Common Data Model. Keywords: Modular logistics, interconnected shared network, intermodal, data sharing, modular logistics conceptual approach. 1 Introduction In this paper we propose the definition of a conceptual model for the management of the information related to the handling of modular units, i.e. the M-Boxes, as they have been defined in the Modulushca project (Modulushca). The M-Boxes and the data model are a possible contribution to the definition of an approach for achieving the Physical Internet (Montreuil 2013, Montreuil, Ballot and Meller 2014). The focus here will be at the operational level, of the logistics, i.e. the handling of the boxes, the shipments/consignments, the related processes and the information needed. The proposed data model focuses on supporting the Information Technology (IT) protocols for handling all unitised movements from source-to-sink, considering the handling of the M-Boxes in the operations of pick-up and drop-off and the reverse logistic for the empty boxes delivered within a business process, using a structured network, with a common carrier approach across multimodal logistics domains. In the handling of the M-Boxes, reverse logistics is particularly important, in order to reduce or avoid empty trips along the links between the logistics nodes. The repositioning of the M-Boxes, also, have to be considered, in order to enable full M-box operability. Regarding the handling of modular units, their internal contents and the stacking/order arrangement, we use a black-box approach, considering as driving model the encapsulation principle defined in the physical internet. The encapsulation principle is inspired to the digital internet handling of the information, the internet does not transmit data: simply transmits packets. The information inside the packet is not used during transmission, it is handled by original sender and final receiver of the packets only and are the "payload" of the packet. Packets are routed, through the digital internet, using only the header information. The Physical Internet encapsulates physical objects in physical packets. Similarly to the digital internet, handling of the M-Boxes is realized using the associated data model, which constitutes the "header" of the physical packets. In our proposed approach we

2 aim at only considering nominal declaration of good s type and nature, i.e. the information needed for handling the M-boxes are available, without the need to open them. The remaining of the document is organized as follow: section 2 covers the related work of interest; section 3 describes what is needed for achieving modular logistics, from data exchange point of view; section 4 presents the data model as defined during Modulushca Project; section 5 presents the conclusion about the presented idea. 2 Related work Physical Internet Initiative (Montreuil 2013, Montreuil, Ballot and Meller 2014) is a major supply chain project that has the potential of changing the way we handle, store, package and transport goods across the supply chain. Basically the researchers involved in the Physical Internet (PI) wondered whether supply chain professionals could use the digital Internet as a metaphor for a new way to move physical objects through the supply chain (Montreuil 2011). In the same way of the seven-layer Open Systems Interconnection model of the Digital Internet, Montreuil (et al., 2012) proposes an Open Logistics Interconnection (OLI) model to structure the interconnected logistics services for easing the conceptualization, the implementation and the deployment of the Physical Internet. The first project to be considered is Modulushca, related to the Physical Internet initiative and aimed at enabling interconnected logistics, using modular container (M-Boxes), digital interconnectivity of systems with modular container. The final goal is to provide a basis for an interconnected logistics system for The key enabler is the development & use of modular logistics units of sizes adequate for real modal and co-modal flows of fast-moving consumer goods (FMCG). This paper is based on the activities the authors performed in the project. icargo is a very relevant research project for the modular logistics concepts. It aims to identify an ecosystem of services that enable cooperation and interoperability between information systems and logistics services. In icargo the objective of defining a service ecosystem approach is pursued through Service Oriented Architecture (SOA), in which Information and Communication Technologies (ICT) services, in the virtual space, make available the features realized by logistics services, in the real world. The e-freight project represents another interesting work for the modular logistics. e-freight project has defined the Common Framework, which allow goods tracing in real time, ensures intermodal liability promoting clean freight transport, by creation and deployment of a single transport document in electronic form (electronic waybill), and an appropriate framework for the deployment of tracking and tracing technologies (RFID, etc.). Moreover it ensures that liability regimes promote rail, waterborne and intermodal transport. In the sequent parts of the work the relevant aspects of e- Freight are considered. FreightWise s overall objective is to support the modal shift of cargo flows from road to intermodal transport using road in combination with short sea shipping, inland waterways and rail. It will achieve this objective by means of improved management and facilitation of information access and exchange between large and small, public and private stakeholders across all business sectors and transport modes. ARKTRANS represents the basis on which FreightWise has been developed. It produced a user manual from which it is possible to understand how to describe framework architectures. Frame.net provides information through a website on the European Intelligent Transport Systems (ITS) architecture. It develops information tools from which it is possible to learn communication elements. KonSULT is relevant for the format of multilevel guidelines it developed in a guidebook for supporting intermodal transport.

3 SmartFreight is aimed at making urban freight transport more efficient, environmentally friendly and safe by answering to challenges related to traffic management, freight distribution management, and a better coordination. A technology to be considered is the XML (extensible Markup Language). In logistics there are XML for purchase orders, shipping notices, and invoices. Developing and maintaining multiple versions of common business documents like purchase orders and invoices is a major duplication of effort. Creating and maintaining multiple adapters to enable trading relationships across domain boundaries is an even greater effort. The need to support an arbitrary number of XML formats makes tools more expensive and trained workers harder to find. The OASIS Universal Business Language (UBL) is intended to help solve these problems by defining a generic XML interchange format for business documents that can be extended to meet the requirements of particular industries. UBL schemas are modular, reusable, and extensible in XML-aware ways. In order to allow the interaction between the different logistic systems, from an IT architecture point of view, without the need for each participants of implementing specific adapters to everyone systems we intend to use the Canonical Data Model (CDM) approach, an Enterprise Application Integration pattern (Hohpe 2003). This approach allows minimizing dependencies when integrating applications that use different data formats. Figure 1. Canonical Data Model Integration Pattern The approach is based on the design of a common data model (inspired by the Canonical Data Model) that is independent from any specific application. It requires that each application that want to interact with all the others, have only to be able to produce and consume messages in the common format. Sending a message means translating the info from the own system format to the common one. Receiving a message means translating the info from the common format to the own system format. In the e-freight framework (Cane 2012), one of the crucial parts is the establishment of a solid interoperability base on which the different stakeholders would be able to flawlessly communicate and exchange data. The e-freight domain is facing with two perspectives of the paperless transportation initiative: the data integration challenges that exist in the message exchanging process of the system and the use of Web services. Each one of the freight actors uses his own message standard, which means that the descriptions of domain concepts from the various parties are not aligned to each other. This means we have a many-to-many communication between parties that are not using the same language to exchange information. If we assume that there already exist m parties (Figure 2), then, in the most complex case, m*(m-1) transformation mechanisms would be needed for establishing that communication among them. Furthermore, for any new party, there would be a need to create m transformations for all the former parties towards the new one and m new transformation formulas from the new one towards the existing parties. The problem of heterogeneity in the communication between the different parties could be addressed by the introduction of a meta-model, which would be responsible for the bridging and interoperability between the different message standards. The proposed meta-model is the e-freight Ontology, which describes the concepts in the freight domain, and the relations between them. The

4 concept is shown in the Figure 3. Collaboration, is favoured, by the fact that each partner have to provide only on component for translating to and from the common model. P 1 P m P 2 P 5 P 3 P 4 Figure 2. Interaction with m partners The ontology will be the connection point between the various parties as a global reference model, acting as a common language. In this way only 2*m total transformation mechanisms (i.e. for each party, one from XML to Ontology instance and another one for the opposite direction) are needed instead of the m*(m-1). P 1 P m P 2 e-freight ontology P 5 P 3 P 4 Figure 3. Interaction between m partners using a common ontology For each party, one transformation is needed to transform the XML message into an ontology instance (a process called lifting). Another transformation is needed to transform from an ontology instance (in RDF/XML syntax) into the XML message (called lowering). A relevant element of the efreight Architecture is the EAP: efreight Access Point (Bento 2012). An EAP is a single point of access (more than a HUB) with the following characterization: globally addressable; secure; independent from semantics or applications; independent from vendor or provider and simple and easy to use. Generally an Access Points (AP) allows parties to communicate securely and reliably using electronic messages without the need for a centralised platform. The concept is analogous to , in which the user simply creates a message from relevant data, enters the destination address and presses send. In exactly the same way, a network of APs is responsible for transporting messages to the right destination through the internet. An e Freight Access Point (EAP) is an Access Point that has been adapted specifically for the needs of the e Freight actors and specially customised for transporting the e Freight Framework messages

5 (Figure 4). Moreover, addons for the EAPs will be developed to endow them with extra functionality to support tracking and tracing, the Single Transport Document solution, and other value-added services. DNS Existing system EAP Existing system EAP INTERNET EAP Existing system EAP Existing system Figure 4. The efreight EAP An EAP can be operated by any suitable organisation (subject to authorisation from the e Freight e- Delivery Infrastructure controlling body), for example a large transport logistics company may choose to operate their own EAP in the same way that they operate their own server. More commonly, especially for SMEs, a 3rd party can establish an EAP and provide services to users such as SMEs. This is an additional role to be considered in the overall approach, which could be identified as an IT services provider (Cane 2012, Hofman 2012). Each EAP provides a number of web services which can be invoked either by e Freight Applications or by existing systems which have been adapted to be interoperable with e Freight ( e Freight Enabled Applications ). Once the initial connection to the EAP is made, parties can then use these standardised services to interoperate with any other party which is connected to the e Freight community via an EAP, without the need for further investment (Cane 2012, Hofman 2012). When discussing electronic information exchange in the transport business, two issues are always at the forefront in the minds of stakeholders: Security and ownership of information. The e Freight e-delivery Infrastructure addresses both of these issues: Security is provided using certificates, adapted from a concept supporting security that satisfies e- Government. Security and integrity of the business transactions through the e-delivery Infrastructure relies on using a Public Key Infrastructure (PKI) to establish a trusted network. When Access Point providers sign the e-freight e-delivery Infrastructure Agreement they are issued with an e-freight Digital Certificate. This certificate contains the key information for validating all communications on the e-delivery network. This ensures only known and trusted providers provide services on the Transport Infrastructure. All information is owned by the organisation/system that produced it. Having no central platform, providing sufficient data security, and defining the community that is allowed to access (receive) information by using the address lists, the owner of information is in full control of it. As part of the set of additional e Freight specific services, the EAPs will implement the solution for the Multimodal e Waybill (Bento 2012). One of the critical problems to solve for the e Waybill is how to make the data globally available to those parties which need it. One solution is to have a single, central e Waybill system with a static address and means of access. However, this is not a feasible solution for reasons of confidentiality, security and reliability. In Modulushca the basic idea for addressing this problem is the introduction of a more structured model the Modulushca Common Data Model (Modulushca D4.4), which contains the data to be

6 considered in the interactions and, at same time, provide also the indication of availability of the data for the different contexts in the logistics processes. 3 Towards the modular logistics A message based solution, considering the e-freight approach, and the Modulushca Common data Model may be enabled using the EAP components. An EAP is exclusively available for a LSP or a LSC, but can also be provided by an IT based solution provider. The EAP handles only the standardized e-freight messages. The EAP is aimed at exchanging messages suited for logistics purpose and only with structured and predefined messages. The e-freight multimodal e-waybill (Bento 2012) is one such solution which will utilise the underlying communications infrastructure and services provided by the EAPs to meet the challenges above. The creator of the e-waybill uses standardized services provided by the EAP to create and manage the e-waybill. The waybill data is stored only on the EAP on which it was created. By using the network of EAPs, all other users can access the data they are authorized to, via their own EAP. This means that the owner of the e- Waybill has full control over his data, but other parties still have access to the parts they need. The protocols and services which are part of the Access Point design ensure the security of the data and enforce the access rights and authentication of users. In our activities analysis of existing systems has been performed, considering the PI vision to apply Internet transportation model into physical transport model where data (goods/postal letters) are consolidated into packets (modular logistic container) that move freely from source to destination. In our digital connectivity idea, derived from the PI metaphor, modular logistic containers represent the packets and goods represent the data. The data format described in this work are aimed at defining the architecture of the information, and, where needed, of the related protocols, standards, and interfaces needed for handling the modular boxes. Our analysis focused on FMCG industry as well as the postal industry. This has been done by means of interviewing users and experts from key players FMCG and postal industry as well as from the transport sector. A fundamental and unavoidable aspect, which represents the principal difference between Postal and FMCG fields, is related to objective of the logistic services. The Postal field is oriented at offering products and services to consumers, which personally require the functionality, favours the minimization of the latency of the single transportation and could be compared to a pull strategy, in which it is the user to start the processes of the logistics system. The FMCG field, instead, is oriented to the production and delivery of manufactured goods, favouring throughput volume of transportation and could be likened to a push approach, where the user is indirectly involved in the logistic processes, as final consumer. Summarizing, we have: Table 1: Comparison between Postal and FMCG scenarios Field Objective Efficiency criterion Customers Network type Main restrictions Postal Logistics Offering services to consumers Latency of each single service Private citizens or business companies Capillary network covering all the territory of a country Strict SLA for each single service (in terms of time allowed for the delivery) FMCG Logistics Providing goods to retailers Throughput of overall volume of goods transported Wholesalers, retailers, final consumers Dedicated network intended for covering specific routes and places Storage issues and related availability of goods where they are really needed

7 Postal services are oriented at providing services to customers or companies that are, generally, interested in delivering of letters or parcels to other people or companies, in the same country or abroad. Abroad delivery is realized through collaboration between the postal services of the involved countries. Moreover, the postal services may also receive letters or parcels from abroad to be delivered in the country. In the postal scenario single requests from customers or companies have to be satisfied according to the time of delivery constraints and with Tracking & Tracing systems supporting each single item delivery in the whole logistics chain. FMCG companies are oriented to production and delivery, to final retailers, of their goods. They use third party companies to take advantage of their transport services for the delivery of the goods to final destinations, the retailers. The manufacturer company is aimed at providing goods to other companies, which finally sell them to the final users. Requirements from both the fields have been considered in the definition of the Modulushca approach to data and processes, in order to define a solution viable for both scenarios. We now describe as the standards, already in use or proposed, as identified in the analysed sector of postal logistics and FMCG, may be used for supporting the data model. Standards are paramount for enabling interoperability between different systems and exchange of data. So they are an important component in the definition of the conceptual approach for modular logistics we are describing. In the following, then, we propose possible use for them. Each shipment, in Postal Services, complies with national legal obligations, and it is harmonized with UPU (Universal Postal Union) deliverables and standards for an international postal environment. So international postal interfaces organized through UPU standards for gateway hubs, in a national environment have, obviously, the related standards on a national scale. The postal logistic supporting information systems usually manage two types of data: data about entire processes monitoring (tracing, tracking, transport, ownership) and data about customers billing. However the basic idea is that each physical event (in the real world) corresponds to an informative event (in the IT systems), with all the information for supporting it. In the considered scenario, then, there is a correspondence among respective national informative events, in an international environment managed by UPU s activities and through the negotiation of a technological DIA (Data Interchange Agreement) (mostly used are EDIFACT-based (Electronic Data Interchange For Administration, Commerce and Transport) and XML-based messages). Standards are important prerequisites for effective postal operations and for interconnecting the global network. The UPU's Standards Board develops and maintains a growing number of standards to improve the exchange of postal-related information between postal operators and promotes the compatibility of UPU and international postal initiatives. It works closely with postal handling organizations, customers, suppliers and other partners, including various international organizations. The Standards Board ensures that coherent standards are developed in areas such as electronic data interchange (EDI), mail encoding, postal forms and meters. The UPU Standards may be used, in the modular logistics, for handling the border crossing between different country, enabling the provision of relevant data to the custom authorities In our idea for physical internet data handling, once the goods or the mails are sealed inside a modular box, which is labelled with the strictly necessary information, the delivery may be accomplished treating the modular container with a "black box" approach. Moreover this approach is already used in Poste Italiane, with the use the so called II level containers that, in our view, are the real world container nearest to the M-Box idea, in terms of handling by means of an IT system. Some point have to be highlighted:

8 Postal logistics have to deal with each single item (mail or pack) in order to deliver it fulfilling the related SLA (Service Level Agreement); In postal scenario the starting event of the logistic process is related to a single item, with a customer requiring a service; The postal logistics provides the dispatching, i.e. grouping items with common destinations, which are delivered maximizing the cross-docking and minimizing the storage. Now we can consider what could happen in a shared network where postal products and FMCG goods are shipped using modular containers. In such a view the modular containers may be considered as meta-items in the postal logistics view. Each M-Box, in fact, contains item that have to be delivered to a common destination. The M-Box may be filled in two major ways: Grouping together postal items, executing the dispaccio, i.e. the dispatching of mails and parcels, and inserting the items with a common destination in the same m-box; Taking all the items of an order (in a FMCG scenario) and splitting them up in several m-box, filling them. In both cases the result will be an M-Box with an unique ID (barcode, RFID, QR code, whatever ) that allows for associating to the M-Box a set of data inside the information system supporting the modular logistic. Those information are related to the following area: Data related to the box and present on the box itself, they may be referred as data model for the M-Boxes; Data present in the IT Systems that have to be exchanged with different partners during the interaction along the supply chain. At this point M-Boxes may be shipped in a shared logistics network, using the PI approach, and using operational processes similar to the postal one, i.e. maximizing the cross docking, minimizing the storage and monitoring an SLA for each single meta-item, i.e. each single modular box. We consider, now, the analysis and description of the AS-IS scenario in FMCG logistics processes and related information handling. From a Logistic service provider company, FMCG (Fast Moving Consumer Goods) is a logistic scenario in which there are three main actors involved: The Manufacturer or Shipper, which is the source where the goods are retrieved for the delivery; The Wholesale or Retailer, which is the requestor of the goods and is the destination for the delivery; Logistic Service Provider (LSP) is the actor who performs the delivery of the goods between the source and the destination. We consider a scenario where the Wholesale/Retailer wants to buy goods by a Manufacturer/Shipper. It is a business use case in which the request of buying a set of goods is sent to the Manufacturer/Shipper, then creating the motivation for having a logistic process: delivery. Delivery is the logistic process in which a Logistic Service Provider performs the activities of retrieving the goods from the Manufacturer/Shipper and transporting them to the Wholesale/Retailer. GS1 (Global System One) organization previously EAN/UCC is world leader in the delivering standards solutions regarding automated data acquisition, data carriers and electronic messages in global trade specially FMCG sector. GS1 is dedicated to the design and implementation of global standards and solutions to improve the efficiency and visibility of supply and demand chains

9 globally and across sectors. The GS1 system of standards is the most widely used supply chain standards system in the world. Global identifiers are the foundations of automatic data processing in nowadays electronic data interchange in trade and transport and logistics sector. GS1 identifiers are identifying goods, transport and logistics units, locations, transaction parties, shipments and consignments, means of transport and transport equipments but also documents and services. The most common known identifiers which covers almost whole world are global trade item number GTIN which identifiers every single product in retail sales. Other very important and widely used identifier is the single shipment container code SSCC which is used for marking the single logistics units like pallets, packages, bulks: it is very often connected with SSCC logistics label and electronic messages like dispatch advice for example. This one should be first option for modules marking. Other very important from transportation point of view are identifiers of shipment GSIN and consignments GINC. GSIN number is a proposal of World Customs Offices (WCO) as a correct identifier Unique Consignment Reference (UCR). 4 Data management approach We consider the logistic network is represented as a structured network composed of logistics nodes, hierarchically interconnected by backbone connection or inter-regional (the coach layer), regional (the bus layer) and last mile (the taxi layer). A common carrier approach is desirable, though the management of this common effort is still a big issue, in order to avoid side effects and other unwanted behaviour; the shipment is performed with a common effort of all actors collaborating in delivering the boxes, so as transfers, optimizing the flow-time and at minimal cost. The type of transport is oriented preferably for multimodal or intermodal logistics: the boxes are able to be carried by different means of transportation (multi-modal) without being unpacked. 4.1 The Modulushca Common Data Model In order to enable the modular logistics and for enabling encapsulation of the goods a data model has been defined, in the frame of the Modulushca project (Modulushca D4.4). The following sections describes the model, the related information and interactions. We refer to the data model as the Modulushca Common Data Model or Coloured Data Model. The access to the information handled by the Modulushca Common Data Model is connected to the context. In our approach the context, may be considered as a window allowing to see only part of the information, depending on the role of the actor who is accessing to the information and the situation in which this access is performed. This contexts have been modelled in the common data model, considering the data differently tagged by a colour. Diverse colours, means different level of accessibility for the data. The red tagged data are the most reserved, while the green tagged data are the totally public, accessible by anyone. The model is schematized in the following image Figure 5. The model represented has been formalized using the XML for defining a document able to contain the information. It is important to clear that the represented model, seldom schematized using XML, is a conceptual model, so it may be further detailed and extended. For achieve the needed flexibility, the model is realized with XML Schema Definition Language and the defined XSD types are extensible and may be updated.

10 RFID or other Active TAG QR Code or Bar Code GPS Positioning: Track the Truck (Russian Dolls approach) MBox UUID Cloud Services Distributed DB MBox Data Network flow Shipment flow Business flow UUID Size Weight Fragility Perishibility Special environment(s) Public routing info: - GINC - destination address Protected business related info: - GSIN - sender identity - receiver identity - source address - description of goods - value - time-window Reserved information to be exchanged only between sender and receiver: ID_order - invoice - acknowledge - missing items - ETA Figure 5. The Modulushca Common Data Model or "Coloured" Data Model The modular unit is tagged with devices (i.e. RFID, or other active Tag from the IoT technologies) or description (i.e. QR Code or Bar Code), or both of them, which enables to read the "green data" directly from the M-Box, itself, or by accessing to IT Systems (by means of the UUID) and retrieving them. The green data, defined M-Box data, are needed for correct and safe handling of the modular unit and of its content. They may be read by humans operators directly with portable device or by automated systems. They enable and ease, the loading, unloading, stacking, cold storage and so on. Moreover, the RFID are used for enabling the EPCIS, for the handling of track and trace, and for the generation of events to be processed in the IT systems. On the M-Box there is, also, an UUID (Universal Unique IDentifier) that allows for accessing to the IT Systems, in order to retrieve more information about the box. Regarding the tracking and trace we consider a Russian Dolls approach, exploiting encapsulation of goods, inside Modular Boxes, inside pallets (or inside modular boxes of greater dimension), and inside carriers (trucks, trains, etc.). The tracking of each single box is obtained tracking dynamic aggregation of boxes, that travels by one node to another. IT Systems, in our vision, are realized using the Cloud Computing approach and are based on Cloud Services, which together establish a distributed system, interconnected through the internet, enabling the several actors involved in modular logistic to exchange information and data, perform collaborative planning, exchanging track and trace information, and so on. Next layer in the model are the yellow data, which we identify as the network or routing data, related to the transport layer of the network. They are slightly more reserved than the green ones and are accessed and processed in order to provide the correct handling of the boxes, through the network, in order to satisfy the transport needs and guarantee the satisfaction of the consignment. This data (together with the previously described green data) are involved with the how of the consignment, i.e. the use of physical resources and means in order to complete the delivery. Following, in order of increased secrecy, there are the orange data, which are related to the shipment of the boxes, and involved with the logistics value of the consignment. They deal with who, where, what and why of the delivery process. Last there are the red data that are the most reserved, being aimed at the business and financial aspects of the delivery. They have to be exchanged only between the original sender and the original receiver, in order to fulfil the business needs.

11 In the following we describe the data, how they have been modelled using the XSD formalism, which allow the definition of specific type, simple and composed, aggregating the information. Figure 6. Common Data Model: M-Box Data The green data or M-Box data are encapsulated in a single XSD, which is a XS Complex Type, composed by atomic information, defined as XS Simple Type in the model (Figure 6). As defined the M-Box provides: the UUID of the box, its size, its weight (as loaded by the goods), the fragility of the contents (useful for handling it correctly), the possible perishability of the content (and consequent need for cold storage, for example) or the need for use of special environment (for chemicals, flammable or other kind of dangerous contents). This set of data allows for the blackbox handling of the modular units: without the need to open the box, the operators or the automated systems may know all the basic and fundamental information for the handling of the box at the best. Figure 7. Common Data Model: Routing Data The Routing Data (or Network data), tagged in yellow, is used for the routing of the boxes in the network (Figure 7). IT systems at this level may operate using a planning-checking approach. Using the routing data the box consignment is planned (in advance or dynamically just in time) and the box loaded on a carrier. Routing data are also used for detecting and correcting routing errors. The XS Complex Type is composed by: GINC, Global Identification Number for Consignment, providing the information needed for the consignment handling, and the Destination Address used for the routing and planning. Figure 8. Common Data Model: Shipment Data

12 The Shipment Data, or orange data, is a XS Complex Type, which is involved with the logistic value moved by the consignment (Figure 8). The information available, at this level, are related to what, where, and when of the delivery. The XS Complex Type composed by: the GSIN, Global Shipment Identification Number, information about the sender and the receiver identity, the source address where goods have been picked up, a description of goods, their value and the time window for the delivery. These information may be used in the IT systems for providing planning constraints, defining SLA (Service Level Agreement) and other restrictions to be considered while performing the consignment. Figure 9. Common Data Model: Business Data Finally the Business data, or red data, is a XS Complex Type, allowing the exchange of reserved information between the business partners of the delivery (Figure 9). Involved data are related to the purchasing order, the invoicing, the acknowledgment of the delivery, the missing items and ETA (Estimated Time of Arrival). This XSD elements, are the elements of the Modulushca Common Data Model, which may be used for enabling interoperability. In fact they may be used as standard arguments (i.e. variables to be provided) for the operations of the standard interfaces between the interconnected systems. 4.2 Security Additional stakeholders have to be considered, which are not part of the reference logistics value chain but play an important role in logistics chains: The Authority/Customs (A/C) for governing the goods flow based on (inter)national laws and regulations. There is a variety of authorities, each with their own specific requirements on information exchange, e.g. customs, inspections, and river police involved in handling vessels in ports and on sea. Customs broking or Customs brokerage is a profession that involves the "clearing" of goods through customs barriers for importers and exporters (usually businesses). This involves the preparation of documents and/or electronic submissions, the calculation and payment of taxes, duties and excises, and facilitating communication between government authorities and importers and exporters. Custom brokers may be employed by or affiliated with freight forwarders, independent businesses, or shipping lines, importers, exporters, trade authorities, and customs brokerage firms. Customs brokers must pass an examination and background check to become licensed by the U.S. Customs and Border Protection. They are not government employees and should not be confused with "customs officers" (in other countries, however, the two terms may be interchangeable). Customs brokers need to be familiar with the tariff schedule, a listing of duty rates for imported items, and the regulations governing is an importations found in 19 CFR, the Code of Federal Regulations Title 19. To illustrate, a customs broker may need to advise an importer on the marking requirements of the country of origin, or complete paperwork for a clothing shipment subject to

13 quotas and visa requirements. Knowing the requirements of each type of import can avoid costly delays or merchandise seizures. The customs authorities structure includes: the Federal Customs Authority; regional customs departments; customs offices; customs checkpoints. Data privacy and security is very important in logistics. Logistics data contains commercial relations between organization including agreements and costs and should therefore only be disclosed to authorized organizations and persons. As Logistic Service Providers (LSPs) and carriers are responsible for handling (high value) products of others, they are also liable up to a certain amount. What data is required by an LSP or carrier for actual value exchange? In case a service provider does not have and does not require data, i.e. the actual content of a container, but only a broad description (STC: Said To Contain), that provider can only be held liable for loss or damage for a particular amount, e.g. cargo weight. Who has access to particular (real-time) data, i.e. for collaboration or inspection (to govern security and food safety)? Data visibility is not only required for collaboration amongst organization operating in logistic and in the entire supply chains, but also from an authority perspective. Different mechanisms can be implemented, i.e. Role Based Access Control is probably the most well-known and applied in practice. However, in a dynamic environment roles of an organization differ per supply chain configuration. Access control thus needs to be related to the participant role in a particular supply chain. Organizations like shippers/consignees, LSPs and carriers basically can have access to data of others if they have agreed for such collaboration. However, they should only have access to data of business transactions in which they are service provider and customer, unless granted otherwise (e.g. full supply chain visibility). Authorities should only have access to data of incoming and outgoing cargo flows types of goods (e.g. agricultural goods) in the territory they govern. Liability and data visibility require identification and possibly other IT security mechanisms like electronic signatures giving proof of data stemming from a particular source. Logistics is faced with safety and security measurements dealing with terrorism, smuggling, and related security accidents with a high societal impact. It arises the necessity of the realization of a flexible platform for sustainable and secure data exchange between collaborating global supply chain actors. Such a platform allows shippers, authorities, logistic service providers, and carriers to be fully interoperable across closed communities, to perform paperless logistics, and to adhere to societal demands of security, safety, and sustainability. For the realization of the platform, a hybrid solution consisting of central and decentralized systems is possible with a combination of several IT components implemented by one organization or operating on behalf of more than one organization, either owned by these organizations or offered by a commercial service provider such as a cloud services provider. A hybrid solution requires interoperability amongst all IT systems supporting the functions. This aspect also relates to governance and standardization issues relevant to communities: is there one common semantic model or do we need to have multiple (bilateral) transformations based on standards and models agreed in different communities? Having an hybrid solution implies that also more than one identification mechanism with different types of certificates needs to be supported. Authorities operating in the government layer within a country will for instance define their identity mechanism that can be used in collaboration with them. Traders can also make particular agreements on the identification mechanisms used. Protocols need to be established for collaboration and business transactions amongst organizations utilizing different identification mechanisms. Having these protocols makes it possible for an organization to use its certificate

14 globally, it will for instance offer a customs authority access to a foreign database to retrieve all required data of incoming and outgoing goods flows in the territory of that authority. The biggest challenge here is to build up an international chains of trust. In transport law, carrier liability determines how much the carrier must pay if the cargo is lost, damaged or delayed during transport. The level of carrier liability (i.e. how much must be paid) is determined by the liability rules which are applied to the contract of carriage for the transport booking. A transport document or waybill is not a contract of carriage. That is, the document itself is not the contract on which the rights and obligations of the parties are based. Rather, it is the evidence that a contract and related contractual regime exists. The terms of the contract and applicable liability regime influence the choice of document used for a given transport and so transport documents are inextricably linked with the issue of liability. The coloured model addresses this needs, providing already public data, directly accessible on the modular unit. More restricted data may be required and accessed, basing on the roles of the requestor. All the actors involved in the logistic processes may be tagged with a role, which allows for accessing to the data, which may be colour tagged. In our conception the role may be the follows: green role: access granted only to the green data (i.e. systems and operators not involved in the logistic process but only in the handling, storing, stocking); yellow role: access granted only to green and yellow data (i.e. logistic service provider involved in the transport); orange role: access granted to all but red data (i.e. the shipper managing the shipment, the authorities); red role: access granted to all data (i.e. original sender and original receiver, involved in the business processes). Public Data Manufacturer, Retailer Network Data Shipment Data Shipper (4PL), Custom authorities Business Data MBox handlers, Warehouse Figure 10. Roles and access to data LSPs, Carriers (3PL) The above image (Figure 10) summarizes the roles involved in the collaborative logistics scenario and the access granted to the different shells of the Modulushca Common Data Model. 4.3 Model evaluation The presented model is generic and may address the needs information sharing in interconnected modular networks. Furthermore, roles and security issues are considered, in order to consider the feasibility of the proposal. Anyway some issues emerges when evaluating the model.

15 One interesting consideration, in M-Boxes approach, is to realize them assembling standards panels as needed for encapsulating the goods. In such case there is an issue to solve, regarding how to generate the UUID for the assembled M-Box. Authors proposals are: to have "lead panel", i.e. one particular type of panel, with all the needed devices for the storing of information, or the existence of separate "tracking boxes", hosting all the needed devices, to be added, one for each assembled M-Box. Another interesting idea to consider is related to M-Box grouping, i.e. the modular container should present the ability of being assembled together in order to be handled as a unique container. In order to accomplish this, modular container should be assembled on three levels: physical level, electronic level and computing information level. The data model, then, should be able to handle temporary logical aggregation of information object, enabling the handling of them as a whole. This functionality is already available in postal logistics, where the postal items to be delivered are grouped, using two level of modular containers, considering their destination, and then are tracked and handled as an aggregation. Finally the need for geolocalization of M-Boxes have to be considered. During activities in Modulushca project, future evolution of the tracking devices has been considered. In future, with increased capability of the electronic device at reduced cost, GPS enabled devices, with sensor for measuring physical parameters inside the boxes, may be used to track each single M-Box. Nowadays a similar approach is already used for tracking containers. 5 Conclusion The present work describes an approach for handling the information about modular boxes, in an interconnected logistics scenario using the Canonical Data Model (CDM), enterprise application integration pattern, which is based on the definition of a common data model. The proposed Modulushca Common Data Model, identified also as the Coloured Model, has been obtained considering the encapsulation approach, proposed by the Physical Internet and is the base for the definition of interfaces and protocols. The former, in fact, may be defined through a set of operations, usable by the IT systems in order to interoperate one with the other for exchange data as defined in the proposed Modulushca Common Data Model. The latter, is the description of interaction between actors using the defined interfaces and the types proposed in the Modulushca Common Data Model. In the Modulushca project the proposed CDM provides an efficient way of enabling meaningful comparisons across disparate data sources, highlighting the differences in data capture processes and/or underlying supply chain characteristics that are important for interpreting results produced from each database. The proposed mode, then, is an important contribution in the direction of defining a model for interoperability of IT Systems. The model has been defined using XML and XSD, in order to be platform independent, extensible, machine processable and human readable. It is based on supporting standards and proposals: the GS1 and EPCIS. Moreover, it is inspired on the results of the efreight project, for defining and using XML based documents, EAP and inter-operable systems. Further evolution of the model will be needed in order to address completely the needs of the modular logistics. Integration and extension of the Modulushca Common Data Model, however, are already considered as normal operation, using it. In fact, the model has been defined using XML and XSD language, that allows for extending and integrating the data structures, to be used for handling the interoperability between participants. The successful use of the proposed Common Data Model, as well as the execution of the ICT operational environment rely on the capability of the implementation of the correct business model towards the Physical Internet to interoperate between different players in the entire supply chain.

16 Another point of interest, in the refinement of the model, could be the introduction of semantic description of the data and operations. An ontology may be developed for the introduction of metadata and for the semantic annotation of the services. Such approach may allow a high level of interoperability and integration between the systems, because introduce and enable the machine understandable description of services, and the automatic service composition. The proposed model, then may be further extended and improved but is a valuable result. In fact it has been used for defining an High Level IT architecture, in the Modulushca project, for realizing the modular logistics. Acknowledgments The research activities, leading to the results presented in this paper, has been executed in the frame of the Modulushca projects, which has received funding from the European Union Seventh Framework Programme. References Bento N., Cane T., Kjellberg C., Pedersen J.T., Rosen M., (2012): e Freight the edelivery Infrastructure, Proceedings of the e-freight 2012 Conference, Delft, The Netherlands, 9-10 May Cane T., Mattheis S., Tsoukos G., Focas C., Koliousis I. (2012): The e-freight Multimodal e -Waybill. Proceedings of the e-freight 2012 Conference, Delft, The Netherlands, 9-10 May Hofman, W., Bastiaansen, H., Van den Berg, J., Pruksasri, P. (2012): A platform for secure, safe, and sustainable logistics. Proceedings of the e-freight 2012 Conference, Delft, The Netherlands, 9-10 May Hohpe G. and Woolf B (2003): Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, Addison-Wesley. Modulushca D4.4 (2014): Common coding and information format for digital interconnectivity, Modulushca deliverable. Montreuil B. (2011) Towards a Physical Internet: Meeting the Global Logistics Sustainability Grand Challenge, Logistics Research, Vol. 3, No. 2-3, p Montreuil B., E. Ballot & F. Fontane (2012): An Open Logistics Interconnection Model for the Physical Internet, Proceedings of INCOM 2012 Symposium, Bucharest, Romania, 2012/05/ Montreuil B. (2013): Physical Internet Manifesto, v1.10, (Original v1.0, 2009), Montreuil B., E. Ballot & R. D. Meller (2014): Physical Internet, Documentation Française (La) (September 5, 2014) ARKTRANS: EDI: efreight: EPCIS: FreightWise: icargo: KonSULT: Modulushca project official page: SmartFreight: UBL: XML: