D5.1 Port Systems: feasibility and business behind port community integration

Transcription

1 Grant D5.1 Port Systems: feasibility and business behind port community integration Agreement nr: XXXXX Project acronym: e-compliance Project title: e- Compliance

2 Funding Scheme: FP7 Deliverable No and Name: D5.1 Port Systems: feasibility and business behind port community integration Due date of deliverable: 29 February 2016 Actual submission date: 26 February 2016 Start date of project: 1 June 2013 Duration time: 36 months Organization name of lead contractor for this deliverable: TNO Revision (v3) Project co-funded by the European commission within the Seventh Framework Programme ( ) Dissemination Level PU Public 1

3 Version History Version Date Author Organisation Description 1 19/02/ /02/2016 J.G. de Putter, I.Y. Davydenko, Bert Cappuyns, Albert Ruiz J.G. de Putter, I.Y. Davydenko, Bert Cappuyns, Albert Ruiz TNO, PT Draft 1 TNO, PT 3 22/07/2016 Ditto TNO, PT Reviewed version Updated version addressing comments made by the reviewers 2

4 Contents Version History 2 Executive Summary 5 DoW compliance check 7 1 Introduction Research scope and understanding of the problem Background on PCSs and NSWs Approach towards business cases with respect to Virtual Port Systems Reading guide 13 2 Methodology Approach Arguments for Scoping Interview Stakeholders Interview Protocol Conclusions regarding methodology 21 3 The role of PCSs Functions of PCS Why PCSs 27 4 Forms of PCS integration 29 5 Feasibility study on PCS integration SWOT analysis on forms of PCS integration Interviewees on the current situation Concluding remarks 37 6 Business cases of PCS integration 38 7 Technical analysis of integration of MGI (port of Marseille) and Portic (port of Barcelona) General information Technical aspects Business case of information Data storage 55 3

5 7.5 Conclusion on Portic & MGI case 61 8 PCS integration in the European context European potential for PCS integration Implications for European policy 63 9 Conclusions and outlook References Appendices Appendix 1. Example of an xsd message Appendix 2. XML message linked to the xsd message of Appendix

6 Executive Summary Most ports have information exchange systems that allow parties working with and around the port to exchange information between each other and with the governments. These port information exchange systems are also known as Port Community Systems (PCS) and provide the communication means and certain port-specific intelligence functionality. Guided by the EC Directive 2010/65/EU, the government provided information exchange systems are intended for communication between the users of ports and port services with the government. These IT systems are taking the form of a National Single Window (NSW), where all communication with various government agencies and departments is realised through a single interface. The main goal of this deliverable is to provide an analysis on the feasibility and potential business case(s) of PCS integration, as well as the position of the NSW systems in the PCS integration environment. Information once entered into a Virtual Port System (VPS) covering a number of ports should not be entered anew at each port covered by the VPS. This would reduce the administrative burden, reduce the chance of mistakes and allow for various intelligent services and functionalities, such as logistics visibility and rerouting. The VPS system of this deliverable is based on the idea of integrated PCSs systems, where a number of original PCS work together on information exchange in various organisational forms and degrees of integration. The analysis is first approached by the scoping of the problem, definitions of the PCS, NSW and PCS integration. The main differences between PCSs and NSWs are that NSWs are country specific, provide no way to reuse the data and realised by the governments; in contrast, PCSs are local and port specific, allow for reuse of data and can be established by the governments/public entities or private parties. Another important aspect is that NSWs are compliance-driven, while PCSs can be considered as the basic infrastructure of the ports to the extent that some ports can even realise a competitive advantage through a well-functioning PCS. The integration of PCSs, therefore, should be of interest to the regulators, declaring parties, enforcement agencies and interest groups. The analysis of this deliverable is based on desk research and empirical information, gathered through interviews with important stakeholders and industry experts. Methodologically, the desk research contributed to the scoping and framing of the problem, also identifying main questions that the industry experts should be able to answer. These questions resulted in an interview protocol, which also contains a definition of PCS integration. In total, around 40 interviews of approximately one hour have been conducted; some interviewees have been spoken to a number of times, as they were the sources of relevant information. The analysis combines in a structured way the information from the desk research and interviews. The role and functions of PCSs have been considered in detail. Based on desk research, seven dimensions and corresponding user groups have been found. Within each dimension, 5-18 dimensionspecific functionality elements are presented. Previous research is also analysed the degree to which major world port PCSs realised each of the functionalities per functionality dimension. Although this information has independent intrinsic value, it also shows that PCSs are very different in their nature, emphasis, sophistication, complexity, etc. In other words, PCS is a very loose definition of a port IT system. This conclusion is very important for understanding possibilities of PCS integration, as it 5

7 underlies the fact that there cannot be a unified PCS integration protocol, but it will always be a specific effort of specific parties. Four main system integration designs (forms) are considered in the context of feasibility and business case of PCS integration. Integration can be easy, at the level of (1) bilateral message exchange, which can also be considered as an arm s length integration. Bilateral integration can also take a form of a merge, where instead of two PCS in the end there will be one system used by both ports. This design (2) full bilateral system integration is very suitable for the (small) ports that currently do not have any PCS. If more than a few systems need to be integrated, bilateral links become impractical. A (3) multilateral message exchange design involving a neutral message exchange platform would be the choice if integration is at the level of message exchange. If multilateral integration takes a deeper form with a single common interface, then the (4) central PCS or multilateral system integration design is the most suitable. Feasibility of PCS integration is considered through SWOT analyses of information sharing in general and SWOTs of the four integration designs. As the PCS systems of European ports are hardly integrated currently, except only a few pilot projects, starting up integration efforts presents a challenge. Hence, in this environment the first design with bilateral message exchange realising the needs of stakeholders at the two ports may be a viable starting point. Full integration (design 4) at this point in time is not considered to be a viable option. Based on the opinion of the interviewees, there are eight distinct integration cases present. This deliverable does not develop these cases into fully-fledged business cases with investment and cash flow analysis, as there is no financial information available on the one hand, and due to the fact that diversity of the PCS realm would result in completely different cost and benefit estimations. In other words, quantitative estimations are very specific to the integrating parties. Nonetheless, the idea of single user log in credentials and unified user interfaces is considered to be viable. Also cases that improve business processes, such as sharing of track-and-trace information, prefill of compliance forms, reuse of documents have been considered by the interviewees as interesting. During the course of the e-compliance project, the ports of Barcelona and Marseille have implemented their own pilot integration case. They have designed an API for exchanging information between the PCSs. The ports currently exchange information related to the ship arrival procedures, mainly on behalf of the ship agents. The data shared are related to the vessel (BERMAN message), outgoing dangerous goods (similar to the HAZMAT message). The technical details of this integration project are further specified in this deliverable. Based on the interviews, there is currently a very limited practical potential for a single European level VPS/PCS. The pilots being developed now do not go further than an arm s length bilateral message exchange. The main reason for this is that such integration is relatively easy to realise technically and organisationally as the parties know exactly what data is exchanged, with whom and for what purposes. Nonetheless, despite a lukewarm attitude of the interviewees, the authors consider EUlevel functionalities that facilitate work and reduce the costs (such as form prefill) to be potentially viable. In addition, global data pipeline linking foreign PCSs for the purpose of document preparation and risk profiling are viable. The policy makers should not be involved directly in the integration process, as the businesses around the ports are well capable of making their own decisions on integration. However, the policy makers should look for the cases where market failures 6

8 or exorbitant market power of certain stakeholders and/or transport chain partners stand in the way of efficiency gains through integration. DoW compliance check The following table links the content of this report to the task description in the e-compliance Description of Work (DoW). The italic text highlights the main emphasis of the work. For each subtask listed in the DoW, in the column Covered in section we provide where in this deliverable the work results can be found and, generally, in what form. Table 0.1: Task 5.1 DoW compliance DoW text for D5.1 (Port Systems) Covered in section 1 A feasibility study and Chapter 5 presents feasibility study in the form of SWOT analyses of different integration designs 2 business case analysis of integrating Port Community Systems and National Single Windows will be carried out. 3 This activity will take input from T1.1 on the different stakeholder requirements, identify barriers and benefits from sharing compliance data via PCSs, 4 and develop possible business models for a network of PCSs exchanging logistics information. 5 A key focus will be the position and future of PCSs and National Single Windows in modern supply chains. 6 The analysis results will also discuss the role of smaller ports that do not have a PCS at the moment and advise on how these smaller ports can be integrated in a European VPS. 7 The problem analysis will identify the challenges, e.g. political, businesswise, legal etc., and potential benefits of a virtual port based on desk study and interviews. 8 The technical analysis will investigate the interoperability challenges that exist between the various systems and how these can be solved. Consultation with the EPCSA should be Chapter 6 outlines integration business cases Chapter 1 defines functions of PCS and NSW, considers differences; Chapter 3 recaps on ecompalince WP1 work, including requirements Chapter 4 provides integration designs and Chapter 6 provides integration (business) cases, including logistics visibility and trackand-trace functionalities Chapter 1 specifies the roles and functions of PCS and NSW, Chapter 3 further specifies functions of PCS per user category and considers major international PCS with respect to fulfilling these functions The SWOT analyses of Chapter 5 address the issues of smaller PCS-less ports directly. This is done per integration design. Chapter 5 addresses these challenges and benefits directly and explicitly for a general PCS integration concept, as well as for four integration designs. Chapter 7 provides a detailed description of integration efforts between the ports of Barcelona and Marseille. EPSCA (currently IPSCA) has been consulted with 7

9 sought to support this activity. 9 Based on the above analysis, rules and requirements for information exchange between PCSs will be specified. Chapter 8 draws conclusions for the potential of PCS integration at the EU level, as well as provides a concise advice for the policy makers. Chapter 9 draws conclusions. 8

10 1 Introduction This deliverable reports on research conducted in the framework of e-compliance s project task 5.1. It concerns the question of usefulness, feasibility and practicality of information exchange between different Port Community Systems (PCS), which are IT solutions around the ports facilitating information exchange between the parties working at, around and with the port, as well as with government bodies. In this chapter we introduce PCS, provide our vision on the understanding of the problem and facilitate the reader with a concise user guide. 1.1 Research scope and understanding of the problem Data sharing in international transport setting is assumed to provide substantial benefits and potentially can lead to an improvement of the whole industry through faster, more reliable, safe and environmentally responsible services. Data sharing can also result in operational efficiencies of individual companies through less administrative and control labour inputs, as the data once entered into an electronic system may be directly reused for other purposes, or transformed and formatted and matched with other data elements to create inputs for other domains. In the context of this research, many ports have port community systems, which facilitate data exchange between the parties, who work at, with and around the ports, as well as government bodies. Essentially, PCS are Information Technology (IT) providers of the ports, helping organizations related to the port to exchange data and communicate with each other. As opposed to the government-run National Single Windows (NSW), PCSs can be private, as well as public. Also, there is no rule that a port has to have a PCS, while NSWs are required by the European legislation. The fact that many ports have a PCS and the established practice of information exchange via PCS create evidence that PCSs provide value for its users. A PCS can be even considered as a part of infrastructure provided by the port; quality of these IT solutions is a factor in competitive attractiveness of a port. Therefore, it is a logical idea that information exchange between PCSs can present a value for the users, thus broadening the coverage of IT solutions. Moreover, PCSs can take over some functionality of NSWs, or provide a better interface to the government agencies. Therefore, this research tests the idea of PCS integration. First, a feasibility of PCS integration is considered. What are the tangible benefits of PCS integration? What are the barriers in the way? These questions are intended to gain understanding on how realistic data exchange between PCSs is. Subsequently, this research identifies potential niches, where integration can be self-sustaining, driving by a positive business case around such an integration. There are many parties who work directly or indirectly with the ports. These parties can be considered as stakeholders for the case of PCS integration. Some of the stakeholders might benefit from it; others might not or even lose their competitive advantages. Therefore, the scope of this research includes identification of the relevant stakeholders for the case of PCS integration, and consideration of their primary needs with respect to PCS integration. In other words, a possible integration case is within the realm of parties who use PCS directly or indirectly and who may benefit from information sharing /or other forms of integration between the PCS. 9

11 1.2 Background on PCSs and NSWs PCS Definition: A Port Community System (PCS) is an electronic platform that connects multiple systems operated by a variety of organizations that make up a seaport or airport community. It is set up, organized and used by organizations and stakeholders with interests in maritime, logistics and trade in this case the port community. Key drivers for the establishment of Port Community Systems are the need for a standardized communication platform to improve the logistics supply chain systems in terms of punctuality, reliability or costs, and the need to increase the competitive position among ports. Distinctive for all PCS is the link to Customs and Port Authorities and other institutions such veterinary offices or coastguard. Each PCS has the ability to link electronically into many other systems as the local, national or international regulations require. As such, the PCS brings the business-to-business information exchange into the equation, as well as providing the gateway for business-to-government processes, and is therefore complementary as well as supplementary to the Single Window at both national and international level. Notion of a NSW The World Customs Organization defines a single window as follows (EC 2006): A facility that allows parties involved in trade and transport to lodge standardized information and documents with a single entry point to fulfil all import, export, and transit related ( ) regulatory requirements, explaining that the single window is clearly a trade facilitative measure. It permits the trader or transporter to submit all the data needed for determining admissibility of the goods in a standardized format only once to the authorities involved in border controls and at a single portal. The Single Window concept places the onus on the authorities to manage the Single Window and to ensure that the participating authorities or agencies are either given access to the information or are actually given the information by the managing authority. It eliminates the need for the trader or transporter to submit the same data to several different border authorities or agencies (EC 2006). The directive 2010/65/EU defines Single Window as an entity linking SafeSeaNet, e-customs and other electronic systems that shall be the place where, in accordance with this Directive, all information is reported once and made available to various competent authorities and the Member States. Parties involved in trade and transport should be able to lodge standardised information and documents via an electronic single window to fulfil reporting formalities. Individual data elements should only be submitted once. The National Single Window (NSW) aims to simplify this administrative burden by providing a place where all maritime information is reported once by ship data providers, at either national or port level, and made available to all relevant authorities. Certain parts will also be made available to other Member States via SafeSeaNet (EMSA 2014). Single window system is a trade facilitation idea. As such, the implementation of a single window system enables international (cross-border) traders to submit regulatory documents at a single location and/or single entity. Such documents are typically customs declarations, applications for import/export permits, and other supporting documents such as certificates of origin and trading invoices. Definition of PCS Integration: Integration between PCS s enables the exchange of data and documents regarding specific vessel voyages and cargo data including information concerning 10

12 routing and goods and people on board, in order to allow the transmission of data between subsequent ports without the need to report the same information multiple times to different PCSs. Differences between PCS and NSW: PCS is usually a local initiative realized in an IT system, which is specific to a port. The NSW is, by definition, a country-level national system. The NSWs are driven by the governments and in response to the Directive 2010/65/EU, which ensures that the EU Member States accept reporting formalities in an electronic form. The directive does not guide the PCSs, thus they are developed independently as initiatives around the ports. The PCSs can be privately as well as publicly held and developed. Once information is submitted to the NSWs, it cannot be re-used for other purposes, as this is not intended by the NSWs. The opposite is true for the PCS, as port community systems can develop any functionality that is requested or may be useful for the parties around the PCS. PCS can function as the electronic gateways for the NSW, submitting compliance data there on behalf of the PCS users. The following list summarizes main differences: 1. NSWs are country-specific, while PCSs are port-specific 2. NSW submitted data cannot be reused, while PCS data can be used later or for other puposes 3. NSWs are government-driven, while PCS can be either or both government or public driven It should be noted that currently NSWs serve primarily for SafeSeaNet purposes. SafeSeaNet should combine data such that info from different NSWs and PCSs can be checked. There is no use for PCS integration, as it is the task of SafeSeaNet. There is a practical issue now, as the feeds to the SafeSeaNet are a one way communication. It is about to change in the future. The NSW implementation is compliance driven, their implementation seems to be behind the schedule. As NSWs are only for the compliance purposes, they do not require other information. Moreover, any other information would cause info-liability; hence all information shared to the NSWs is limited to the EU directives and in some cases national legislation. Examples of regional organisation of PCSs Portugal has one PCS for all ports; France has 12 PCSs (including one provided by the French administration, several that serve several ports and several that are dedicated for one port); In the UK nothing is provided by government 1.3 Approach towards business cases with respect to Virtual Port Systems This deliverable approaches the issue of feasibility and business case through a desk research; expert opinions gathered through face-to-face meetings and telephone interviews, which are both based on an interview protocol developed for this deliverable; and analysis of the results. A PCS integration case of the Barcelona and Marseille ports is also presented in this deliverable as a complete standalone case. The interviews with some 40 industry experts have been used for a feasibility analysis, applied at the level of four technical designs of integration (see chapters 4 and 5 for more details) and for the analysis of cases for integration, presented in chapter 6, where e-compliance has 11

13 distilled useful integration cases from the interviews. The cases are centred on the needs of a broad set of stakeholders, as they have been specified in e-compliance WP1. e-compliance Work Package 1 has aggregated port stakeholders into four distinct groups: (1) Regulators, (2) Declaring Parties, (3) Enforcers, (4) Interest groups. Here we present aggregated requirements from these stakeholder groups with respect to PCS integration (Virtual Port Systems). I. Regulators 1. Harmonize European port process formalities 2. Simplify port processes 3. Speed up implementation of regulatory changes 4. Control / address mis-non- declarations to EMSA 5. Eliminate local disadvantages 6. Data harmonization and electronic exchange II. Declaring Parties 1. Communication with the Captain 2. Port process harmonization and simplification, cost reduction through administrative burden allevation and error elimination 3. Elimination of annecessary data / document submission 4. Less manual working procedures 5. Better coordination and sharing of data, one-stop-shop 6. Real time visibility III. Enforcers 1. Access to vessel information from other stakeholders 2. Early access to vessel schedules 3. Vessel requirements from port operations 4. Timely and error free information to harbor master 5. Document harmonisation and agile communication with stakeholders IV. Interest Groups 1. Reuse messages and eliminate business process duplication The representatives of all four stakeholder groups have been approached and spoken to in the interviews. The e-compliance team has aimed to have enough representatives in each of the stakeholder groups in order to draw qualitative conclusions with respect to their opinion on PCS integration feasibility and cases. 12

14 1.4 Reading guide This report is structured as follows. After a concise introduction of this chapter, the methodological approach to a study on feasibility and case for PCS integration is explained: desk research and interviews with the stakeholders have been used to determine usefulness and conditions of PCS integration. Chapter 3 looks into the role of PCS at the ports and in transportation chain, paying attention to the different types of port community systems and stakeholders involved. The concept of PCS integration is dealt with in Chapter 4, where the main designs of PCS integration are considered. Chapter 5 considers the feasibility of PCS integration, also presenting a SWOT approach to the issue. Based on the desk research and interview results, Chapter 6 presents an approach to a business case for PCS integration. A realised PCS integration pilot case for the systems of Barcelona and Marseille is presented in Chapter 7. The deliverable is finalized with the policy implications in Chapter 8 and Conclusions of Chapter 9. 13

15 2 Methodology 2.1 Approach The problem of PCS integration has not been studied before. The e-compliance project provides a first attempt at understanding on the whether such integration is possible, and if yes, then what would be the business case on integration, which parties may drive it and implement. Since not much was known before e-compliance started working on this problem, the research followed a classical approach of the problem scoping, desk research, empirical research in the form of interviews, analysis of the results and drawing of conclusions and recommendations, see FIGURE 2.1. Interpretation of problem and scoping Research approach and method Desk research Understanding of PCS Interviews List of interviewees / stakehloders Analysis Identification of potential cases Stakeholders Portic Barcelona- Marseille case Previous work Questionnaire and interview protocol Network mobilization to get in contact with interviewees: ecompliance and broader networks Interview scheduling and execution Feasibility (SWOT) Case description Conclusions FIGURE 2.1: Research approach 2.2 Arguments for Scoping While scoping the problem, several potential PCS integration benefit areas have been identified as the result of desk research. These potential integration benefit areas have been defined as follows: 1. Integration with the systems outside of the EC. This area is related to Services related to extended supply chain, supply chain visibility and better security profiling. In case if container is transshipped at an intermediate port, PCS integration can greatly improve visibility, allowing data (1) on what ship the container is travelling (direct service of not)? (2) In case of transshipment, where transshipment will take place / have taken place, what is the next ship, what are the chances that the container would make it to the next ship on time. (3) In case of a missed connection, what are the other possibilities? These data elements will lead to a better estimation on the container release time at the destination port. 14

16 Although container routing information could be obtained through direct bilateral links with the carriers, these carriers should be connected to the PCS of the destination port, which in almost all instances an unrealistic assumption. Therefore, it should be advantageous to collect these data through PCS. This would realize an increase in attractiveness of integrated trade lanes under the condition that the major (transshipment) ports are integrated (e.g. Singapore, Rotterdam, Shanghai) 2. Shipping line perspective. The shipping line perspective is centered on the idea of transmitting information only once, as opposed to transmitting at each (EU) port. For instance, the list of hazardous items onboard is the same at the port of departure and at the arrival port. In addition, terminal-related information can be transmitted only once, assuming an integrated PCS can take care of subtracting / adding container-related data items, as physical containers are taken off the ship and / or loaded onto the ship. The shipping line will also benefit from a smaller number of PCS to link to, as well as operational efficiencies realized at the ship agents, who work on behalf of the shipping line. 3. Freight forwarder / consignee / cargo owner perspective. In case if a freight forwarder or cargo owner works / routes its cargo through a number of ports and handles port-related issues itself, it would need to connect to a number of PCS. An integrated PCS will make it possible to provide (1) container status and container release message from one source; (2) bank integration with respect to payment messages becomes viable; (3) speeding up container release, especially if area 1 on integration with non-eu PCS is tackled. 4. Maritime single window. NSW: Directive 2010/65/EU (Maritime Single Window) requires that from June 1, 2015 onwards (1) Ships must be able to report data electronically; (2) A ship needs to report one data element only once; (3) National authorities should cooperate with each other; (4) They NSW s must use the same data (re-use) as this data is reported only once. By 1 June 2015 EU countries had to ensure that they have NSW and NSWs provide and share information within EU- country- level authorities (through SafeSeaNet). PCS can include interfacing functionality for the NSWs such that private parties can report to NSWs using interfaces provided by the PCSs. An integrated PCS can provide an alternative (horizontal) infrastracture with respect to EMSA / SafeSeaNet reporting (as opposed to vertical integration via the NSWs) 5. Big Data Applications. A PCS is a rich datasource on various data elements. An integrated PCS is richer than an individual. Network effect (information growth with the number of nodes squared) is possible, however, under a condition of sufficient data anonymity. From the big data applications, business intelligence can be created, but also statistics bureaus, authorities of different levels (port authorities, local, national government) and researchers can directly benefit. The big data area shifts the focus of an integrated PCS from servicing community to the function of data an intelligence provider. Practically, it will require an agreement of PCS users that their data will be aggregated and used by 3rd parties Within big data applications area, three approaches can be identified. (1) Data value approach: creation of valued data using / combining different sources; (2) Business intelligence: prediction of transport demand on certain trade routes in EU (fleet / empty containers positioning), extensionf the operational planning horizon to a few weeks; (3) 15

17 Improvement of operational environment, which includes: facility wating time prediction, advanced fleet optimization, collaborative environments (intercompany optimization). 6. Backbone network. This area also known as physical internet and is related to an introduction of intelligence and decision making capacity into the PCS. With respect to container transport, possible applications include re-routing of containers on the way from origin to destination as a response to adverse network events (e.g. dalys and service cancelations) or in the context of Synhromodal operations, where network resealeanse, costs and environmental impact are decisive decision variables. For instance, an integrated European PCS can help choosing hinterland connection not only at the destination port, but the destination port itself. Freight forwarder can get decision support system via virtual port systems (ETA at different ports, available hinterland options at those ports at container release time), as an integrated PCS can provide automation of these decision support systems. Backbone network has a potential for a more efficient routing and positioning of the empty containers as (a) shipping lines inform freight forwarder where to deliver empty container and (b) a number of shipping lines (an alliance) that pools containers together and if necessary reroutes containers on loan. Internal testing of these potential cases / integration domains within the e-compliance consortium has led to a reduction of the possible scope with respect to potential case areas. The big data and backbone network areas have been assessed as no go as these integration areas would require data sharing with 3 rd parties, which at the moment of research did not promise to open up. The area of maritime single window was suggested to be considered out of scope for this research, as the developments with respect to Directive 2010/65/EU have been delayed and unclear in relation to national implementations. Nonetheless, in the course of interviews, there have been interesting comments and clarifications on the NSW / MSW. The e-compliance consortium considered the shipping line perspective to be the most promising in the context of the project. To some extent, the cargo owner /consignee, freight forwarder perspective has also been considered promising, however limited due to the fact that only a minority of these stakeholders deal with the PCSs directly. The Integration with the systems outside of the EC has been considered interesting and promising with respect to customs and terminals, and global pipeline functionality for the cargo owners. In principle, this internal assessment of possible integration areas has already contributed to the understanding on the most promising PCS functionalities that can be of use for the integration purposes. Therefore, WP 5 has proceeded further by approaching a broader set of stakeholders in the interviews. 2.3 Interview Stakeholders e-compliance WP1 and WP4 have considered requirements with respect to PCS integration value proposition. These work packages provide an initial list of stakeholders and an assessment of their 16

18 tentative positions with respect to PCS integration. TABLE 2.1 summarises this information and insights. TABLE 2.1: Requirements and observations derived from D1.1 and D4.1, enhanced with preliminary analysis with respect to requirements and observations Stakeholder incl. Requirements description of stakeholders. explanation of why they may be potential users European Commission (DG Move) (EMSA) (EU Maritime Safety Agency gathers and combines info from all different sources and shares combined results with national authorities. Operational services are Vessel Reporting (to control fishing, piracy, etc.), Earth Observation, Integrated Maritime Services, and Pollution Response Services). European States Harmonise European port process formalities Simplify port processes Observations Union is highly dependent on maritime transport for its trade with the rest of the world and within the internal market Shipping has several advantages, such as its lower costs, and a lower impact on the environment in relation to the amount of cargo carried Shipping is not used to its full potential, also due to considerable administrative burden Speed up implementation of Implementation of National Single regulatory changes along Windows the chain of national/local authorities and operators Control/address misnondeclarations Control measures and/or Clear responsibility path inaccuracies in data Measures to avoid repetitive errors or reported to EMSA incompliance Member Eliminate local disadvantages due to excessive administrative burden Become de-facto standard for Member State operators Maintain compatibility with European standards Speed up implementation of regulatory changes along the chain among local authorities and operators Through harmonisation of European port process formalities Port Community System may play facilitator role for local operators to adapt to national standards Through harmonisation of regulation, reporting formats, data sets, coding standards and use PCS to facilitate adaption of reporting parties internal systems. National Single Window Data harmonisation Eliminate/convert local port coding standards Electronic data exchange Automate data/document submission Distribute data/documents To be executed under AnNa project among local single umbrella windows: information that is required by law to be reported only once 17

19 Port Authority (ESPO) Input from other EU countries Via EMSA-SSN (not planned) see below Access to vessel i.e. From NSW/EMSA-SSN. SSN has information from other currently only limited value for ports that stakeholders are mainly data providers within and do not always get access to data. SSN should be more proactive in terms of automatically disseminating information to ports related to arriving vessels If available and reliable, SSN provided information can complement data information exchange from existing port systems (e.g. Hazmat declarations) Early access to vessel schedules Separate vessel information requirements from port operations Avoid conflicts in berth assignments or anticipate heavy port traffic conditions Clarity on information/documentation needed to authorise vessel entry (avoid delays in vessel operations) Need to clarify the relation Avoid two co-existing single windows, one between the national single for vessels and one for cargo reporting. window development and the e-customs initiative Better coordination with other initiatives (e-freight, e- navigation) Harbour Master Timely information To decide on vessel entrance authorisation Vessel operating agent / Carrier /Ship owner (WSC/ECSA) Agile communication with stakeholders Control of erroneous data submission To request missing/additional documentation, to communicate entrance denial etc. Spot incompatibilities with data declared in other ports Documentary harmonisation Standard formats and communication flows Communication Captain with Port process harmonisation and simplification Control of extended inspection Eliminate unnecessary data/document submission Communication problems vessel2office to make vessel captain understand and comply with port process formalities in time due to significant differences among countries Establish single set of data/documents to be submitted (at least at EU). Agents have difficulties to determine for themselves if certain vessels require extended inspection. This data can be forwarded to them via EMSA Receive and process input from other EU countries, i.e. via EMSA and NSW (not planned) 18

20 Ship s captain (IFSMA) Cargo owners/freight forwarders (CLECAT) Vessel Document Management System Mechanisms (national, EU, IMO) to assess consequences when putting forward new procedures Less manual working procedures - More standardisation and digitalisation Better coordination, exchange and sharing of data one stop-shop (inspections, ports, authorities) Simplified process in ports: - Increased efficiency in transferring goods - Reduction of administrative costs - Reduction of human error and time in the information transfer process between relevant parties (paperless documentation) Need for visibility real time date Plan for set of data and documents needed by the vessel on its route through various countries and ports with regulatory differences Avoid stamps, copies and ink signatures Interconnectivity between systems (PCSs) will help but neutrality and confidentiality of information must be guaranteed. Interconnectivity between systems (PCSs) will help but neutrality and confidentiality of information must be guaranteed. 19

21 Port Community Systems (EPCSA) Not to duplicate existing business processes and to use those messages that are already in use by the Maritime and Logistics Industry within the EU 2.4 Interview Protocol To our knowledge, Port Community System integration is a new research subject, such that there are no published research results available on the topic. Therefore, this research approach puts the emphasis on obtaining first-hand experience and opinion of the stakeholders to whom PCS integration can potentially be interesting. The stakeholders have been approached with a request to take part in an interview, where the potential for PCS integration was to be discussed. The interviews have been prepared with the open questionnaire and the interview guideline. The interview guideline is to provide interview guidance for the discovery on to what extend integrating PCSs can provide added value for different stakeholder groups. The interview guidance together with the questionnaire were not sent to the (potential) interviewees before the interview. The protocol included the procedure that first an introduction round was to be held, and then the substance of the question was to be explained to the interviewee. The following text has been used as the explanation on PCS integration and as the guiding questionnaire. Definition of PCS Integration: Integration between PCS s enables the exchange of data and documents regarding specific vessel voyages including information concerning routing and goods and people on board, in order to allow the transmission of data between subsequent ports without the need to report the same information multiple times to different PCSs. Background materials: e-compliance project D1.1 and D4.1 described the results of respectively the stakeholder analysis and interviews with the relevant parties in the Barcelona port community. In other ports and port communities, the stakeholder group may well be broader. Hence, the expected value of PCS integration for stakeholders in other ports needs to be identified as well. 1. Intro by TNO a. Who we are (TNO and interviewer) b. Purpose of the interview: very short on ecompliance and PCS integration 2. Short company background a. Interviewee short introduction b. Company, industry, size, core business, core stakeholders 3. Does your company use (a) PCS(s)? 20

22 a. Which PCS(s) (single / multiple)? b. Which functionalities? c. Would you like the functionality to be extended? In what way and why? 4. Open question: please outline your vision of PCS and PCS integration: a. Why would PCS integration be relevant for your organization? i. Which specific functionalities? ii. Which documents should be exchanged between PCS on your behalf? b. How would the difference be measurable in your organization? c. How much do you expect this measure to improve after PCS integration? (what is the current value, what would be the future value?) d. Would there be an extra value for you to work with one PCS instead of being connected to a number of PCSs? e. Assuming that PCSs are integrated, would you need a (substantial) adjustment of your processes and IT systems to reap benefits of the integration? f. What are the main cost reduction posts or income / profit generation possibilities? (Do you foresee additional business opportunities for your company?) g. Could you quantify / estimate annual monetary effect of PCS integration for your company / organization? Could you attribute those to specific tasks / operations? h. Could you quantify / estimate monetary effect per unit of throughput (e.g. container handled, port visited, shipment info request, etc). Could you attribute these to specific tasks / operations? 5. Open discussion: please provide your thoughts on the barriers of PCS integration, main beneficiaries and opponents of it, as you see it. Who would oppose it and why? 6. Closure a. Did we cover all relevant questions/topics in this interview? b. Who should we talk to in addition? (contact details) c. Agreements on anonymity d. Agreement on check of the interview report e. Agreements on sharing of the analysis with the interviewee f. Can we approach you later with extra questions / need for clarifications? 2.5 Conclusions regarding methodology PCS integration is a complex problem, which has not been seriously studied before. The complexity of the problem lies in the diversity of the Port Community Systems, with respect to functionality and main stakeholder group served; peculiarity of specific port environment, where PCS is established; diversity of the stakeholder group; different and sometimes conflicting business interests of the stakeholders. 21

23 The complexity of the problem has been approached by 1) a study on an integration case within the e-compliance project (see Chapter 7, where the Barcelona-Marseille case is described); 2) analysis of the materials available on the PCS, such as work by Kostas Papagiannakis and Irina Romochkina (2011); 3) gathering empirical data from the interviews; and finally 4) analysis of the interview results. 22

24 3 The role of PCSs A Port Community System (PCS) is an electronic platform that connects multiple systems operated by a variety of organizations that make up a seaport or airport community. It is set up, organized and used by organizations and stakeholders with interests in maritime, logistics and trade in this case the port community. Key drivers for the establishment of Port Community Systems are the need for a standardized communication platform to improve the logistics supply chain systems in terms of punctuality, reliability or costs, and the need to increase the competitive position among ports. Distinctive for all PCS is the link to Customs and Port Authorities and other institutions such veterinary offices or coastguard. Each PCS has the ability to link electronically into many other systems as the local, national or international regulations require. As such, the PCS brings the business-to-business information exchange into the equation, as well as providing the gateway for business-to-government processes, and is therefore complementary as well as supplementary to the Single Window at both national and international level. FIGURE 3.1 shows a typical organisation of PCS connectivity; FIGURE 3.2 shows connectivity provided by National Single Windows. FGURE 3.1. Typical organization of PCS connectivity. Source: project Single window local solutions 23

25 FIGURE 3.2. Connectivity provided by National Single Windows (SeaNews, 2014) In short, the primary function of the PCS is to provide IT infrastructure to the parties operating around the port. The primary function of the NSW is to provide connectivity to the government bodies. The NSW are compulsory and to be provided by the government. The PCSs are not compulsory; however, they may also provide functionality for communication with the government bodies or to be a frond end for the NSW. 3.1 Functions of PCS Kostas Papagiannakis and Irina Romochkina (2011) have conducted research on the functions of PCS and fulfilment of those functions by PCS serving various ports worldwide. They identified seven functional dimensions coupled with supply / transport chain stakeholders, where functionality of PCS can be grouped. These are: 1. Shipping lines 2. Freight frorwarders 3. Terminal operators 4. Customs 5. Port authorities 6. Carriers 7. Stuffing / unstuffing of containers Within each dimension, the researchers identified primary functions. The following list summarizes PCS functions for each stakeholder dimension. I. For Shipping Lines, there are 18 classes of services: 1. Distribution of transport offers of regular lines 2. Booking requests to multiple carriers 24

26 3. Booking information and status 4. Real time tracing of goods status and movements 5. Collection of the B/L information entered by freight forwarders 6. List for goods loading 7. List for goods to be discharged 8. Discharge report (discrepancies between priory announced containers and actually discharged) 9. Customs declaration 10. Dangerous goods declaration 11. Waterway activity 12. Berth soundings 13. Vessel inspection request 14. VPA anchorage 15. Ship departure confirmation 16. Waste disposal notification 17. Harbour dues 18. Vessel declaration II. For Freight Forwarders, there are 12 classes of services: 1. Facilitation for searching transport offers 2. Booking requests to multiple carriers 3. Booking information and status 4. Transmission of the B/L data to the shipping agents 5. Real time tracing of goods status and movements 6. Truck nominations 7. Transport order management 8. Unloading confirmation 9. Dangerous goods declarations 10. Customs declaration 11. Transmission of the Customs clearance status 12. Government agencies (e.g. veterinary inspection) declarations III. For Terminal Operators, there are 10 classes of services: 1. Presentation of reception and storage conditions of dangerous goods 25

27 2. Vessels schedule 3. Information transmitted on list of goods to be unloaded 4. Beginning and end time-stamping of unloading operations 5. Transmission of information on goods to be loaded with seals and stocks, goods remaining on quay to shipping agents, freight forwarders and Customs 6. Customs scan process 7. Truck appointment system 8. Truck arrival pre-notification 9. Fleet management (managing port's vehicles) 10. Rationalization of controls by means of the targeting functions IV. For Customs, there are 5 classes of services: 1. Authorization control and loading receipt 2. Customs declaration 3. Follow-up of shipping agents stock accounting write-off 4. Discrepancy list 5. Customs scan process V. For Port Authorities, there are 15 classes fo services: 1. Ship departure confirmation 2. Harbor dues 3. Vessel inspection request 4. Immigration clearance 5. Surveyor clearance 6. Reception of dangerous goods declaration 7. Vessel arrival notification 8. Notification waste disposal 9. Berth soundings 10. Transmission of the agreement and conditions of dangerous goods landing on quay, physical follow-up 11. Transmission of information on the storage and pick up of dangerous goods 12. Truck nominations 13. Statistics Everyone 14. Supply Chain performance indicators Everyone 15. Berth allocation management 26

28 VI. For Land Carriers, there are 8 classes of services: 1. Viewing of goods status needed to leave the port 2. Web cameras at the terminal gates 3. Truck appointment system 4. Truck arrival pre-notification 5. Barge planning 6. Rail planning 7. Port traffic alerts 8. Transport order management VII. For Stuffing / Unstuffing Centers, there are 6 services: 1. Unstuffing lists recovery 2. Transfer of stuffing instructions 3. Goods status display 4. Checking of the Customs status 5. Container tracing: from the stuffing center to goods loaded on board 6. Unstuffing management 3.2 Why PCSs In general, PCSs have different levels of functionality implementation and functional sophistication. Even within the same geographical areas, PCSs show various levels of party focus and functionality realization. This fact points into the direction that PCSs serve specific local needs of the parties that work with the specific ports. In principle, bilateral communication between the stakeholders around the port is possible. In many instances parties also communicate with each other bilaterally, as for instance, large businesses provide dedicated user interfaces for the clients. However, for the parties, which deal routinely with a number of organizations and businesses around the port, it is more efficient to link up with one single system, as opposed to maintaining multiple data links. Some parties and businesses around the port may exclusively rely on the PCS. For instance, terminal operator and port authorities may require that communication with them is realized over the PCS. As these parties are relatively powerful in the port environment, such a requirement establishes the central position of the PCS. Once it is required to connect with a party via PCS, connections to other parties within the same PCS are more attractive compared to other alternatives. 27

29 PCS can be considered as a part of basic infrastructure provided by the port. The quality of the port s IT infrastructure is one of the factors that play a role in port choice by the shipping lines and freight forwarders. Therefore, additionally to IT efficiency considerations, a second driver of PCS deployment is the competitive position of the port with respect to other competing ports within the same geographical area. 28

30 4 Forms of PCS integration The concept of Port Community Integration (or Virtual Port) assumes exchange of data and documents regarding topics, such as vessel voyage or cargo information, in order to allow the transmission of data between subsequent ports without the need to report the same information multiple times to different PCSs. There are different organisational and technical designs of integration configurations possible. Here we consider four organizational and technical sub cases of PCS integration, ranging from arm s length information sharing of specific messages or information elements to a complete integration in one platform servicing multiple ports. FIGURE 4.1 presents main integration design cases. Port 1 Port 2 PCS 1 PCS 2 Specific Messages / Services Port 1 Port 2 PCS 1 PCS 2.. Port n PCS n Neutral Message Exchange Platform (NMEP) 1: Bilateral message exchange 3: Multilateral message exchange Port 1 Port 2 Port 1 Port 2 Port n Common Interface (CI) Shared PCS PCS 1 PCS 2.. PCS n 2: Full bilateral system integration 4: Central PCS or Multilateral system integration FIGURE 4.1. Four main PCS integration designs FIGURE 4.1 distinguishes four core PCS integration designs. The first design Bilateral message exchange presents the least integration possible, arm s length integration. This design assumes that PCSs function in a way as they functioned before the integration, but some services requiring data from other PCS are realized. For the realization of these services, a data link between the PCS is necessary. The data link is used to transfer messages or specific data for the realization of required services. This design is practical for a bilateral case when certain services are to be realised relatively quickly (and possible in an ad-hoc manner). If there are more than two PCSs to be integrated, the third design Multilateral message exchange may become more attractive, as the number of bilateral links growths proportionally to the number of nodes (PCS) squared and at some point a design based solely on bilateral links would become impractical. The third design, therefore, proposes a central connectivity platform, which can be designed as a National or European Neutral Logistics Information Platform. In this third design, the number of connections is equal to the number of PCSs taking part in the initiative. 29

31 Central Connectivity design (or hub and spoke configuration or single solution for multiple ports), can be found in Portugal. Front office cooperation in Bremerhaven and Hamburg (being able to login to Bremerhaven PCS with Hamburg account and vice versa) is an example of the first design. Geographic cooperation: these two designs also provide bilateral or consortium data sharing of specific messages between PCS or the development of shared services by two or more PCSs nearby each other, e.g. Barcelona and Marseille integration case. Chain cooperation: bilateral or consortium data sharing of specific messages between or the development of shared services by PCSs of two or more distant ports, e.g. hypothetically a Singaporean PCS and a European PCS. The second design Full bilateral system integration presents the case when two ports completely integrate (or merge) their original PCS solutions into one IT system, which provides the same interface for both ports. This type of integration is the most ambitious, as the combined system should take into account local specifics of both ports. In principle, there is no limit on the number of PCSs that could be replaced by one integrated system, however, there might be a practical limit on functionalities of one system that take into account all diverse regional and local circumstances and (municipal) regulations. The fourth design Central PCS or multilateral system integration makes complete PCS integration between a (larger) number of system more practical, by provision of a common interface (front end) for all participating ports, but (temporarily) leaving legacy portspecific PCS in place for realization of locally-specific functionality. The fourth design may present a scheme for creation of a road map for a European Virtual Port System in the future. The following chapter on feasibility of PCS integration considers the question of integration as a whole and the above-considered main integration designs in particular applying a SWOT analysis to them. 30

32 5 Feasibility study on PCS integration A feasibility study aims to objectively and rationally uncover the strengths and weaknesses of an existing business or proposed venture, opportunities and threats present in the environment, the resources required to carry through and ultimately the prospects for success (Young, 1970). Based on the interviews, we first present a SWOT analysis of the four most interesting integration designs, consider factors on why such an integration has not massively happened yet and discuss the integration drivers. 5.1 SWOT analysis on forms of PCS integration The SWOT analysis is split into five separate sub-analyses. The first one (TABLE 5.1) concerns information sharing in general, where the issue is approached from a broad point of view. The following four analyses (TABLES ) provide SWOT analyses for each of the integration designs presented in Chapter 4. TABLE 5.1: SWOT analysis of Information sharing in general Information sharing in general Strengths: Reduced administrative costs: Avoid double entry and data errors, fewer costs to correct mistakes. Better use of information: Optimization of hinterland processes: Reduce delays in processes, reduce transit times (demurrage, detention, other penalties), reduce uncertainties and (resulting) safety stocks and costs of capital, leading to satisfied customers and better price dynamics Optimization of port processes and turnaround times, less handling costs and yard times Synchronization of processes and planning: different transport modes and lower costs Removing physical controls and checks Visibility: Just In Time (JIT) information Avoid delays Lower costs for LSP/shipper, e.g. less demurrage Pre-clearance facilities Avoid customs brokerage (eliminate commercial parties from the chain) Electronic rating/mapping codes: recognize (trusted) parties; Image, brand value: for the European Union (a good place to do business) and individual member states and ports: good visibility, innovative ports; for the shipper: deliver to promise reliable, customer satisfaction; LSP: better control over the product (of the LSP) on maritime side No commercial information, so no barriers in that perspectives Weaknesses: Quote: Every PCS was developed as a solution for a local problem. They are also based on business cases: if a customer asks for certain functionality, it will be 31

33 implemented. All PCS are very different. There is no universal ownership model (Africa: public), Europe: public / private. PCSs are change management projects: getting going into a certain direction. Technology is not an issue, it is the people! Quote: Sharing information may be seen as losing control by the individual ports. Market power: Shippers can or cannot enforce visibility, depending on who is the most powerful party in the chain. Size does matter! Carriers are few and powerful. The larger shippers benefit. Authorities force others by the means of legislation. There are only intermediate benefits for agents, LSPs and forwarders. Protectionism: Carriers and Freight Forwarders (FF) have no incentive to share info as they compete based on information asymmetry with respect to their customers. There is competition between shipping line and freight forwarder, between carrier haulage and merchant haulage: many models are based on earning from inefficiency and intransparency leading to more handling for the terminal owner, larger margin for any agent. It leads, in some instances, to resistance because insight by other parties in their processes could lead to (additional) pressure on margins and interference in their daily operations (commercial value of products under pressure). The parties are reluctant to share information if they do not know what will be done with the information due to data security/privacy/liability, data use, added value considerations: Even the slightest doubt on data or system governance is killing for an initiative ; Resistance: commercial parties (including shippers, carriers and forwarders) do not accept the risk that their commercial information may become visible to competitors. The security issue is too difficult to solve, expensive to engage ( requiring huge investments ) and only long term and uncertain benefits. Unclear answers to the questions such as what is necessary to know? for what purpose? Who takes key decisions, e.g. for the best mode of transport? If you want data, why don t you pay for it?! Who can be the trusted intermediary? Respondents claim multiple reasons for not sharing (their) data: 1. Industry is conservative (strong business case required for convincing) 2. Explanation and political / legal pressure required to stimulate innovation 3. Industry tends to fight against new rules and increased control 4. Conventions say there must be paper documents onboard. 5. Industry quality standards are higher than government. Lacking standardization: many different stakeholders involved, using their separate systems and message formats. Even standard messages are declared in different formats. Missing capabilities to transmit data electronically: air has better capabilities in standardization than sea Legal barriers: governmental organisations often are not allowed to share info with other (commercial and governmental) parties or do not want to be held liable for 32

34 Opportunities: potential mistakes Data analysis, data mining (e.g. strategic stats for ports, competitive advantages or triggering sales actions); Eliminate (roles for) intermediate parties from the chain, resulting in an overall more efficient chain for the shipper; Better value added services, e.g. information services such as 4PL services by PCSs Threats: An increasing resistance of parties who build their businesses on information asymmetry Table 5.2.SWOT analysis of Bilateral message exchange Bilateral message exchange Strengths: Easy solution, short term realizable, arms-length, customized agreements on data exchanged and compensation, small chance of issues with respect to ownership of system disputes, functional and technical requirements differences; Solution is tailored to individual ports needs, control mechanisms, goal alignment is by default realized, benefit from each other s skills, flexible; Weaknesses: Existing infrastructure could be relatively easy integrated in bilateral links. Own developments or adjustments required (no of-the-shelf solutions); When exchanging messages with multiple other PCSs, the risk exists that a company needs many different technical and contractual solutions, potentially limited strategic vision (one-time solution) no standard as such; Need to negotiate pricing bilaterally, especially in complex and competitive environments; Robustness of the solution: if the number of messages grows, will the solution still be able to function as intended? Not possible for small ports without PCS Opportunities: Standardisation of message format eases upscaling to other partners First mover advantage can be potentially realised Threats: Future developments can easily be taken up If the two parties do not have similar levels of technological advancement or market power, one partner could be at a disadvantage; Developments and events around corresponding ports may have strong (adverse) impact on bilateral message exchange systems; Relatively small investment and ease of establishment make the system also susceptible to disruption by external events. 33

35 TABLE 5.3: SWOT analysis of Full bilateral system integration Full bilateral system integration Strengths: Joint effort, long-term reduction in transaction costs, greater social capital, control opportunity, strong commitment, realization of economies of scale, tailored to the needs of individual ports and stakeholders; Weaknesses: Suitable for small ports without PCS, as the needs of those ports can be taken into the existing PCS. Requires a party, which drives a merge. May result in a takeover, as opposed to a merge of equals; Requires great deal of trust, time, commitment, formalization of procedures; Opportunities: Threats: Centralized structure will disadvantage the place where there will be no physical presence anymore. Piggybacking and coordination between authorities; Easy sharing of best practices among ports of merged PCS; also harmonization of the governance structures. Down time of a shared platform ensures problems at both ports at the same time; Once the systems have been merged, it would be very difficult to go back to the old situation with two apart PCS; Changes in either port operations will lead to a change in the common system; The ports will become more dependent on each other (positively and negatively). TABLE 5.4. SWOT analysis of Multilateral message exchange Multilateral message exchange Strengths: Relatively easy solution, arm s length with respect to commitment. Multiple parties work with the same platform or standards, which reduces the effort required to connect with other parties. Economies of scale can potentially be realized; Individual parties have to follow agreed upon rules and message structures, thus no need to reinvent the wheel ; Weaknesses: The solution is scalable, could accommodate a large number of systems. Sources of financing need to be clearly defined; The platform needs to be specified, agreed upon, financed and built first, which will require a strong commitment of the core platform users; The platform has to satisfy the needs of majority of the users, which is difficult given the fact that the PCS business is very divers; The platform has to keep up with the technological developments, legislative change, as well as with the shifting needs of its users; Opportunities: Not suitable for small ports without PCS. Further scaling up of the platform by recruiting new members; 34

36 Threats: Sharing of the same technological approach would lead to harmonized business practices. Security compromise at one of the connected parties can compromise the system as the whole; Bad quality data provided by a system may affect operations of the whole platform; Down time of the platform disrupts the information exchange for all participating systems. TABLE 5.5. SWOT analysis of multilateral system integration Multilateral system integration Strengths: Large potential market: a large importer, transport operator or forwarder will work with multiple ports using a single point of access and underlying local knowledge of existing (legacy) PCS; Integration of large geographical areas, market power in those areas and beyond, economies of scale, small transactional costs and at the same time integration of local specifics; Weaknesses: Small ports without PCS can be relatively easily covered. Development of a new front-end system is complex and costly; Requires a lot of trust of the platform users; Diminishes the role of individual PCS, which may be very awkward politically as well as organizationally; Agreements required on how disputes will be solved and according to which legislator framework and jurisdiction; Chance of data leakage grows and system security is of greater risk; Opportunities: Respondent s quote: Full integration is impossible. Every member state has national regulation and every port has port specific processes. One cannot put everything in 1 system. A big problem would arise regarding legal as well as technical maintenance. In addition, guaranteed uptime for all ports would be a problem. How would you prioritise? Further harmonization of documents, procedures and business practices among the ports served by such as PCS: Respondents quotes on the opportunities of multilateral system integration: 1 specific organization in the EU should demand requirements that simplify procedures Large scale implementation would set a de facto standard with respect to PCS integration specifics DG-taxud new directive in February e-manifest will be obligatory in the whole of EU. Portbase is young, so possibly not happy with the new 35

37 directive: de latest directive prescribed all different declarations. Title said harmonization, but every port developed own system (XML, EDI, WCO, EMSA-style) Threats: External political events will have a large, and probably negative, impact on the integrated PCS; This design is most susceptible for data leaks and privacy violations. 5.2 Interviewees on the current situation Current situation is characterized by only marginal level of PCS integration. There are valid reasons that explain the state of the art. With the exception of a small number of pilot integration efforts, which have been partly subsidized with the public money, there is no real PCS integration today. The promising PCS integration cases are the ports of Barcelona and Marseille integration case of this project (see chapter 7 on more details) and the Bilbao port integration with a few UK based ports. Based on the interview results, the following points explain the current state with respect to PCS integration. It can be noted that the explaining factors of currently not integrated PCS are also present in the weaknesses sections of different PCS integration designs of section 5.1. Market power: The parties who may benefit of an integrated system do not have the necessary market power to force integration efforts. As opposed to private businesses, the authorities can force others by the means of legislation. For the powerful parties, there are now only intermediate benefits possible, as well as the present risk of cancelling of the information asymmetry advantage. Benefits of Obscurity: Carriers and Freight Forwarders (FF) have no incentive to share information and in some perspectives even resistance because insight of other parties in their processes could lead to (additional) pressure on margins and interference in their daily operations (commercial value of products under pressure). The parties are also reluctant to share information if they do not know what is going to be done with it. Complexity and unclear case: PCS integration is perceived as too difficult to solve and establish, expensive to engage ( requiring huge investments ) and only long term (and uncertain) benefits. It is often unclear what specific information sharing needs there are, for what purposes information would be used, who is going to take key decisions. Value of information is not clear, on the other hand, there is reluctance to share it for free. Systems diversity: many different stakeholders involved, using their own systems and message formats. Even standard messages are sent in different formats. The systems currently in operation use different platforms, have different levels of sophistication and scalability. Legal barriers: governmental organizations are often not allowed to share info with other (commercial and governmental) parties or do not want to be held liable for potential mistakes. 36

38 5.3 Concluding remarks PCSs systems of the European ports are hardly integrated today. The main reasons for the current state of the art is the specifics of market power, large benefits of obscure systems for those parties that control data flows, complexity and not obvious case for the integration, systems diversity and legal challenges. The interviewees generally accept that an integrated PCS will bring a number of benefits with respect to operational excellency, costs of the total transport system, quality of transport and competitive advantage to the EC and individual member states. Each of the four possible PCS integration designs have their respective Strengths, Weaknesses, Opportunities and Threats, see TABLEs for more detail. The first design, realizing integration at arm s length message exchange is the most suitable for starting up collaboration and PCS integration, as it is a low risk and the easiest to implement. IF this collaboration is successful, the second design of the full integration of the PCS, in other words, merging them to a single system, should be considered. The first and second designs work well in the case of two integrating PCSs. If the number of PCS is larger than a few, designs three and four should be preferred, as the number of bilateral links grows proportionally to the squared number of PCS-participants. The third design solves the problem of a large number of links through a common platform. The fourth design on merging multiple PCS allows deep integration and one common front-end functionality for the users; however, it preserves (temporarily) existing PCS for dealing with the local knowledge and specifics. 37

39 6 Business cases of PCS integration This chapter looks at the possible business cases of PCS integration in the EU, as well as between EU PCSs and foreign trade-linked PCSs outside the EU. A full-fledged business case should contain data on expected investments, earnings and expenses. The information presented in this chapter considers integration business cases, where required investments and benefits can only be assessed in the qualitative terms. Therefore, the level of maturity of the cases is lower than that of a full-fledged business case. This is the result of the chosen approach, where opinions of a (relatively large) number of professionals have been discovered during the interviews. This information contains only qualitative assessments of the required investments and potential benefits. The empirics of the chosen approach compensate this limitation, as information presented here is the first-hand opinion of the leading industry experts. Therefore, the cases presented in this chapter present viable leads to possible future integration efforts. Due to the fact that PCSs are a part of the basic infrastructure provided by the port, PCSs are relevant to all users and stakeholders of the port. When regarded as such, the port community not only consists of the port centric parties such as the port authorities, terminals and nautical services, but also authorities such as governmental inspection bodies and infrastructure managers, global maritime stakeholders such as shipping lines and agents, and parties in the hinterland, such as shippers, forwarders, inland terminal operators and hinterland transport operators. Hence, the port community consists of a multitude of partners with different backgrounds, stakes and requirements. The interviews indicated that for each type of stakeholder, other specific data elements and forms of data exchange between PCSs are relevant. For example, the automated exchange of messages such as the Berman, Wasdis, Paxlist and Hazmat messages are particularly relevant for the stakeholders responsible for re-entering the data in other systems. However, supervisory bodies acknowledge that data re-entering may lead to typographical errors and at least partially automated message exchange may well provide more reliable data as inputs for governmental risk assessments. The role of parties in the global supply chain determines their position towards information exchange between PCSs. In general, there are two types of parties: parties with an interest in the cargo and the parties with an interest in the infrastructure and transport means. Moreover, the interviews indicated four different areas of interest of different stakeholders. FIGURE 6.1 provides an overview of the types of information and services of PCSs with value for different parties in the port community, with in green the different areas of interest: 1. Infrastructural and vehicle related information and services regarding the seaside status and process for the facilitation of private companies and governmental bodies. 2. Infrastructural and vehicle related information and services regarding the port centric status and process for the facilitation of private companies and governmental bodies. 3. Infrastructural and vehicle related information and services regarding the landside status and process for the facilitation of private companies and governmental bodies. 4. Information and services regarding the logistical and compliance related status of cargo for the facilitation of private companies and governmental bodies. 38

40 Within these four areas of interest, interviewees mentioned eight specific cases with respect to potential useful cases of PCS integration: Case 1: Single login and user interface for multiple PCSs; Case 2: Visibility of container location and status; Case 3: Reuse of ship compliance data from previous port; Case 4: Reuse of information in case of a last minute port change. Case 5: Availability of exit manifests; Case 6: Sharing of container weight information from port of origin; Case 7: Reuse of export information from PCS of origin to prefill import declaration; Case 8: Prediction of terminal berth time; Infrastructure and transport means 1 Cargo Seaside related status and process information and services Port centric status and process information and services Landside related status and process information and services Ocean carriers Ship agents Ship captains Coast guard Maritime supervisory bodies 3 Port Authorities, Harbor master Terminal operators, Degassing services Nautical services (towers, rowers, pilots) Ship suppliers, Stevedores Vessel and cargo safety services Hinterland transport operators (rail, road, barge) and their agents Inland depots and warehouses Tally companies, bonded warehouses Inland waterway and port police National infrastructural supervisors Exporters, importers Freight forwarders Customs agents Financial institutions Customs administrations National plant protection agencies Phytosanitary inspection agencies Veterinary inspection agencies Trade associations Umbrella organizations FIGURE 6.1: Overview of types of information and services of PCSs for different types of parties in the port community This section presents the ideas as expressed by the interviewees during the interviews, per case structured in the following way: 1. Desired functionality: what interviewee sees as desirable or beneficial for a specific (set of) stakeholder(s) 2. Description: description of the current vs. the new situation 3. Beneficiary: main beneficiary(ies) and their expected benefits 4. Value: value (benefits) associated with implementation of the functionality 39

41 5. Requirements: what is needed with respect to information, data, process and technology to realize the desired functionality 6. Investment: who are the main investors and what the required investment to realize the desired functionality is. High / Medium / Low quality assessments can be used. 7. Concerns: concerns related to the case regarding functionality, requirements and implementability 8. Potential: estimation of potential of the case. Qualitative assessments can be used (Low / Medium / High) 9. Source: the type of stakeholder / interviewee who expressed the case, and in case of multiple interviewees expressing the same case, the number of interviewees expressing it. Below we present the eight cases according to this structure. Case 1: Single login and user interface for multiple PCSs Desired Single login and user interface for multiple PCSs functionality Description Beneficiary Value Requirements At present, seaside and hinterland customers of PCSs use multiple PCSs. For example, it is likely that a shipper in Düsseldorf ships containers via Antwerp as well as Rotterdam and a shipper in Wolfsburg utilizes the services of the ports of Bremerhaven and Hamburg. In general, the shipper would require different subscriptions and authorizations to access the services of the different PCSs. The PCSs of Bremerhaven and Hamburg are exceptions though: a PCS user can, based on a cooperation between the two PCSs, access services of both PCSs with a single login and user interface. A single login and user interface for multiple PCSs creates administrative efficiency for primarily PCS users at seaside and in the hinterland, as port centric users are often geographically bound to one port. Hence main beneficiaries are carriers, nonlocal carrier agents, forwarders and hinterland transport operators using multiple PCSs and larger shippers (as smaller shippers often do not use the services of PCSs, but rely on the information services of their freight forwarders). The service is only relevant for parties using multiple ports, which narrows down the impact. These users increase administrative efficiency as they have a single point of contact for their port information services for the ports they use. This translates efficiency in day to day operations and the comfort of a single screen, but more importantly, also into ease of integration with the company systems of the PCS users, which brings global data pipelines and a shared information position throughout the supply chain one step closer. In order to create a single login and single user interface, the port community systems involved in the integration trajectory need to agree upon organizational aspects, resources and financial aspects, and to what extend the services can be accessed through the single login and single 40

42 user interface. Organisational aspects that need to be addressed include ownership, management of functional and technical requirements and division of duties. Resources and financial aspects which need to be agreed upon include the compensation of one PCS if other PCSs access its data, pricing of services towards users, sources of financing for development and maintenance, and division of tasks and time devoted to develop, test, implement, operate and maintain the single login and single user interface. In addition, services offered based on data shared and branding of services need to be agreed upon, as ports and PCS may compete in the same local transport and cargo markets. The organizational aspects closely relate to legal and ethical aspects that need to be addressed: the legal framework, commercial terms of use for data and solutions, Service Level Agreements towards customers and cooperating PCSs, and the social and societal desirability of data sharing. To conclude, also the technical aspects need to be taken care. Examples are agreements on e.g. the architecture and data models for the shared solution and agreements on how to deal with the existing infrastructure, reliability (uptime), maintainability and development of data availability. Who should invest? Concerns Potential PCSs are the only parties required to enable this case. PCSs aim at maximizing their business-to-business proposition. However, in this case, PCSs need to invest but the willingness to pay of users is unclear. Port centric parties are often the primary group of stakeholders in PCSs, but these parties are not likely to gain from the solution. The question is whether efficiency in day-to-day operations and lowered barriers in integration of company systems with multiple PCSs are a convincing proposition towards the other stakeholders. Low-Medium Case 2: Visibility of container location and status Desired Maritime and port container traceability functionality Description Real time insight in the location of containers is lacking. In addition, when a container is to be expected at a transshipment point or a point of transfer of ownership is often not accurately known as well, due to which each party down the stream (the terminal, border inspection authorities, hinterland transporter, shipper) is forced to use more slack in their time schedules. Only the party handling the container at a certain moment in time has an exact idea on where the container is. For example, after berthing, it can take up to two days to unload a ship. When a container is unloaded depends on the location of the container on the ship. Once unloaded a customs release needs to take place. In some 41

43 cases, an inspection is required, which can take up to one day, but needs to be scheduled as well, which increases the actual throughput time. When the customs release has taken place, the terminal checks whether financial obligations have been fulfilled, which leads to the commercial release of the container, after which the container can be picked up for hinterland transport. In a bad scenario, this process can take a week, while in theory it might be possible to pick up a container hours after berthing. When downstream supply chain partners know when a container is about to be unloaded, whether a container needs to undergo a customs inspection and when the container is about to be released, they can anticipate this in their time schedules. If not, the lack of insight in arrival times and container status causes a snowball effect in the supply chain increasing unpredictability of arrival times along the supply chain. Improved information quality is an important aspect as well. Increased visibility of ship and container status and location would create visibility of anomalies between reported information and the reality. Terminals and port authorities mention shipping lines may have incentives to adjust the estimated arrival times to reserve quay space that otherwise might be used for another ship. Hinterland parties mention terminal may have incentives to maintain intransparency because it provides them flexibility in their handling processes, e.g. when to bring a container to an inspection location. Beneficiary Value Requirements Investment Visibility of container location and status is primarily important for downstream supply chain parties. The terminal requires information on when a ship is to be expected in order to make an optimal schedule and optimize the use of its assets. Inspection bodies require information on when a specific container can be expected at a designated inspection location. Cargo owners, insurers, forwarders and hinterland transport operators need to know when the container release is to be expected in order to schedule hinterland processes. The main benefit of increased visibility as well as better data quality is planning: terminal planning for the terminal, capacity planning for inspection agencies and hinterland planning for hinterland stakeholders. For a shared information position on location and status of ships and containers, all parties in the supply chain need to share data. This requires interoperability (and harmonization) of carrier systems and PCSs, terminals and PCS regarding container location and status in a terminal, and information services (ETA, ATA, container unloaded notification, routing at terminal, are required inspections performed, has container been brought to scan inspection timely, customs and commercial release status, gate out). PCS to PCS integration is mainly important for a better prediction of arrival times of a ship in a next port. Carriers and terminals have the information required to optimize planning 42

44 processes of other parties in the port community. Concerns Potential Carrier and terminals have no incentive to provide insight in their processes or share this information (upfront) with PCSs and the port community behind a PCS. Medium-High Case 3: Reuse of ship compliance data from previous port Desired Reuse of ship manifest and notification data from previous port functionality Description In the current situation, a ship s captain is responsible for accurate declarations and notifications in each port. In practice, ship agents most frequently file these reports to the port authorities. Although the reporting obligations vary from port to port, depending e.g. the local geographical circumstances and national legal framework, much information needs to be refiled in every port. If a next port would get ship manifest and notification data such as the Wasdis, Hazmat, Berman and Paxlist information from the previous port and the PCS could make it available for the captain or ship agent, this party could just modify it if required. Beneficiary Value Requirements Investment Concerns Potential The main beneficiaries are ship agents, because for them it becomes easier to fulfil their obligations to the port authorities. Port authorities might benefit as well, as the quality of the information filed may improve. The value for the ship agents consists of avoided s and phone calls, re-entering in different systems, mistakes and the effort of correcting mistakes. The main requirements are digital manifest data of the previous port in an agreed upon format and the means to share the information between subsequent ports. Chapter 7 explains in detail the technical requirements and solution for this case, which has been piloted in Barcelona and Marseille. PCSs of subsequent ports need to be willing to share the information and facilitate the infrastructure to do so. None. The information is not commercially sensitive. Whether the PCS are willing to invest, depends on the added value they expect to be able to offer their customers. Medium Case 4: reuse of information in case of a last minute port change Desired Forwarding information required for the local customs clearance procedure 43

45 functionality Description (in case of import as well as export) to the appropriate PCS in case of a (last minute) change in port of discharge (import) or port of loading (export). Some PCS facilitate the filing of different types of customs declarations through their systems. In practice, the port of discharge or the port of loading may change after a declaration has been filed. In that case, shippers or their (customs) agents need to file (new) declarations, which can be prevented if PCSs could forward the required information to the PCS of the actual port of discharge or port of loading. An example is a container, for which a shipper has a T1, that was intended to leave Europe via the port of Rotterdam, but actually leaves Europe via Antwerp. Depending the circumstances the carrier will bear the costs for the transport from Rotterdam to Antwerp (e.g. barging to Antwerp), but goods are under customs supervision, hence an NCTS* declaration needs to be filed and an MRN must be deregistered. This is at present typically the responsibility of the shipper and performed by his (customs) agent, but could be performed by PCSs if they would share this information. )* With the New Computerised Transit System (NCTS or Transit), noncommunitairy goods can be moved between the 28 EU Member States, the EFTA countries, Turkey and Macedonia under Customs supervision. In order to use the transit procedure, the shipper or a representative needs to file a declaration by means of a message in NCTS. Requirements Shippers need to agree on their data being shared by PCSs. PCSs need to be able to facilitate the filing of different types of customs declarations through their systems. PCSs need to be willing to share this information with different PCSs. PCSs needs to (be able to) forward the cargo, shipping and shipper related data required for (adjusted) declarations and the PCS in the actual port of discharge or port of loading needs to be able to handle this data. Investment Concerns Beneficiary Value Primarily the PCSs need to adjust their systems in order to be able to offer this as a service. Customs agents lose business, because in the current situation, they charge the customer for filing a new declaration in the new port of discharge; Even though cargo-owners agree to sharing their data, ports and PCSs may have commercial incentives not to share cargo and owner-related data with other PCSs (ports often being the primary shareholder in a PCS). The Shippers are the main beneficiaries in this case, because in the end, they pay for the services of customs agents that may no longer be required in the case of last minute port changes. In the example of NCTS at exit: a shipper may save approximately 25 for changing NCTS by a customs agent, but how much PCS will charge for the 44

46 service is unknown. Potential Limited due to the dependencies on PCSs being able to facilitate Case 5: Availability of exit manifests Desired Availability of exit manifests functionality Description Beneficiary Value Requirements Investment Concerns Potential The confirmation of exit can prevent a VAT notice. Be aware, VAT is a nationally based tax form, for which regulation is different in different member states. For example, if a Dutch shipper exports Dutch goods to extra-community countries, an export declaration is required and customs formalities need to be fulfilled. After the customs authorities receive the notification of Arrival at Exit and the exit manifest from the carrier, they provide the Confirmation of Exit to the party who declared the goods for export (often the shipper, his forwarder or his customs agent). If customs authorities do not issue a confirmation of exit, an export can be invalidated. In that case, the shipper may need to pay VAT (which is not required on exported goods) or substantiate that the goods actually left the EU based on other documents, such as the exit manifest. If the exit manifest would be more easily retrievable, this would save shippers the time and effort to search for alternative evidence. Shippers The total value of wrongful VAT charged on exported goods depends on the cargo value and occurrence and is the product of the tariff, the value of the goods and the fraction of unjust non-confirmations. For the shippers, avoiding non-confirmations would save the shippers also administrative costs of chasing the confirmation of exit and searching alternative evidence (e.g. the manifest). The first requirement is to realize the sharing of exit manifests between carriers and PCSs. The second requirement is that PCSs should make the exit manifest available for shippers and their agents. A ship can exit the Union from many different member states. Hence, if a shipper would want to get the Exit Manifest for its container(s) from its own PCS, the third requirement is that all PCSs should have a form of mutual integration. Carriers and PCSs need to make adjustments to their systems to facilitate the sharing of the exit manifest with shippers. The manifests may contain commercially sensitive information, but the primary concern is that interfaces are built for situations that hardly ever occur. Low, e.g. in the Netherlands, the percentage non-confirmation is low and the Dutch customs administration offers other practicable ways based on a company s own administration to prove that the goods left the EU. 45

47 Case 6: Sharing of container weight information Desired Sharing of container weight information functionality Description Beneficiary Value Requirements Investment Concerns Potential July , container weight verification a condition for vessel loading will become legally binding ( Shippers are responsible for the verification. Weight information is relevant for the balancing of a ship and to prevent overloading of, for example, a truck. In addition, when one knows the bill of lading and what can be expected, the weight can serve as an indicator of the container is said to contain is the actual content. Governmental inspection bodies can check the expected and the actual weight of cargo to confirm legitimacy of trade. Carriers and terminals can improve stowage plans. Shippers can use the weight verification as a monitoring tool for non-overloading, as they are responsible for the correct stuffing of containers. Sharing container weight information may also ease the burden the weight verification condition imposes on shippers as at present it is not yet clear which measures are allowed, e.g.: weighing on a certified scale or reporting the sum of the tare weight of the empty container stuffing, the packaging materials and the cargo good. In addition, each member state proposes different error margins. Container weight information can help in detecting fraud and increasing security through fraud prevention and stowage planning for transshipment. Container weight information of port of loading to be shared with the port of transshipment and/or unloading. PCSs for sharing, terminals for data acquisition. None. Low, impact differs per member state because tolerances are different, e.g. in NL 5% and BE 2%. Case 7: Reuse of export information from PCS of origin to prefill import declaration Desired functionality Reuse of export information from PCS of origin to prefill import declaration via PCSs Description Beneficiary Information entered into systems in order to fill out the export declaration can be used to pre-fill the import declaration. These services can be offered via bilateral agreements between PCSs and are primarily viable for major trade lanes. Main beneficiaries are the declaring parties, who do not have to re-enter information on the same goods twice. They do however have to check the entered data. For regulatory and financial reasons, the way goods are to be declared at export differs from the way these goods must be declared at import. There is also a potential benefit for the customs authorities to know 46

48 what has been declared at export, as they may be able to compare import and export customs declarations. Value Requirements Investment Concerns Potential The value depends on the availability and use of a Global Data Pipeline, linking the port of origin and the port of destination. The primary benefit is the avoided time and effort of data re-entry (estimated 15 minutes per import declaration). A global pipeline is required, as goods are shipped around the world and PCS integration of the exporting and importing country would be required in addition to the use of PCSs for customs declarations. Export declarants need to share data of export declarations with PCSs and the PCSs of origin need to share the information with the PCS of destination to make it available to the declarant at destination. Shippers may be resistant to sharing more than legally required information with customs authorities. Low Case 8: Prediction of terminal berth time Desired functionality Better scheduling of ship handling at terminals. When a vessel approaches a port, if no other system is involved, port will just FIFO unload vessels. Description If the port and terminal(s) have a complete picture on incoming ships and their ETAs, the port and terminal(s) can influence arrival process for the benefit of all parties involved. In practice, it will mean that the ships that would have to be anchored and wait for their tern at the terminal, would be able to slow down and save on fuel, instead of unproductive waiting. Better schedules and less queuing, through better information about slots at the ports. This is about communication between ports and ships. It is increasingly popular to organize traffic (a lot of savings for shipping lines). The ship communicates with the port of arrival. Beneficiary Value Requirements Investment Concerns Potential Ocean (speed to berth) and inland carriers (transport planning), terminal (planning), port (branding) In liner shipping: schedule to keep, agreement with port for preferential treatment. Most of shipping is without regularity, when ships know there is no rush, they can slow down and save fuel. Also significant for RTM-FLX Complete picture on inbound ships and their ETA s, acceptance by the ship operators of the new scheduling. PCS Willingness of ship operators to be scheduled by other means than FIFO Medium 47

49 7 Technical analysis of integration of MGI (port of Marseille) and Portic (port of Barcelona) This chapter describes the pilot effort conducted by the ports of Barcelona and Marseille on establishing message-exchange level integration of their corresponding PCS systems. The main contribution of this case is a design of a protocol and an API for exchanging information between the PCSs and showing feasibility and practicality of this approach. 7.1 General information MGI (port of Marseille) and Portic (port of Barcelona) have designed a protocol (API) for exchanging information between the PCSs. MGI and Portic have implemented it in a pilot project. The aim of this pilot was to demonstrate how the stakeholders connected to the Port Community System could benefit from obtaining information from other ports for performing the vessel arrival procedures. For the demonstration, the port of Barcelona uses information related to vessels arriving from Marseille. This information is subsequently to be used by the ship agents at Barcelona for the purpose of helping them with the vessel arrival procedure. Finally, in order to help the pilot understanding and user experience, Portic is planning to develop a web site that emulates the system of ship agents for requesting information in a vessel arriving from Marseille. Portic performed a set of interviews with Ship Agents at the Port of Barcelona for the mapping of the needs to be satisfied. Based on these needs, Portic has designed a description of the information to be shared between the Port Community Systems. This description has been presented to the same group of ship agents, who approved it as a feedback (the API description fits into the needs). The next step was to share the document with the MGI and start an analysis for the decision on the technical communication channel, protocols and formats. Basing on the current data in the systems at Marseille and Barcelona, the data to be shared are related to the vessel (similar to the BERMAN message) and outgoing dangerous goods (similar to the HAZMAT message). There are other potential data elements to be shared, for instance Passengers list data. However, the MGI system is limited in that respect, therefore only those data are shared that fit into functionality of both PCS. 7.2 Technical aspects The system for exchanging data is a messaging system. There are other possible ways such as SOAP web services, REST, etc., but user needs showed that the message system was a right choice. For this reason, the API document contains the specification for all the available messages as well as the restrictions, formats and messages for responses (APERAK). The communication is not directly between the PCS s (b2b), there is a central repository with a database and a server waiting for requests. The communication is performed through the FTP protocol in this pilot, so the process starts (is triggered) when a file is received in the incoming folder, and the messages are correctly formatted in XML. 48

50 FIGURE 7.1: Portic & MGI messaging interface All the messages have a general structure in order to build a scalable system and enable other parallel tools such as track and trace data of messages: FIGURE 7.2: General message structure The system provides two possible flows for exchanging information, as shown in FIGURE 7.3. The top design shows that the PCS at origin sends information to be stored in the Port Data Storage; the bottom design shows that the PCS at destination gets information from the Port Data Storage. 49

51 FIGURE 7.3: Inter-PCS messaging. The system also enables the port to share binary documents in any format. This can be useful for sharing additional documents like certificates, etc. The services architecture is depicted in FIGURE

52 The list of message formats is the following: FIGURE 7.4: Services architecture 1. VESSELINFO: Data related to a vessel berth. This message is similar to BERMAN message ( This message is sent by the PCS of the origin port. 2. HAZMAT: Dangerous goods information. This data is related to a previous vessel info message, so the previous step is mandatory. This message is similar to HAZMAT/IFTDGN message ( Only two hazmat messages are allowed for a vessel: incoming and outgoing. The system can receive incoming dangerous goods information, but the useful information for other PCS is the outgoing dangerous goods. This message is sent by the PCS at origin. 51

53 3. ATTACHFILE: Binary file (attachment) related to a previous vessel info message. There can be as many attachments as necessary. This message is sent by the PCS at origin. 4. RESPONSE: Returning message from the server with the response of the previous message received. This message is received by the PCS at origin. 5. GETVESSELINFO: Message for requesting vessel info data to the server. This message is composed by the parameters for obtaining one vessel info message. 6. RESPONSEVESSELINFO: Response for the previous message (matching data). 7. GETDANGEROUSGOODS: Message for requesting dangerous goods data to the server. This message contains the id of the original vessel info message. 8. RESPONSEDANGEROUSGOODS: Response for the previous message (matching data). 9. GETATTACHEDFILES: Message for requesting a list of the attached files of a vessel. This message contains the id of the original vessel info message. 10. RESPONSEATTACHEDFILES: Response for the previous message (matching data). In order to help the PCS s to join the services, a set of xsd files was designed (one for each message). Appendix 1 presents an example of an xsd message, and Appendix 2 presents an example of a linked to xsd message of Appendix 1 xml message. FIGURE 7.5 presents a relationship between main messages: vessel information and dangerous goods 52

54 FIGURE 7.5: Relationship between vessel info and dangerous goods messages 7.3 Business case of information There are currently several regular vessels traveling between Marseille and Barcelona. For this reason the most effective option for the pilot is using a real case. Marseille and Barcelona will select one of them from their database for exchanging data. Marseille will act as sender for the pilot and Barcelona will act as receiver, so the vessel will travel from Marseille to Barcelona. TABLE 7.1 shows the steps to be performed in the pilot. TABLE 7.1: Actions related to message sharing # By Action Message involved Expected result 1 MGI Send the data of a vessel leaving the port of Marseille to Barcelona VESSELINFO Data saved at central repository 2 MGI Send the dangerous goods data related to a previous vessel info 3 MGI Send two certificates related to a previous vessel info 4 PORTIC Search an incoming vessel from Marseille of a vessel (by DANGEROUSGOODS ATTACHFILE GETVESSELINFO Data saved at central repository Attachments saved at central repository The data sent in #1 is received 53

55 IMO) from a date of departure. Note: Portic knows the regular lines from there, so a call for each regular line should be performed. 5 PORTIC Search for dangerous goods related to the previous received vessel 6 PORTIC Search for additional documents related to the previous vessel 7 SHIP AGENT Portic (acting as ship agent for the pilot) will manage the port call request related to this vessel at the port of Barcelona, and will reuse the receive data from Marseille. GETDANGEROUSGOODS GETATTACHEDFILES Ship agent system (Special screen designed for the pilot) The data sent in #2 is received The attachments sent in #3 are received Most of the data is completed automatically. FIGURE 7.6 shows the relationship between system and stakeholders and FIGURE 7.7 provides a ship s agent screenshot. FIGURE 7.6: Relationship between system and stakeholders 54

56 FIGURE 7.7: Ship agent screenshot 7.4 Data storage The implementation includes a central repository (database) that stores data and binary files. This means that we have to think about the disk (data storage) requirements. Portic has performed a study based on a real use case with the following estimations of required storage space, see FIGURE 7.8. The data is stored in a SQL structured database. The main tables in the database are the following: o o o o o o o vi_portcall: Port calls. All the tables depend on this vi_vesseltech: Vessel technical data. vi_ramp: Vessel ramp positions and sizes. vi_ispsinfo: ISPS information vi_crewpassengers: Crew and passengers information vi_expandedinspection: Data related to the last inspection applied on the vessel. vi_dangerous goods: Dangerous goods information 55

57 vi_dgshipments: Shipments with dangerous goods vi_dgequipments: Containers with dangerous goods vi_shipmentgoods: Dangerous goods cargo in shipments vi_shipmentgoodseq: Relationship between dangerous goods cargo and equipments. This is required to know the location of the dangerous goods. 56

58 FIGURE 7.8. Main tables for data storage 57

59 FIGURE 7.9. Storage of attachments 58