EUROPEAN COMMISSION DG-TREN Euromar EEIG. Intermodal Portal Project FINAL REPORT

Transcription

1 EUROPEAN COMMISSION DG-TREN Euromar EEIG Intermodal Portal Project FINAL REPORT File Name: IP FINAL REPORT V Version Date: 6 MAY 2002 Status: Distribution: Abstract: FOR DISTRIBUTION PUBLIC This document summarise the work carried out and the results obtained by all the partners. IP Consortium IP Final Report v May 6 th,

2 QUALITY CONTROL Originator(s): Visa and Date: Technical Manager (M. Fernandez) Appraisal authority: Visa and Date: Project Management Board Appraisal Authority: Visa and Date: Project Manager ( ) Appraisal Authority: Visa and Date: DG-TREN Project Manager IP Consortium IP Final Report v May 6 th,

3 VERSION HISTORY Version Date of creation Status Author Changes/Comments 01 18/12/01 Draft J. Rocha For internal review 02 15/01/02 Draft Jose Francisco Vidal, M. Fernandez Conclusions 03 28/01/02 Draft Consortium Overall changes 04 08/02/02 Final J. Rocha Efforts tables 05 06/05/02 Final M. Fernández Changes in response to EC requests DISTRIBUTION LIST Name Project Management Board Project Officer Company Euromar EEIG PM EC DG-TREN IP Consortium IP Final Report v May 6 th,

4 Definitions and Acronyms AT: DG: DPM: EC: EDI: EDIFACT: EEIG: FT: NCA: PM: PMB: PQM: RM: SC: TT: UC: WP: WPL: SL: SA: VY: CR: CRP: AE: Awareness Team Directorate General (e.g. DGVII - Transport) Deputy Project Manager European Commission Electronic Data Interchange EDI For Administration, Commerce and Transport European Economic Interest Group Financial Team National Competent Authorities Project Manager Project Management Board Project Quality Manager Repository Manager Steering Committee Technical Team User Committee Work Package Work Package Leader Shipping Line Shipping Agent Voyage Plan Call Request Call Response Authorization Entities All transport related definitions are based on: Glossary for Transport Statistics (Second Edition 1997): Document prepared by the Intersecretariat Working Group on Transport Statistics formed by Eurostat, European Conference of Ministers of Transport (ECMT) and United Nations Economic Commission for Europe covering: Intermodal Transport Road Transport Railway Transport Water Transport Inland Waterways Transport IP Consortium IP Final Report v May 6 th,

5 TABLE OF CONTENTS 1 EXECUTIVE PUBLISHABLE SUMMARY PROJECT OVERVIEW PARTNERSHIP INFORMAT ION OBJECTIVES OF THE PROJECT SCIENTIFIC AND TECHNICAL DESCRIPTION OF THE RESULTS THE ROLE OF PORTS AS INFORMATION TRANSFER POINTS EUROPEAN SCENARIOS...17 INTERMODAL PORTAL, A EUROPEAN CONCEPT THE SINGLE DESK: SHIP ROTATION THE EUROPEAN SINGLE DESK VIRTUAL SHIP AGENT DANGEROUS GOODS DECLARATION TRANSPORT ORDER FOR TRUCKS PORT ORDER...31 PORT ORDER REAL TIME ETA INFORMATION BILL OF LADING SYSTEM SYSTEM ARCHITECURE: INTEGRATION OF IP NODES LIST OF DELIVERABLES COMPARISON OF INITIALLY PLANNED ACTIVITIES AND WORK ACTUALLY ACCOMPLISHED PRESENTATION OF THE PROJECT ORGANISATION WORK PROCESS MANAGEMENT AND CO-ORDINATION ASPECTS RESULTS AND CONCLUSIONS INTERMODAL PORTAL CONCEPT CONTRIBUTION OF THE IP PROJECT TO THE EUROPEAN TRANSPORT POLICY ANNEX 1: THE IP MESSAGES ANNEX 2: THE POINT OF VIEW OF THE USERS...77 IP Consortium IP Final Report v May 6 th,

6 List of Diagrams Two dimensional View of the Ports The Single Desk Business Cycle Relationship of the Single Desk with Port Authorities The Single Desk Context Diagram The Virtual Ship Agent Context Diagram The Virtual Ship Agent Business Cycle The Dangerous Goods Testbed Architecture The Dangerous Goods Business Cycle The Dangerous Goods Information Flow Transport Order for Trucks Business Cycle The Port Order Transport data in the Port order Real Time ETA Business Cycle The IP Technical Architecture IP Consortium IP Final Report v May 6 th,

7 1 EXECUTIVE PUBLISHABLE SUMMARY. 1.1 PROJECT OVERVIEW The improves the integration of ports into intermodal transport chains by harmonising administrative procedures and offering a set of information and communication (ICT) tools and services for easing the mandatory data supply as well as the data delivery to other partners in the chain while ensuring the reliability and security of all the data transmissions within the system. This has been done by integrating results of previously successful RTD projects and industrial strength solutions into a large-scale demonstration covering 14 of the major seaports all over Europe (from Finland to Greece). IP is a combined RTD/Demonstration project for the Task 2.3.2/2 Innovative Waterborne Transport Concepts of the 1 st Call for the 5 th Framework Programme, Thematic Programme Competitive and Sustainable Growth, Key Action Sustainable Mobility and Intermodality. To carry out this project, a group of key actors in the area of transport telematics joined efforts throughout Europe. They represent Port Community Service providers, Port Authorities and Transport Research Institutes. The IP Consortium consists of the following companies: EUROMAR EEIG (PORTEL, MGI, SeT), - Spain, France and Italy Innovation Strategies - Spain Institute of Shipping Economics and Logistics (ISL) Germany Transport Research Institute and Transportforschung GmbH (TFK) Sweden, Germany Marintek Norway EDI Management Finland Datenbank Bremische Häfen GmbH (DBH) Germany City of Bremen: Ministry for Ports, Transport and Foreign Trade (HVA) Infoport Valencia - Spain IP Consortium IP Final Report v May 6 th,

8 With IP, the original goal was to provide a sustainable IT environment offering the parties engaged and interested in waterborne transport a single point of entry to these modes. Main reasons for this goal are found in the circumstance that transport is (almost naturally) required as one of the major prerequisites for gaining wealth and economic prosperity. In contradiction, congested roads are speaking for themselves. Hence, movement of cargo under the From Road to Sea headline has been a major goal for European policy makers for years. However, Intra-European transport by water has not yet achieved the market share neither desirable nor possible. Missing information on possibilities and missing integration of information is identified as one of the key enablers for increased usage of waterborne transport. IP addresses this circumstance by developing a set of low cost and easy to use Internet based applications that all together will provide a far improved approach to IT reinforced Shortsea Shipping usage. In this sense, IP directly supports the implementation of the policy recommendations made by the EU and is a valid platform to further implement harmonization and rationalization directives and initiatives. One of the major issues within the lacking acceptance of waterborne transport in European waters is still a set of overall administrative process that are far more complicated than the ones applied for road transport. The project addressed this circumstance by investigating the procedures applied and by developing a set of standard applications for these purposes. The provision of a sustainable IT environment will enable harmonized and streamlined administrative affairs that have to be applied when vessels are calling ports in Europe. Within the scope of IP, a set of applications for the following key areas were developed, tested and piloted: - Waterborne Single Desk This application copes with the task of harmonized and simplified administrative treatment of vessels in ports. Based on the FAL forms provided by UN s IMO, digitizing this process is made possible. The initiative of the Single Desk was developed fully in line with the corresponding European Directive on implementation of FAL forms. - Intermodal Waterborne Node Managing intermodal transports is still considered as far too complicated for a serious breakthrough within European transport. Considering ports as natural important interfaces, the organization of intermodal transports can very well start here. The application demonstrates this possibility by sample business cases. The intermodal node focus is enriched by the portorder@online which provides the opportunity to book a port transaction via a web-based interface. Additional comfort is provided by the Real time ETA (Estimated Time of Arrival) application which enables an user to detect the ETA that will have to be applied. The onward or pre-carriage is supported with the use of internet-based IP Consortium IP Final Report v May 6 th,

9 Transport Order module, which can be integrated to any operative IT system of a road haulier via XML interfaces and the capability of interchanging information regarding the Bill of Lading in a simple manner. -HAZMAT Dangerous Goods Dangerous goods are a major reason for concern in European waters and ports. Their increasing share in containerized and conventional cargo transport requires more attention. At the same time, any administrational process has to remain lean and efficient. The application provides a possibility for simplified declaration of any dangerous cargo and for the transfer of this information Beside of the research goals, a thorough dissemination and exploitation work was performed in order to gain public attention for the project s aim and the needs that are addressed by the IP Intermodal Portal project. IP Consortium IP Final Report v May 6 th,

10 2 PARTNERSHIP INFORMATION Considering the objectives pursued by the IP project, we deemed it would be interesting to gather a consortium of entities, representative of the key actors in the transport area throughout Europe. This is the reason why the IP team was set up with the following partners: Coordinator: EUROMAR The coordinator partner has been Euromar EEIG, a European Economic Interest Group formed in 1996 with the aim of consolidating the benefits of Information Technology and telematic applications for the intermodal transport activity in the Mediterranean region. In this case 3 members of EUROMAR have directly participated in the project; Marseilles Gyptis International (MGI) (independent company created by the Port Community of Marseilles), PORTEL Servicios Telemáticos (company that promotes the implementation of advanced technologies in all Spanish commercial ports) AND Sistemi i Telematica (SET) (company based in Genoa that offers a broad range of experience from system integration, supply of operational systems and engineering services). The partnership is enriched by these other partners: - Innovation Strategies: Consultancy firm that helps its clients achieve business and technological development by applying Information Technology with a large experience in the transport sector. - Institute of Shipping Economics and Logistics (ISL): independent, private, non-profit making foundation located in Bremen - Transport Research Institute and Transportforschung GmbH (TFK): nonprofit, co-operative research organisation. - Marintek: versatile research company specialising in R&D in central areas of marine activities. - EDI Management: logistics and electronic commerce consulting company - Datenbank Bremische Häfen GmbH (DBH): joint venture by 108 companies belonging to Bremen s seaport transport industry. - City of Bremen: Ministry for Ports, Transport and Foreign Trade (HVA): responsible for the ports owned by the city of Bremen. - Infoport Valencia: company created by the community of operators of the Port of Valencia to serve as the main vehicle to improve the logistic information flows around the Port of Valencia. IP Consortium IP Final Report v May 6 th,

11 3 OBJECTIVES OF THE PROJECT European Commission DG-TREN The originally planned objectives for the IP project are explained in the following Master Table of Objectives Objectives Starting Point Testbed Anticipated Results Validated 1) To harmonize the presentation of declaration to Customs, Maritime and Port Authorities and the information flow regarding dangerous goods 2) To define an harmonized model to connect port communities with road and rail branches IMO FAL Forms Waterborne Single Desk pilot in the Marnet project BOPCOM Tools HAZMAT Directive Results of the COREM,WISDOM,ITESIC, INTRARTIP, 3SNET projects for integration with other transport modes Waterborne Single Desk HAZMAT Dangerous goods Intermodal Waterborne Node Deliverable 2: Waterborne Single Desk procedure and 4:HAZMAT Telematics Procedure Process model described using UML (unified modelling language) Data Model of messages and supported databases User interface/messages definition for all the agents that intervene in the procedures Deliverable 3: Intermodal Waterborne Node procedure: Process model described using UML (unified modelling language) Data Model of messages and supported databases User interface/messages definition for all the agents that intervene in the procedures Maritime/Customs/Port Authorities:. Major shipping lines Small shipping lines Port Community Systems HAZMAT national coordination centres. Rail / Road operators Port Community Systems Container Terminals / Stevedores 11

12 3) Develop Systems Software Applications and message definitions from the relevant projects Existing Port community Systems Waterborne Single Desk HAZMAT Dangerous goods Intermodal Waterborne Node Set of software applications EDI messages XML messages Definition of technical architecture IP Portal (Intranet) Compliance with the procedure defined EDI messages recommended by the International Maritime Organization (IMO) FAL Forms 4) Implement/test systems System demonstrator Waterborne Single Desk 5) Design the Implementation Strategy Results of the tests User Group feedback HAZMAT Dangerous goods Intermodal Waterborne Node Waterborne Single Desk HAZMAT Dangerous goods Intermodal Waterborne Node 6) Disseminate result All Waterborne Single Desk HAZMAT Dangerous goods Intermodal Waterborne Node Deliverable 10: Live Operation Evaluation report. Organization Legal responsibilities Contractual arrangements Marketing materials Presentations Web site Large Scale demonstration (14 ports) from Scandinavia to the Mediterranean Signed support by participants in the tests Cover the whole transport sector 12

13 The objectives were achieved as follows: Objective 1: To harmonize the presentation of declaration to Customs, Maritime and Port Authorities and the information flow regarding dangerous goods Based on the starting point reflected in the master table above, (IMO FAL Forms, Single Desk pilot of Marnet, BOPCOM tools and Hazmat directive), we have developed 2 services integrated in IP where the administrative procedures for supplying mandatory information when a ship is calling at a port are supported and carried out in an standard way: 1. Single Desk: that proposes an harmonised and common interface through which relevant documents can be submitted electronically to European port authorities. By using this service, these documents can be submitted using always the same format and entering the same information independently of the port on which the vessel is calling. 2. Dangerous Goods: that provides specific transport operators, i.e. ship- and line-agents, with a value added resource to more efficiently perform administrative procedures towards the local authorities with regard to dangerous goods declarations (according to the Hazmat directive) avoiding unnecessary re-keying of data at the different ports of call. The concept behind this two services has been validated by the user group. Additionally, the specific implementation we have made along the project of these services, has been tested and approved by relevant pilot users. Objective 2: To define an harmonized model to connect port communities with road and rail branches. Due to the complexity associated to manage information regarding intermodal transport, it is very difficult to define an harmonized way to connect road and rail branches with ports. For this reason, within IP, we have defined and developed a set of services that could become a first pilot and start up of an European Platform on knowledge, tools and services supporting interconnectivity for information exchange around ports as nodes in intermodal transports. These services are: Sailing Schedule Transport Order for Trucks Real Time ETA Port Order online Maritime booking and quotation Information on bill of lading 13

14 Additionally, as an important by-product of the project a set of standard XML messages covering the most important data interchanges occurring in the intermodal transport business has been defined (See Annex 1: The IP Messages). The consortium is pushing towards a generalization of these messages both, inside and outside the IP scope in order to facilitate information flow between parties and as a way to avoid re-inventing the wheel each time there is a need to standardize information interchanges (these results are public and available to anyone interested, they can be solicited by sending an to: K. Fjortoft (Marintek) at KayEndre.Fjortoft@marintek.sintef.no ). Objective 3 and 4: Develop and Test Systems. All the systems described above have been successfully developed and tested by the users during actual live demonstrations. Objective 5: Design the implementation strategy. According to the results and feedback obtained during the test phase and meetings held with the user group all along the project, the consortium delivered a business and exploitation plan for the further commercial usage of the results. In addition, in terms of contractual arrangements, the consortium also delivered a signed Consortium Agreement and Intellectual Property Rights and a set of Technological Implementation Plans to ensure that the transition to the commercial phase is properly backed up by all partners of the consortium. Objective 6: Disseminate Results. In order to disseminate the results obtained during the project, the consortium has produced a large set of presentation materials, including a web site, newsletters, PowerPoint presentations, press releases, etc. that have been published in different media throughout Europe. In addition, the IP project and its results has also been presented in several meetings with key actors of the industry, authorities conferences, (Thematic Networks i.e.),etc.. Please refer to section 6.2.2: Impact on Previous Projects in IP, for more details on how previous results have been incorporated into the IP project. 14

15 4 SCIENTIFIC AND TECHNICAL DESCRIPTION OF THE RESULTS. The aim of the is to improve the integration of ports into intermodal transport chains by harmonising administrational procedures and offering a set of information and communication tools and services for easing the mandatory data supply as well as the data delivery to other partners in the chain. The information required to support intermodal transport is in most cases available in the transfer points involving waterborne transport : the seaports. But procedures, formats, responsibilities, etc. are different throughout Europe influencing efficiency in a negative way. There is a need of a consistent, homogeneous and credible telematics offering across Europe. 4.1 THE ROLE OF PORTS AS INFORMATION TRANSFER POINTS The role of ports as information transfer points has been regarded under various points of view. One aspect takes care of the different roles of ports as nodes, that means A.1 ports in their interaction with other ports, ports as nodes in the sequence of calls of ship rotations dealing mainly with the planning and performance of voyages and calls of ships, the stowage, loading and unloading of cargo, monitoring of dangerous cargo on board and the control belonging to the HAZMAT directive on the one side, and A.2 port in its role as an individual port, as an intermodal node of combined transportation providing all services required from a node in intermodal transport chains, each of these chains under the control of one or various transport operators managing door to door transports, on the other side. Regarding these roles and for discussing the technical and organisational solutions for the information exchange in the following paragraphs a second aspect has to be considered concerning the difference between B.1 information which can be collected and distributed, preferably online, via a standardised regional or even European procedure called single desk on the one side, and 15

16 B.2 information which has been created in individual inhouse information systems and has to be delivered via EDI to individual inhouse information systems, operated by private enterprises (e.g. industry, trade, forwarders, shipping lines, agents, port operators, road and railway carriers) as well as by administration and authorities. There is a correlation between the roles of ports described under A.1 and A.2 and the different demand on information exchange mentioned under B.1 and B.2 (see figure below Two dimensional View of the Ports ). This is to say that both solutions (B1 and B2) are applicable on both scenarios (A1 and A2) depending on the specific information interchange that we are dealing with. More specifically: forwarder transshipment Intermodal Nodes (A.2) Valencia Bremen Helsinki rail carrier agent European Single Desks: Ship Rotation, Dangerous Goods, Virtual Ship Agent (A.1) Two dimensional View of the Ports Information exchange in the way described under B.1 (via a single desk) on a European level is supporting the role of ports pointed out under A.1 (concerning ship rotation with various port calls), and there especially regarding small and medium sized ports, shipping lines, agents, port operators and authorities which are not operating own EDP application systems. In addition, due to the variety of processes in various ports, regions and individual intermodal chains solutions for information exchange via single desks providing online access for information exchange are already in use or will be established locally and 16

17 individually e.g. for a port, for a region of ports or for alliances of transport industry along intermodal chains, supporting both roles of ports, A.1 and A.2. Information exchange in the way described under B.2 (with demand on interconnectivity via EDI) is needed for both roles of ports, A.1 and A EUROPEAN SCENARIOS. In addition to the complexity of supporting the intermodal transport, we have also taken into account the variety of scenarios located at Europe: In every region and, in most cases, in every port the administrative procedures are different. Therefore, harmonisation is urgently required. On the other hand, every scenario not only supports different procedures but they also are based on different architectures, systems or means to provide this mandatory data. In order to overcome this situation the Intermodal Portal approach has been based on building standard nodes that are adapted to the targeted scenario: filling the existing information gaps between local Port Community Systems, connectig to existing systems, and providing a common set of functionalities. This concept is explained in more detail in the following paragraph. 4.3 INTERMODAL PORTAL, A EUROPEAN CONCEPT The Intermodal Portal consists of an Internet Site and a decentralized virtual portal. The Internet site focuses on providing a set of simple and useful services to transport operators in Europe and beyond. The decentralized virtual portal focuses on information transfer between existing nodes with no or minimal changes to existing systems. In order to materialize the concept, the services of the portal relies on available Information Systems such as Port Community Systems. The nature of the offered services implies that the user of IP operate in various ports at the same time. So IP is a multi-port service; it does not have the intention of substituting Port Community Systems but to extend their functionality so more users regardless of their geographical situation can access them. There are two types of users: 1. Persons. 2. Information Systems. Persons utilize IP-based services to, (for instance): 17

18 Issue Call requests. Generate Dangerous Goods Declarations. Receive and accept call requests. Request for Voyage Offering, Quotation and finally deliver Maritime Bookings. Generate Transport Orders for trucks. Deliver Port Orders. Ask for Real Time ETA. Information Systems send and receive information to/from IP via messages. The resulting services for both types of users are: - Single Desk => Ship Rotation. - Dangerous Goods Declaration. - Voyage Offering, Quotation & Maritime Booking => Virtual Shipping Agent - Port order online. - Real Time ETA - Transport Order for Trucks. - Information on Bill of Lading - XML messages definitions The services offered by the standard IP nodes are explained in the following paragraphs: 4.4 THE SINGLE DESK: SHIP ROTATION Single Desk Purpose. The objective of the Single Desk is to simplify and harmonise the administrative procedures that should be carried out when a ship is calling at a port. Along time, every port has been defining and enforcing its procedures and regulations to control and to track the arrivals, the internal movements and departures of vessels. Because of this, port specific vessel entering and clearance procedures have to be followed in each port, reducing efficiency and increasing complexity of administrative operations. 18

19 The IP Single Desk services, on the contrary, propose a harmonised and common interface through which relevant documents can be submitted electronically to European port authorities. By using the portal, these documents could be submitted using always the same format and entering the same information independently of the port the vessel is calling. The Single Desk takes into account the current available trade facilitation standards. IMO FAL FORMS and recommended practices set the scope to IP Single Desk Services. The Convention on the Facilitation of Maritime Traffic (FAL Convention) was adopted by the International Conference on Facilitation of Maritime Travel and Transport on 9 April It entered into force on 5 March The purpose of this Convention is to facilitate maritime transport by simplifying and minimising the formalities, documentary requirements and procedures associated with the arrival, stay and departure of ships engaged in international voyages. The Convention emphasises the importance of facilitating maritime traffic and demonstrates why authorities and operators concerned with documents should adopt the standardised documentation system developed by IMO and recommended by its Assembly for world wide use. It is of special interest to point up Standards and Recommended practices for: Electronic data-processing techniques. - Public Authorities shall accept documents required for the clearance of ships, when produced by electronic data-processing or interchange techniques that conform with international standards (United Nations (UN) Recommendations and relevant ISO standards) to the maximum extent practicable. They also shall limit the information they require and shall encourage but no require the use of this techniques by maritime operators and other parts concerned. Arrival, stay and departure of the ship. - Provisions concerning the formalities required of ship owners by the public authorities on the arrival, stay and departure of the ship. Public authorities shall not require for their retention, on arrival or departure of ships to which the Convention applies, any documents other than: 1. Maritime Declaration of Health 2. Document required under the Universal Postal Convention for 19

20 mail. 3. FAL Forms (see section 5.1.2) Public authorities shall accept these declarations either signed by the master, the ship agent or some other person duly authorised by the master, or authenticated in a manner acceptable to the public authority concerned. Arrival, stay and departure of cargo and other articles. - Provisions concerning the formalities required by public authorities form the shipowner, his agent or the master of the ship Business Cycle. The Single Desk Communication Area consists of several agents that exchange some documents in order to cover a Voyage Business Cycle. First of all, the starter of the Business Cycle is the Shipping Line who prepares a voyage plan that includes several EU seaports, he must deliver mandatory documentation in every port of call. Because of most of the information included in the documentation should be constant data and/or data with few modifications, starting form a Voyage document filled by the Shipping Line, the mandatory Call Requests are created and delivered to each Shipping Agent that the Shipping Line s got in every port of call. The Single Desk Business Cycle 20

21 Then, the Shipping Agent of each port of call updates and completes the required information for that specific call and begins a dialogue with the Port Authority in order to achieve the authorization of the call. Relationship of the Single Desk with Port Authorities The context diagram of the IP Single Desk is as follows: 21

22 SHIPPING LINE / MARITIME AGENT VOYAGE PLAN CALL REQUEST RESPONSE STATUS OF THE VOYAGE CALL REQUEST RESPONSE RESPONSE CALL REQUEST PORT AUTHORITY A SHIPPING AGENT A RESPONSE PORT AUTHORITY C RESPONSE CALL REQUEST CALL REQUEST RESPONSE CALL REQUEST RESPONSE CALL REQUEST SHIPPING AGENT C SHIPPING AGENT B PORT AUTHORITY B The Single Desk Context Diagram 4.5 THE EUROPEAN SINGLE DESK VIRTUAL SHIP AGENT The Virtual Ship Agent (VSA) is a pilot of an internet-based portal, offering several value added services for the transport community: combined voyage plan enquiry quotation online booking The demonstrator has been piloted by a traditional ship agent, who already has great knowledge of intermodal transport procedures and even more important the business connection to various shipping lines. These shipping lines offer break bulk, ro-ro or container transport. 22

23 European Single Desk ship rotation European Single Desk dangerous goods voyage plan DG information shipping line voyage info booking voyage plan Virtual ShipAgent port order voyage plan enquiry/quotation booking forwarder Local IP Node Local Community System The Virtual Ship Agent Context Diagram In addition to offering this service to customers via the internet, the employees use the same technology for their internal work. For this, the inhouse software has been adapted and the internal workflow has been restructured. The great advantage is, that the relevant information is entered and stored only once and is available without delay to all the employees as well as the customers. Communication with external partners, such as shipping lines and local administration, but also with the single desks ship rotation and dangerous goods is based on EDI messages as described in B.2. Although the aim was to establish automated connections to all external systems, there remain some remote systems which have to be operated manually. The information have to be manually entered into the VSA system by the agent. The ultimate goal was to map all the activities of a ship agent which are mostly performed via telephone or fax into an internet application, thus providing an easy and uniform access to waterborne transport facilities. During the prototype stage, the activities covered for the ship agent has been: Voyage Plan, Enquiry, quotation and booking. 23

24 European Single Desk dang. goods European Single Desk ship rotation port-community system 1 port-community system 2 remote terminal shipping line system 1 DG notification voyage plan remote terminal shipping line system 2 shipping line system 3 accountant agent shipping line system 4 accounting software business logic voyage plan, rates, booking shipping line system 5 administration (i.e. customs) web server Virtual Ship Agent voyage plan, enquiry, quotation, booking shipper forwarder The Virtual Ship Agent Business Cycle Voyage Plan Module The service that was implemented first is the combined voyage plan. Even though most of the shipping lines run their vessels on tight schedules, it seems to be a big problem to get this information to the customer. Many shipping lines publish the voyage schedules by fax to their ship agents or just make them available on their remote terminals. All these different formats make it difficult to browse or search different voyage schedules to find optimal voyages. The virtual ship agents collect voyage schedules from several selected shipping lines and combine them into one which is stored in a central database. This is done automatically as far as possible. A customer is able to select port of loading, port of destination and time of travel and is presented with a number of voyages travelling between these ports. 24

25 The benefits of such a service are evident. For the customers, i.e. freight forwarders, it greatly simplifies the task of integrating the sea-going transport into his overall transport planning. For the ship agent it provides a uniform tool for gathering and retrieving voyage information Enquiry, Quotation, Booking Module As the second step, the portal offers the possibility of rate enquiry on all the voyages from the voyage schedule. This enquiry is processed by the system by looking up the rate information in the relevant tariff lists in the database. The initial enquiry leads to in a quotation that is sent to the enquiring customer. Based on this quotation the customer can generate bookings by entering the required data which is again handled by the virtual ship agent. As the last step the booking information is transferred to the individual shipping lines. 4.6 DANGEROUS GOODS DECLARATION Dangerous Goods Declaration Testbed Purpose. The objective of the Dangerous Goods Declaration Testbed consists in focusing on the specification of a potential harmonised dangerous goods procedure according to HAZMAT directive, as part of the single desk procedure. This task takes more particularly into account the results from European projects such as MarNet (Dangerous goods pilot) and Protect. Along time, every port has been defining and enforcing its procedures and regulations to control the declaration of Dangerous Goods. Because of this, port specific procedures for the declaration of Dangerous Goods have to be followed in each port, reducing efficiency and increasing complexity of administrative operations. Now users have to enter a lot of unnecessary data to prepare the DG declarations. The IP Dangerous Goods Service, as part of IP Single Desk, offers a common interface through which Dangerous Goods Declaration can be submitted electronically to European port authorities. The IP Dangerous Goods Service support also the harmonised and standardised information flows, since it will eventually need to exchange e.g. dangerous goods notifications with the non-ip port systems or with non-ip IT systems of shipping lines, through the certified IP Node. 25

26 4.6.2 Business Process Currently, the declaration of dangerous goods in carried out in ports using portspecific procedures; in addition it is a local process as is it is carried out by the local shipping agent and the designated authority by exchanging the dangerous good declaration and the dangerous goods authorisation. As part of this process, dangerous goods are declared in more ports, namely the port of loading, the ports of transit and the port of discharge. Accordingly, the information about a dangerous goods is reported in the declarations submitted in several ports, namely the declaration submitted in the port of loading, the declarations submitted in the ports of transit and the declaration submitted in the port of discharging. This overhead could be removed by adopting the IP DG testbed; indeed the DG testbed proposes, on one hand, an harmonised solution for submitting the dangerous goods declarations and, on the other, a solution for seamlessly exchanging information among the ports called by a given vessel, so that information about a given dangerous cargo could be entered in the dangerous good declaration submitted in the port of loading and then transferred and automatically included in the dangerous goods declarations submitted in the ports of transit and in the port of discharging. According to this approach, the dangerous goods declaration shouldn t be conceived as a local process that take place in each port, but as a global process that involves all the ports called by a vessel during a voyage. Involved in this global process are Shipping Lines, Shipping Agents, Port Authorities or Maritime Authorities. The global process of Dangerous Goods Declaration is showed in the next picture: it show a vessel which start from Port A, transit to Port B and arrive to Port C; users in Port A and B use IP Dangerous Goods Service, users in Port C don t use IP Dangerous Goods Service. 26

27 IP Node Port A use IP DG Service European Single Desk dangerous goods IntermodalPortal.com IP Node Port B use IP DG Service European Single Desk dangerous goods IP Node Port C don t use IP DG Service BERMAN BOOKING APERAK Shipping Agent IFTDGN XML IFTDGN draft Shipping Agent IFTDGN XML IFTDGN draft - BERMAN BOOKING APERAK APERAK APERAK XML MESSAGES Port Authority Port Authority XML MESSAGES INFOLOGISTICA PORTEL DBH SHIPREP SIC-VLC PROTISNET INFOLOGISTICA PORTEL PORT@NET DAKOSY SIC-VLC PROTISNET * Example of local community systems. The Dangerous Goods Testbed Architecture The process of Dangerous Goods Declaration is detailed in the following picture: 27

28 Ship Owner Shipping agent in Port A Shipping agent in Port C Shipping agent in Port B IFTDGN draft of IFTDGN IFTDGN draft of IFTDGN IFTDGN APERAK APERAK APERAK Authority of Port A Authority of Port B Authority of Port C The Dangerous Goods Business Cycle However, it happens that a number of European ports deploy local PCS systems that are used, among the other, to submit dangerous good declarations. For instance, this is the case of the port of Genoa, where the Infologistica platform is used, or of the Spanish ports, where the Portel solution is adopted. And it is not reasonable that the IP DG testbed could substitute these systems. In addition it seems reasonable that in the future a number of IP DG testbeds could be used in a number of European ports, for supporting the dangerous goods declaration processes that take place in that ports. For instance, during the IP demonstration, a connection was made to Portel that acts in Spain as the National Competent Authority for Dangerous Goods (under the Hazmat directive) allowing users to comply automatically with the directive without having to re-key the data. But the most common solution will be (such as in the case of Genoa) to connect to the local Port Community System that it is in turn connected to the corresponding National Competent Authority. 28

29 All these systems support the local process that take place in the port they are deployed and, as such, they, disjointedly support different pieces of the overall global process that involves the declaration of dangerous goods along a vessel voyage. In order to support the overall global process as a single IP DG testbed does, they should be integrated together so that information on dangerous goods are exchanged seamlessly among ports. Port A Norway Port C Finland Local port community system Certified IP node Dangerous goods notification Certified IP node Local port community system Agent A Acknowledgement Agent C Port B Spain Acknowledgement Dangerous goods notification European Single Desk dangerous goods Dangerous goods notification Agent B Centralised IP on the web Acknowledgement The Dangerous Goods Information Flow Therefore, the objective was to define and to develop the integration of IP DG testbeds with external PCS systems. This resulted in an integrated support for the global dangerous goods declaration process that avoids unnecessary activities related to the multiple declarations of cargo in different ports and, at the same time, allows existing PCS to be used by users in the same way they do today. 4.7 TRANSPORT ORDER FOR TRUCKS. The transport order for trucks is a service offered by the IP web application in order to facilitate the work of clients and especially SME companies as well as the work road hauliers. Many road hauliers offers nowadays extranet services to 29

30 their clientele, but seen from the client s point of view this leads into a situation where client needs to adapt daily to different type of applications, different screen layouts, different usernames and passwords as well as different work flows. Therefore the idea behind this demonstrator was to offer a generic solution for sending the transport order and the accompanying freight waybills in a unified way to the road hauliers. The road hauliers benefit from this type of solution by getting the information in a standardised form and content, namely as a XML file, directly into their system. The following picture illustrates the demonstrator as a whole IP Transport Order, Freight Waybill Freight Invoice Road haulage company Freight Invoice Transport Order, Freight Waybill Freight Waybill Client of the road haulier Transport Order for Trucks Business Cycle The process is the following the client can enter the transport order information on the IP website from which it will be passed on the road haulier as an XML file at the road haulier s system the transport order will be read into their IT system and the operations manager will allocate the truck(s) for the client once the trucker is about to fetch the goods, the client can update the transport order already entered and form freight waybills of the data the client will then print the freight waybill to the trucker, since it is a legal requirement to have it on paper 30

31 he/she will also accept the waybills on the IP website, and they will be passed onto the road haulier s IT system again as XML files the road haulier receives the information and uses it as the basis for the freight invoices once the freight invoices have been generated in the road haulier system they will be sent to the client for example as attachments or even better theyt could be payed on the Internet depending on the client The benefit for the SME company to use the internet is that by standardising the contents of these information flows and supplying the SME with code lists and logos of the different road hauliers, he can then do business with the road hauliers in one standardised way instead of logging into different type of extranets offered by the road hauliers. 4.8 PORT ORDER. 4.9 PORT ORDER. General Description By using this platform via Single Desk as an online Application or via Message- Transfer using XML or EDIFACT Format each participants of a Port is securely on the way feeding and providing all necessary data to all companies and administration authorities who take part within the IMPORT- as well as EXPORT-Procedures in the chosen harbour. This Internet-oriented System for all involved companies within a port or between different ports offers the opportunity to inform all parties who have to receive special information concerning port handling procedures. A port node has to connect all participants of the transport chain according all communication paths looking on the involved ports of supported areas. This means to join the shippers, forwarders, shipping lines, stevedores, truckers, terminal operators, port authorities, Customs and customers. The system does not substitute a transport manager but its most important feature has been the support of automatic interconnectivity among all participants within connected ports. The main idea of Port Order is to transfer information online via a simple Internet solution. A customer/forwarder is able to use the Internet without 31

32 investing a browser is available everywhere- to send his specific data online to members of the transport chain all over Europe using IP-Nodes An Internet based order procedure integrates the customs and the port authorities for the hazardous goods. All participants need only an internet-browser to take part of the port communication. Information can be collected and distributed online via a standardised procedure as a single desk. The communication management is served by Servlets placed on a Webserver. They work with Enterprise Java Beans and are supported by an Application Server. The Servlets are responsible for Vessel Information and ship rotation, Dangerous Goods Declaration (HAZMAT), Master Data (Commodities, ISO- Codes for Containers,..) and Port-Order data for Customs Clearence. The System is portable to each and every port or a group of ports. It is indifferent where the participant has his office, he can achieve every port electronically from every site using IP-Nodes The user of Port Order has to load a Java Applet via online access. He doesn t need interfaces or software adaptations and developments. The usage of Java- Applets instead of a poor HTML-solution will save the opportunity a clear, considerable and static environment on the surface. Port Order takes care of the routing of all special kind of messages in EDIFACT Format (IFTDGN, IFTMIN, CUSCAR, COREOR, APERAK, etc.) to all members of the transport chain. Data Exchange via XML-Message-Format is in preparation for mid of The ORACLE Database System is designed to store the above defined various data. Cargo and HAZMAT information is stored as well as vessel and Container information. Those data will be used in the messages transfered via IP nodes to the connected partners. Order Contains the general data for the order, such as revisor (clerk), name and phone number of the revisor (can be clicked for profile data, which, once created, can always be reused). In addition, the internal company section and position number must also be specified. In the Comments field, notes can be made on the order. 32

33 The Port Order Transport The transport data comprise vessel- and port-information. These data are determined through the vessel data. The search for the vessel is carried out via the port of shipping and the port of destination. 33

34 Transport data in the Port order 34

35 Positions / Containers Here the page is subdivided. In the upper part, information on the container and goods is expected, whilst in the lower part the data on the customs declaration must be entered. Container Data in the Port Order 35

36 4.10 REAL TIME ETA. The Real Time ETA module is designed for passing on the ETA information of the inbound vessels for public use. The VTS stations record the vessel s positions once the vessel reached the VTS station area, normally most vessel traffic systems are capable of calculating the ETA of a vessel to the next port of call. This information is highly valuable to many different type of users such as the Customs offices, Port Authorities and import/export companies not to forget the onward carriers like road hauliers. Nevertheless, this ETA information is not normally obtainable by these interest groups, since they are not allowed to acces the actual VTS systems. The goal of the IP module is to pass on the ETA information to the appropriate port community system, which in the demonstrations was the Finnish national administrative port community called Port@Net. IP 4) national vessel time schedules(xml) 1) basic data of the vessels (XML) 2) voyage information (XML) 3) ETAs of the vessels (XML) Port@Net VTS station Real Time ETA Business Cycle The Real Time ETA module works in the following way: 36

37 The system sends the basic data of the vessels to the VTS system, the information includes eg. vessel names, call signs, length, beam etc. This is to facilitate the work at the VTS station by speeding up the process of identifying the approaching vessel. The same applies when sending voyage information to the VTS station. The voyage information is sent to the system by the shipping line agent informing of the vessel, the port it will call, the ETA given by the agent and so on. When the vessel is within the VTS area and reports to the VTS station, then the personnel at the station can easily identify the vessel and combine the information with the voyage data received in advance. After the identification of the vessel, the VTS system automatically calculates the ETA for the vessel and sends it back to the system.. With regular intervals, the system automatically retrieves vessel time schedules with the updated ETA data and transmit this information to the IP Vessel Time Schedule module. Different users such as the Customs or road haulier can browse the national time schedules on the IP website of the Vessel Time Schedule module. In the future one option to supply the users with the vessel time schedule could be the use of WAP phones or SMS messages directed to GSM phones INFORMATION BILL OF LADING SYSTEM The objective of IP project is to simplify the administrative procedures relative to call ship management and goods managements. Regarding that ambitious objective, one problematic that maritime professional are facing is the transmission of information on the goods from one port to another. On this part, the application «Information Bill of Lading» aims to demonstrate that using an Internet application allows to the professional a means to answer to that problematic. That IP application has for main objective to build a tool to forwarders and maritime agents allowing the transfer of the information keyed on a Bill of Lading. (only the information, the objective is NOT to substitute BL by computer way but to allow an improvement of the setting up of BL by parties) Currently, the Bill of Lading is created by the export forwarder and stamped by the maritime agent in the port of loading. The document is presented at import with Customs clearance. 37

38 The Info BL application leans on the logistics chain of the goods translated into Information System. This application brings several advantages : - Conformity control of the document linked to the goods, - Same formal presentation for the BL between forwarder and agent, - Smoothness of the information exchanged, - Time benefit in the administrative process, with the automation of manual tasks (stamping for example, no need for the forwarder to have someone going to the agent to bring the BL). - Easy implementation into European Ports interested by the service. Remark : That application is easily interconnectable with private system or Port Cargo Community system : automatic transfer of the goods information in order to prepare the Cargo manifest for example. The application objective is to build an on line service (through Internet) and having the following functionalities: - On line key entry of the Bill Of Lading by the forwarder, - Automatic transfer to the parties written on BL, - Stamping and agreement on the information by the port agent, - Saving of the BL in the Data Base, - Automatic mailing when the BL is confirmed by all parties How information BL fits IP scope? The major scope of IP project was to bring solutions in improving administrative procedures regarding port procedures (ships and goods). Information BL demonstrator fits this scope providing a tool to European professionals involved in the building up of BL. By the way this demonstrator allows to share information on BL, by one keyentry in one formal framework and thus to see time savings in the setting up of BL (no redundancy of key entry of BL by parties, the information are keyed once at the root and transferred from one to another). Moreover, the information on BL can be exchanged to a Port Cargo Community System. The building up of the demonstrator is done permitting every European professional interested to be a user of the system. One other problematic IP tries to answer is the coordination of numerous partners of different professions, cultures and sizes. 38

39 This wish of coordination and harmonization is translated in practice by the necessity to harmonize complex procedures and by the need of communication between heterogeneous Information Systems. Thus IP Info BL demonstrator brings an answer providing an IC tool to forwarders and agent (no matter they are computerized or not), helping them to share necessary information for the constitution of their BL SYSTEM ARCHITECURE: INTEGRATION OF IP NODES. In a conceptual level, the integration of IP has been made according to the following picture: IP Node A IntermodalPortal.com IP Node B BERMAN BOOKING APERAK XML MESSAGES - Ship Rotation - Dangerous Goods - Maritime Booking. - Voyage Offering - Quotations. - Transport Order Trucks - Real Time ETA. - Port Order XML - Ship Rotation - Dangerous Goods - Maritime Booking. - Voyage Offering - Quotations. - Transport Order Trucks - Real Time ETA. - Port Order BERMAN BOOKING APERAK XML MESSAGES INFOLOGISTICA PORTEL DBH SHIPREP SIC-VLC PROTISNET PORT@NET DAKOSY EUROTRANSPORTNET * Example of local community systems. The IP Technical Architecture 39

40 For test purposes, a single IP node has been set up. The node was developed based on 4 premises: 1. The IP concept is focused on filling the existing information gaps between local Port community systems. 2. An IP node provides an standard web interface in terms of functionality and look and feel. 3. The IP node is capable of interchange information by standard XML messages defined by the Consortium with any other IP node (to facilitate different implementation schemas). 4. Connections to specific external systems were made when it was required. By using this approach, it was easy to prove the feasibility of setting up different nodes capable of communicating themselves. Therefore, we will be able to set up different nodes in different regions/areas providing the same services in different languages and connecting to specific systems already located in these regions. As it has been pointed before, the communication between the nodes are made through standard XML messages defined by the Consortium. These XML messages have been defined from their corresponding EDIFACT message. They are: APERAK CUSREP IFTDGN CUSCAR VESDEP BERMAN VOYAGE PLAN MESSAGE MARITIME BOOKING MESSAGE QUOTATION MESSAGE (For more information on the role of XML messages in IP, please refer to Annex 1) 40

41 5 LIST OF DELIVERABLES. OVERVIEW OF DELIVERABLES Deliverable Reference Version Access Level D1 Overall Intermodal Portal Scenario and Test Cases D2 Waterborne Single Desk Procedure D3 Waterborne Intermodal Node Procedure Date of delivery D1 Final Restricted June 2000 D2 Final Restricted June 2000 D3 Final Restricted June 2000 D4 Dangerous Goods Procedure D4 Final Restricted June 2000 D6 Waterborne Single Desk initial System D7 Waterborne Intermodal Node initial System D8 HAZMAT Dangerous Goods initial System D9: Integrated IP Demonstrator System D10 Live Operation Evaluation Report D11 Feasibility study on barriers for adoption D6 Final Restricted February 2001 D7 Final Restricted February 2001 D8 Final Restricted February 2001 D9 Final Public April 2001 D10 Final Public February 2002 D11 Final Restricted February 2002 D12/D13 Exploitation and Dissemination Plan D12/D13 Final Restricted February 2002 D14 Intermodal Portal web site D14 Final Public February 2002 D15 Presentation Materials D15 Final Public February 2002 D16 Project Control File D16 PPR4 Restricted February 2002 D17 Final Report for Publication D17 Final Public February 2002 * D5 is not present due to an error numbering the deliverables during contract preparation 41

42 6 COMPARISON OF INITIALLY PLANNED ACTIVITIES AND WORK ACTUALLY ACCOMPLISHED 6.1 PRESENTATION OF THE PROJECT ORGANISATION EUROMAR has operated as the Co-ordinator and has been responsible for project management. The three founder members of EUROMAR (Sistemi e Telematica, MGI, Portel) have a wide body of experience in the field of Information Systems applied to telecommunications and maritime transport systems. The organisation for the IP project was: Steering Committee Project Management Workpackage Leaders Technical Team Awareness Team The project has been managed by the Project Management under the supervision of the Steering Committee. The Steering Committee: Formed by a member of each consortium partner. It had the responsibility of taking the major decisions on the project according to the mechanisms established in the contract. Project Management was formed by: The Project Manager : Mr. Francesc Sánchez, General Manager of Euromar. The Technical Project Manager: Mr. Miguel Fernández, General Manager of Innovation Strategies The project management is responsible for the successfull delivery of the project's results. The Workpackage Leaders: 42

43 Each Work Package was led by a senior professional, the Work Package Leader. There were frequent contacts between the Project Management, the Technical Team and the WPL (Workpackage leader) on management issues. Responsibles for each Workpackage were: Workpackage WP1: Refinement of the Intermodal Portal Concept WP2: Specification/Harmonization of procedures WP3: Internal Integration of technologies WP4: External Integration WP5: Demonstration and Refinement WP6: Define deployment approach and legal support WP7: Exploitation and dissemination WP8: Project Management WP9: User Group Management Company Leader Euromar-Portel ISL IS EDI INFOPORT TFK Euromar-Gyptis Euromar-APV ISL A workpackage leader was responsible of: The delivery of a detailed workplan for the workpackage. The Coordination of the preparation of the Deliverables for the Workpackage To provide Inputs for the quarterly reports. The Technical Team Due to the technical and organizational complexity of the project, it was very advisable to create a reduced, working technical forum to achieve agreements and co-ordinate the position of the different partners along the project. Its role was specially relevant during workpackages 1 to 3 were technical agreement, cooperation and deep understanding of each other's needs are a most. The technical team was responsible of: Drafting the technical strategy of the project and elevate it to the Steering Committee for approval. 43

44 Finding consensus on procedures, tools and technical deployment issues. Present the background information that is brought by each partner to the rest of the consortium. Refine and technically approve deliverables that were going to be presented to the steering committee. Organize technical meetings and serve as the contact of the WP leaders to the whole consortium. Perform Quality Control Guarantee the homogeneity of the results. Agree on WP plans prepared by the different WP leaders. Ensure that cooperation was thoroughly achieved. The technical team members represented their geographical scenario and were responsible for their local users (thus providing information to WP9). The technical team was formed by: The Project Manager, that lead the Technical Team. 1 Person representing Euromar (3 companies) 1 Person representing Infoport and IS 1 Person representing TFK and Marintek 1 Person representing ISL/DBH and HVA 1 Person representing EDI The leader of the current technical workpackage (if different from a permanent member of the TT) The technical team was in constant communication regarding project issues, and had a formal working session (2 to 4 days) every 4 months to track the evolution of the project and achieve agreements for the following working period. The Awareness Team was responsible for the dissemination of the project outcomes and the liaisons with the supporting parties. It organised promotional activities, such as workshops, prepared awareness material, brochures, presentations, etc. for the. 6.2 WORK PROCESS The achieved work details and the results are presented in various documents concerning the project and in particular for each work package which comprises 44

45 a project plan, working papers, synthesis reports (please refer to Chapter 5 which presents the list of deliverables). The work consisted on 9 work packages: 1. Refinement of the IP Concept 2. Specification and Harmonization of IP Procedures 3. Integration of Technologies 4. External Integration and Set-up 5. Demonstration and Refinement 6. Define Deployment Approaching and Legal Requirements 7. Exploitation and Dissemination 8. Project Management 9. User Group Management That could be summarized as follows: 1. Finalize the definition and scope of the selected testbeds and specify the streamlined procedures for each testbed. During this work package the efforts were concentrated on modelling the scenario that will bring the IP concept into the waterborne intermodal transport chain. The group came to terms with the following compromise: decentralized virtual portals. The portals will be decentralized to allow regions to have a certain degree of autonomy over the system, the data and the language, yet they handle the work in a centralized fashion (i.e. communicate message across IP nodes, share data when necessary, avoid the need for building one-to-one interfaces, etc.). 2. Define each one of the testbeds that were going to be developed in order to demonstrate the feasibility of the IP concept. During this work package the consortium took key decisions regarding methodology and standardization. 3. Design and develop the new software applications that will make the virtual single entry point accessible to all users, following the procedures defined for each one of the testbeds. 4. Prove the feasibility of the Intermodal Portal solution, by integrating external systems (Port Community Systems, operators, national systems..). 5. Test the new operation and information systems in a real situation in order to obtain meaningful conclusions. 45

46 6. Define implementation policies and the legal framework required to launch the Intermodal Portal for commercial exploitation 7. Transfer and disseminate the results Project Bar and Pert Chart 46

47 Id Task Name 1 The año 1 año 2 T1 T2 T3 T4 T5 T6 T7 T8 T9 2 WP1:Refinement of the IP concept 3 T1.1:Model the Overall Scenario 4 T1.2:Refine Scope 5 T1.3:Select Available Buiding Blocks 6 WP2: Specification/Harmonization of Procedures 7 T2.1:Specify Waterborne Single Desk Procedure 8 T2.2:Specify Waterborne Intermodal Node Procedure 9 T2.3:Specify Hazmat Dangerous Goods procedure 10 WP3: Integration of Technologies 11 T3.1:Integrate/build Demonstrator for Waterborne Sin 12 T3.2:Integrate/build Demonstrator for Waterborne Inte 13 T3.3:Integrate/build Demonstrator for Hazmat Dange 14 WP4: External Integration 15 T4.1 with VTS Systems 16 T4.2: With ongoing projects 17 T4.3: Deployment of Demonstrator 18 T 4.4: Training 19 WP5:Demonstration and Refinement 20 T5.1:Live operation 21 T5.2:Refine demonstrators a/feedback 22 WP6:Define deployment approach and legal support 23 T6.1:Organizational Issues 24 T6.2: Contractual and confidentiality framework 25 T6.3: Technical architecture to support full scale depl 26 Workpackage 7: Exploitation and Dissemination 27 T 7.1: Prepare and Update Dissemination Plan 28 T 7.2: Prepare and Update Exploitation Plan 29 T7.3: Prepare and Update IP Web Site 30 T 7.4: Presentations at Transport fairs and Media Rel 31 Workpackage 8: Project Management 32 T8.1: Control the Project and Quality Assurance 33 T8.2: Assess Change 34 T8.3: Report Progress 35 Workpackage 9: User Group Management 36 T9.1: Finalise list of Participants 37 T9.2: Inform and get feedback from users 38 T9.3:Obtain acceptance from users 39 T9.4: co-ordinate with thematic networks 47

48 6.2.2 Work Package 1. Refinement of the Intermodal Portal Concept. During this work package, work was concentrated in finalizing the definition and scope of the selected testbeds and specifying the streamlined procedures for each testbed. The single most difficult task that we faced during the period was coming to an agreement on the technical vision and design that satisfied the requirements of each testbed function and the systems with which IP will interface. The group came to terms with the following compromise: decentralized virtual portals. The portals will be decentralized to allow regions to have a certain degree of autonomy over the system, the data and the language, yet they handle the work in a centralized fashion (i.e. communicate message across IP nodes, share data when necessary, avoid the need for building one-to-one interfaces, etc.). As described in chapter 4.11, each region operating IP will have its own IP node that will be seamlessly connected to the other IP nodes, this architecture will allow any user to work in its own language and at the same time communicate to any port in Europe. It also allows for a more flexible business model where there could be many IP node operators providing customer service to concrete regions throughout Europe. Once the consortium reached an agreement on the IP concept, we defined the test cases that were going to built and test during the project. In addition, we determined the methodologies to be used, we defined the standard test cases to be built during the project and we analyzed existing systems and ongoing projects for their relevance to our initiative. (See the following table) 48

49 Projects technical functionalities data content Functionalities BopCom Prosit Corem VATT MARNET 3SNET INTRARTIP VTS Vessel Traffic Systems ? ? - -????? - 70 Vessel Tracking & Tracing -?? - -?? - - -???????????? Container Tracking & Tracing - - -??? - -? -?????????? Standardized EDI, e.g. EDIFACT, UML????? - -? -????????? - -?? 125 Improvement of data flow along transport chain????????????????????? - -? 175 Data accessibility on need-to-know basis????????? -????????? -??? 145 Unintrusive resource ??? -????? Data security -?????? - -????? - -?? 100 Schedule of vessels, e.g. sailing list, route? - - -???? - -??????? - -? 110 Applications, e.g. inquiry & quotation, booking???????? -????? -???????? -?? 180 Statistical evaluation of content ? ?????? -?? 70 General information system, e.g. map, sea chart, weather chart, tide information -? ? - -????? - 60 Port information system, e.g. utilization, peaks, pre-notification? -? ??????? Dangerous cargo handling ITESIC EURO- BORDER INTERPORT TRIM INFOLOG SITS SHIPREP/ PORTWIN? - - -?? ?????????? -? 105 NOMIT DISC II PORT@NET Sum 49

50 Dangerous cargo pre-notification? - - -?? - - -??????????? Freight market -?? ? - -??? -? Voyage Definition ?? -?? - -??????? -?? 110 Call Request ?? ?? -??? -?? 80 DG Declaration ?? ?????? -??? -?? 100 Other Administrative communication with authorities? - - -?? ???? -???? -? 90 Sum Legend: - 0 pts? 5 pts.? 10 pts.?? 15 pts. The relationship matrix lists some essential IP functionalities versus previous projects. The IP functionalities are roughly split into two parts: technical functionalities and functionalities that have to do with data contents (i.e. booking information). Two lines summing up horizontally and vertically deliver different results: The horizontal sum row adds the points for each project and is a measure for the affinity between the named project and IP. The vertical sum column shows how much emphasis has been put on the different IP functionalities in the former projects. From this column different things can be seen: which functionalities have been tackled at all and which haven t been which project provides the most promising results for IP which issues seem to be key issues to be used in all projects The highest score is achieved by the applications column: users most often need applications to add to their existing systems, e.g. to control the new data coming in (visualise geographical positions for T&T). Also, every 50

51 project has to do with electronic data exchange and the improvement of data flow along the transport chain. These are probably key issues, that also have to be tackled in IP. Others are of similar importance, i.e. data security, but did not have too much importance in past projects. But also points with no reference to past projects may become important in IP: The statistical evaluation of i.e. data transfers may become important in IP as well as Dangerous Cargo handling, etc. 51

52 6.2.3 Work Package 2. Specification/Harmonization of procedures. Some key decisions regarding methodology and standardization were made during the execution of work package 2 that impacted all of the testbed functions. These decisions were as follows: UML to be employed for the specification of software from the user s perspective (use cases, lifecycle description, etc). Message definition standards were defined. User interface standards were defined. Entity Rela t ionship (ER) Modeling will be used for designing relational databases Work Package 3. Integration of technologies The work performed during this Work Package was considerably tougher than expected due to the complexity of the corresponding demonstrators that had to be developed. The demonstrators systems were made of: Newly developed software components. Existing components from previous projects integrated with the newly developed software components (initially in laboratory conditions) Definition of the XML interchanges. Additionally, these demonstrators were integrated into a Single Virtual Entry Point. This virtual entry point, also called, IP node, offers the following functionalities: Ship Rotation -> Single Desk Call Request (see Chapter 4.4) Dangerous Goods Declaration (see chapter 4.6). Maritime Bookings (see chapter 4.5). Voyage Offering (see chapter 4.5). Quotations (see chapter 4.5). Transport Order for Trucks (see chapter 4.7). Real time ETA (see chapter 4.10). Port Order Online (see chapter 4.8) Information Bill of Lading (see chapter 4.11) 52

53 We also prepared a complete definition of the standard messages that were going to be interchanged between IP nodes, external systems, (i.e. PCS), and in-house systems. They are XML messages that have been generated from their corresponding EDIFACT message: APERAK CUSREP IFTDGN CUSCAR VESDEP BERMAN VOYAGE PLAN MESSAGE MARITIME BOOKING MESSAGE QUOTATION MESSAGE This is an important byproduct of the project, because in fact it constitutes a de facto standardization proposal for the most relevant information interchanges affecting the transport industry today. As such, the messaging proposal is being presented at various European bodies and relevant companies in order to foster its adoption in, and outside, the IP schema Work Package 4. External Integration. During WP2 we made an effort to standardize as much as possible the different procedures and information flows that were covered by IP. Obviously, this was not feasible for all interchanges at the whole European Dimension and that we have to connect the demonstrator system to the real world in order to make it usable by real users. WP4 aimed, then at filling the gaps (both in terms of procedures and information flows) between IP and existing systems so the whole concept could be demonstrated in a real life environment and could show its real value and inefficiencies. A summary of the external systems that have been integrated with an IP node during this work package are: 53

54 Testbed External System Explanation Intermodal Node The VTS system of the Turku VTS station Port of Valencia VTS system RoadNet s traffic operating system Port of Valencia Community System SIC DAKOSY Hamburg PCS It is the Finnish national port community system for administrative purposes. This system connects all the major shipping lines, agents, the port authorities, maritime administration and Customs under one single national IT system. this system has been integrated with Port@Net system, from which the national vessel schedules are retrieved to published on the Finnish IP website Real time ETA functionality and integration has been integrated with Port of Valencia VTS system. Information about real time ETA is sent by Port Authority. IP node and the RoadNet s traffic operating system, RoadNet system receives transport orders and freight waybills entered on the IP website and sent electronically using XML Port of Valencia Community System SIC, which is managed by Infoport Valencia integrates the transport order for trucks service. The integration is based on XML files Interface to DAKOSY in Hamburg using DAKOSY-specific messages for the Port Order Online integration Dangerous Goods INFOLOGISTICA The integration has been performed by exchange of XML messages, the same standard messages that are interchanged between IP nodes, external systems, and in-house systems. 54

55 Port of Valencia Dangerous Goods System Portel s DG National System Single Desk Portel s DUE System for Integrated Spanish Berth & Anchorage Request System The integration between the IP node and Port@Net has enabled the local users to send and receive dangerous goods notifications from/to different other European ports This is and EDI system, which connects Maritime Agents, Port, Maritime and other Authorities in order to have an integrated management Dangerous Goods Traffics Through the Port Portel is the National Authority to collect the information about Dangerous Goods Notifications in Spanish ports This is a test version system to unify the procedure for the Maritime Authorities in all Spanish Ports Work Package 5. Demonstration and Refinement Due to the characteristics of the IP project, (wide range of users and wide range of services), and with the objective of testing as many services as possible by as many users as possible, the consortium defined two testing levels: 1. Test Level: This is the full test level. The users testing the services are real users in a real environment 2. Demo Level: This is not a full level test. In the DEMO Level the test has been done in a workshop directed by a member of the Consortium In order to have realistic and controlled scenarios the consortium defined 3 different testing scenarios, where several services have been tested or piloted by users. These testing scenarios and the services tested within them are. Scenario Location Services Nordic Scenario This Scenario covers the Real Time ETA countries in the Baltic Trasnport Order for and Scandinavian Trucks Region: Sweden, HAZMAT Dangerous Norway and Finland. Goods Ports that have 55

56 German Scenario Mediterranean Scenario participated in this test phase are: Gothemburg Stockholm Turku This Scenario covers Germany, with the ports of Hamburg, Bremen and Bremerhaven This Scenario covers the countries in the Western Mediterranean Region: Italy, France, Spain and Portugal. The main ports included in the test are: Italy: Genoa and Livorno. France: Marseilles. Spain: Barcelona, Valencia, Bilbao and Algeciras. Portugal: Lisbon. Maritime Quotation and Booking Sailing Schedule Port Order Online Transport Order for Trucks (demo) Single Desk HAZMAT Dangerous Goods BL Information Sailing Schedule (demo) Real Time ETA (demo) The conclusions we obtained from the feedback reported by the users: Intermodal Portal appeared to the Users a very positive system. Its positive aspects are: Very adequate Functionality, covering the User Needs. It has a very high Usability. It is a Reliable System with a low rate of malfunctions and secure access. It is a Very Efficient System. It has a short learning time, it is very easy to use and it is simple and clear. 56

57 All these aspects remark not only the work of the Intermodal Portal Consortium but the close work with the User Group. Nevertheless there are always some things to be improved. Some things the Users detected to be improved to put the Intermodal Portal System into exploitation are: More Flexibility is needed to extend the services and to be more easily adaptable to local laws. Some additional modules should be designed to integrate Intermodal Portal with some third party systems, which are not ready to integrate XML messages. Security access should be improved with a higher level of security (VPN, PKI, & SSL) Data should be more protected to system or application failures Work Package 6. Define Deployment approach and legal support The objective of this work package was to define implementation policies and the legal framework required to launch the Intermodal Portal for commercial exploitation. For this purpose, several activities have been carried out by the consortium: Business Plan: The consortium has prepared a business plan for the commercial exploitation of the intermodal portal. This business plan was mainly focused on the fields where the IP solution could be applicated and includes a market analysis, (study on what is the market, how big is the market and what is the economical perspective for IP services), and an economical appraisal Technological Implementation Plan: where mainly, all the partners describe their intentions to exploit the results obtained during the project. Deliverable 11 Feasibility Study on barriers for adoption: that describes the influence and ways of implementation of the IP concept on a high level. It also looks at the barriers that may stand in the way of a comprehensive implementation of IP concepts and products. As a result of this work, we are envisaging the following business scenario: 57

58 IP economic appraisal The core question question raised here is most probably to be: What are the savings, the utilisation of such a virtual portal could provide to the customer? To answer this question; one has to investigate the current behaviour in the transport business that is affected by IP and compare this against the services IP is offering. As IP is a new concept, the second part of the approach is hard to perform. Therefore, another approach was chosen. Potential clients in Europe Based on an investigation covering most of European transport business, ports, relevant companies and organisations were identified that are potential clients for IP services. They are: IP Target group or sectors Prospect Number in Europe Port Authorities and Harbour Masters Offices approx. 500, hereof 70 with obvious IP significance Shipping Lines / Owners approx Shipping Agents approx Freight Forwarders approx Road Transport Firms approx Rail Transport Firms approx. 460 Stevedoring Companies approx. 500 This overview indicates a total market of approx companies being potential candidates for an IP application in their premises. Deducting the road hauliers, a number of approx core ventures is left as potential market for IP applications. 58

59 These core companies, of which one can assume a tight connection to the maritime sector handle some 1,4 bill. tons of cargo, 25 Mill. TEU and some (inbound/ outbound) vessel movements annually. The question whether there is a market for IP services or not can not be answered precisely. Figures identified in the analysis suggest that a market is existing and as such a huge potential for facilitating the trade is there. What might the market be like then in figures? According to the UNCTAD, some 3-5% of trade volume (in currency equivalents) is spend on documentation and administration. IP could significant facilitate this process. The total volume of cargo transport in the EU is 320 bill. EUR. acc. to the EC, a 3% share hereof gets approx. 900 Mill. EUR for the purpose of documentation and administration. Potential Savings Taking core IP services and estimate savings here was attempted by another approach: According to UN investigations, most of border-crossing transport (be it unitised or not) requires the involvement of some 20 parties, that are issuing some 40 original documents. Out of these, some 360 (!) copies have to be produced that are distributed and filed in various places and with various organisations. Some 200 separated data items have to be recorded, whereof approx. 30 are re-used in all documents. This fact was the starting point for our further investigation where we visited several companies (forwarder, agent, broker, trucking and barge operator; locals only) and found out that the preparation of one bill of lading requires some 30 minutes in average. Preparing one dangerous cargo notification requires 15 minutes in average, preparing a call request take some 10 minutes in average. The B/L is being reused approx. 10 times, every time some 15 minutes are used finding the information, keying it in etc. etc. Same ratio applies for the dangerous cargo notification and the other documents. Summarising the entire investigation, one could state that some 75% cost saving (speaking information processing) can be obtained. This is however, 59

60 only relating to the cost aspects. Additional costs caused by failures etc. are not considered at all. Coming with some figures is again hard to perform as a precise statement would require an in-depth analysis. However, a rough calculation should look like this: Time required for complete documentation of transport in average 45 minutes (estimated acc. to on-site visits, provided documentation is done entirely on site) Time required for transmitting and re-processing documentation (estimated acc. to on-site visits, agents & forwarders) Time required in total per transaction Potential savings by using entirely electronic documentation and assistance (like the virtual portal) approx. or 1.5hrs Cost per working hour in Germany Potential savings against total costs of manual processing, approx. 90 minutes 135 minutes 100 minutes approx. 60,- EUR 90,- EUR 135,- EUR In other words, the potential savings are enormous. However, the problem is that is quite hard to access them as they are not easy to be exploited due to the well known reasons. Number of clients / how to calculate the costs Answering this question was a tough item to cover. As no comparison is available on the market (or not accessible due to confidentiality reasons) we did so that the number of clients was obtained by simply offering an extremely low price to the market (This again by taking into account the dbh prices which are known as by far the lowest) We were assuming that the portal should start achieve 200 customers very quick in order to reach the break even point rather soon. These customers are expected to issue some 500 messages a month, approx. 25 per day. Taking the figures mentioned before into account, this does not seem to be unrealistic at all. The problem still not addressed within IP is only how to create a major customer base from a very early point of operation. 60

61 6.2.8 Work Package 7. Exploitation and dissemination The strategy followed to disseminate the results of the IP project was divided into three periods: First period: launching of the project until the beginning of year 2001, to make the project available with its target, concept and organisation. Second period : beginning of year 2001 : to present the first results achieved on May Third period: May beginning 2002 : very concrete presentation of the results so as to the exploitation prospects. First Period: launching of the project. During this period many local operators and Authorities were contacted with the aim of increasing project participation and support in the transport community. Basic Information Pack To facilitate dissemination about the project and to ensure that the message is consistent, we created a basic information pack for distribution through the determined regional channels and depending on the audience/event. This information pack includes: Power point presentations Press releases Newsletters Second Period: Presentation of the first results achieved. During this period the team published some press releases in several publications: L Antenne (France). THB Deutsche Schiffahrstziitung (Hamburg) Gefährilche Ladung (Germany) Bermer Firmen planen IT-Platform für die Seeverkehrswirtshaft XGate forscht mit Internet-Projekt (Bremen) Todo Transporte (Spain) In addition, the consortium prepared a flashy web site ( targeted to the following audiences: Project partners 61

62 Entities belonging to the user group Port communities Transport firms Shippers and shippers associations Press (regional, national and European level) Competent National administrations In addition, the IP project was also presented at the Conference Information Technologies in Ports Year 2000, held in Valencia, (November), where a lot of companies and port s representatives were present, among others: Spain, Italy, France, Tunisia, Egypt and Portugal. IP was also presented to other non european countries : - July 2000: presentation to the National Council of Shippers of Benin - November 2000 : presentation at Lomé - Togo to the Port Authority Third Period: Results of the project. Dissemination activities that were carried out during this period: Press Publications: Spain - Publication in spanish magazine "InterTransport" - Publication in Valencian Newspaper "Diario del Puerto" - France - Publication in french Newspaper L Antenne - Publication in french newspaper La Provence Germany - Publication in THB Deutsche Schiffahrstziitung, Hamburg - Publication in Gefährilche Ladung "Standardisierte Klarierungen" - Publication in "Bermer Firmen planen IT-Platform für die Seeverkehrswirtshaft" - Publication in Bremen newspaper. "XGate forscht mit Internet-Projekt" Presentation at Fairs and to professionals 62

63 - Informative Leaflet of Conference: Information Technologies in ports year 2000 (EUROMAR) November Presentation to the National Council of Shippers of Benin (EUROMAR MGI) July presentation at Lomé - Togo to the Port Authority (EUROMAR MGI) November Presentation to the Egyptian Ministry of Communication (EUROMAR MGI) February Presentation to the International Fair of Transport and Logistics (EUROMAR MGI) April IP presentations for the Steering Group of FITS (Finnish R&D Program on ITS Infrastructures and Services - a cluster programme of Finnish Ministry of Transport and Communication), February 2001, October 2001 (EDI Management) - IP presentation for the Steering Group of the Finnish National Port@Net Community, (EDI Management) June Presentation of the portal concept to French forwarders AOTM, Association of Forwarder Multimodal Transport Organisation (EUROMAR MGI) 13th September 2001 All the information about the project can be found at and/or there is a dissemination CD-Rom that can be solicited to Jose Francisco Vidal (Euromar EEIG) at jfv@portel.es Work Package 8. Project Management. EUROMAR/PORTEL and Innovation Strategies were the responsibles for the project management since their company members have a wide body of experience in the field of Information Systems applied to telecommunications and in Intermodal Transport Systems. The project was managed by a Project Management Board under the supervision of the Steering Advisor Committee. The project achieved its objectives on-time, according to the original project plan. It was only a little delay in the WP3 due to the complexity of building the demonstrators. The project manager delivered progress reports every six months describing the activities undertaken and updating the project plan and the Manpower table. 63

64 Work Package 9. User Group Management. There are two main types of users for the Intermodal Portal project. They are: the providers of the new services and procedures: port authorities, port community system operators, port operators, customs, etc. (they will receive and provide information to the Portal) The users of the port as intermodal transfer point: shipping agents, shipping lines, truck operators, rail operators, inland waterways services, forwarders (they will use the portal as a unified way to connect to each other and the authorities) Some of these clients usually work in different countries, therefore in different ports with different railway companies, changing customs regulations, etc. For them the need of a unified way of managing information is a key element for their competitiveness. A good example of these clients are Shipping Lines facing different kinds of regulations, administrative procedures and telematics services and Logistic Operators encountering different procedures for booking transport services and declaring cargoes. As the users play an important role in the IP project, an individual work-package to manage the user group was set up. It provided feedback and acceptance to all the activities of the project. The user group was a consultative body that acted as an "external assessor" to the project. Its opinions and guidance was included in the Deliverables 10 Live Operation Evaluation Report, 11 Feasibility Study on Barriers for Adoption and served as a continual input to D12 Exploitation Plan. We set up geographically localized user groups for Mediterranean, German, Scandinavian Scenarios (because of language barriers, financial limitations, business differences etc.). Within the local user groups the main objectives were: to discuss and validate IP concepts of their respective region to check the transferability of concepts and applications from and to other regions to monitor the differences in procedures between regions to create awareness on IP measures The companies involved in the user group for each one of the areas were: (for a complete description of their main points of view, please refer to Annex 2: The Point of view of the Users) 64

65 Area Company Role Scandinavia Roadnet Finland Road Transport Mann Lines Shipping Line Finnsteve Port Operator Finnish Maritime Administration Maritime Administration Finnish National Board Customs of Customs TraDav Port Community Provider Viking Line Shipping Line Silja Line Shipping Line Port of Stockholm Port Authority Port of Gothenburg Port Authority Sjöfartsverket Maritime Administration Svenska Hamnar Maritime Association Inport Software developer Germany Hafenamt Bremen&Bremerhaven Ministry of Ports PWL (Peter W. Lampke) Shipping Agent OWL Ocean World Shipping Line Lines Bremen GmbH & Co German Cargo Services Shipping Agent China Shipping Agency Shipping Agent Mediterranean Port of Bilbao, Port Authorities Barcelona, Algeciras, Lisbon and Valencia Port of Valencia Harbour Harbour Master Master Transbull Valencia Shipping Agent MSC Valencia Shipping Agent Port of Livorno and Port Port Authorities of Genoa Costamar Shipping Agent Berge Shipping Agent Fratelli Cosulich Sistema Srl Shipping and Forwarder Agent Saimare SpA Logistic Operator Genova Port Harbour Master Office Harbour Master 65

66 7 MANAGEMENT AND CO-ORDINATION ASPECTS The coordination of the project has been centered around bringing together the diverse experiences of a large consortium partnership. Looking after maximizing the complementary knowledge brought together by each partner in the consortium and its previous experiences, project results, tools and live operational services. This approach has resulted into a rich and sometimes heterogeneous set of results that undoubtly has gone beyond the initial expectations of each individual partner. Attached to this document is an individual summary of the contribution of each partner. From a pure managerial perspective, results have been as follows: Basic collaboration structure defined: Repository (ftp-based documentation). Yahoo-Groups Consortium agreement & Intellectual Property Rights signed. Management Manual. All the Project Control Files delivered. Final Report 66

67 Contact List. 67