EUROPEAN COMMISSION – DG-TREN Euromar EEIG Intermodal ... · IP Consortium thIP Final Report v5 06052002 May 6 , 2002 3 VERSION HISTORY Version Date of creation Status Author Changes/Comments

European Commission – DG-TREN IP Project

IP Consortium IP Final Report v5 06052002 May 6th , 2002 1

EUROPEAN COMMISSION – DG-TREN Euromar EEIG

Intermodal Portal Project

FINAL REPORT

File Name: IP FINAL REPORT V5 06052002 Version Date: 6 MAY 2002 Status: FOR DISTRIBUTION Distribution: PUBLIC Abstract: This document summarise the work

carried out and the results obtained by all the partners.



QUALITY CONTROL

Originator(s): Technical Manager (M. Fernandez)

Visa and Date:

Appraisal authority: Project Management Board

Visa and Date:

Appraisal Authority: Project Manager (________)

Visa and Date:

Appraisal Authority: DG-TREN Project Manager

Visa and Date:



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 Company

Project Management Board Euromar EEIG – PM

Project Officer EC – DG-TREN



Definitions and Acronyms AT: Awareness Team

DG: Directorate General (e.g. DGVII - Transport)

DPM: Deputy Project Manager

EC: European Commission

EDI: Electronic Data Interchange

EDIFACT: EDI For Administration, Commerce and Transport

EEIG: European Economic Interest Group

FT: Financial Team

NCA: National Competent Authorities

PM: Project Manager

PMB: Project Management Board

PQM: Project Quality Manager

RM: Repository Manager

SC: Steering Committee

TT: Technical Team

UC: User Committee

WP: Work Package

WPL: Work Package Leader

SL: Shipping Line

SA: Shipping Agent

VY: Voyage Plan

CR: Call Request

CRP: Call Response

AE: 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



TABLE OF CONTENTS

1 EXECUTIVE PUBLISHABLE SUMMARY...............................................................................7 1.1 PROJECT OVERVIEW .............................................................................................................7

2 PARTNERSHIP INFORMAT ION............................................................................................10

3 OBJECTIVES OF THE PROJECT .........................................................................................11

4 SCIENTIFIC AND TECHNICAL DESCRIPTION OF THE RESULTS..................................15 4.1 THE ROLE OF PORTS AS INFORMATION TRANSFER POINTS ....................................................15 4.2 EUROPEAN SCENARIOS. ......................................................................................................17 4.3 INTERMODAL PORTAL, A EUROPEAN CONCEPT ....................................................................17 4.4 THE SINGLE DESK: SHIP ROTATION. ...................................................................................18 4.5 THE EUROPEAN S INGLE DESK “VIRTUAL SHIP AGENT”.........................................................22 4.6 DANGEROUS GOODS DECLARATION. ...................................................................................25 4.7 TRANSPORT ORDER FOR TRUCKS. ......................................................................................29 4.8 PORT ORDER. .....................................................................................................................31 4.9 PORT ORDER. .....................................................................................................................31 4.10 REAL T IME ETA. .............................................................................................................36 4.11 INFORMATION B ILL OF LADING SYSTEM............................................................................37 4.12 SYSTEM ARCHITECURE: INTEGRATION OF IP NODES. ........................................................39

5 LIST OF DELIVERABLES......................................................................................................41

6 COMPARISON OF INITIALLY PLANNED ACTIVITIES AND WORK ACTUALLY ACCOMPLISHED............................................................................................................................42

6.1 PRESENTATION OF THE PROJECT ORGANISATION................................................................42 6.2 WORK PROCESS .................................................................................................................44

7 MANAGEMENT AND CO-ORDINATION ASPECTS............................................................66

8 RESULTS AND CONCLUSIONS...........................................................................................68 8.1 INTERMODAL PORTAL CONCEPT ..........................................................................................69 8.2 CONTRIBUTION OF THE IP PROJECT TO THE EUROPEAN TRANSPORT POLICY .......................71

9 ANNEX 1: THE IP MESSAGES..............................................................................................75

10 ANNEX 2: THE POINT OF VIEW OF THE USERS...........................................................77



List of Diagrams Two dimensional View of the Ports...................................................................... 16 The Single Desk Business Cycle ......................................................................... 20 Relationship of the Single Desk with Port Authorities......................................... 21 The Single Desk Context Diagram....................................................................... 22 The Virtual Ship Agent Context Diagram............................................................. 23 The Virtual Ship Agent Business Cycle ............................................................... 24 The Dangerous Goods Testbed Architecture...................................................... 27 The Dangerous Goods Business Cycle............................................................... 28 The Dangerous Goods Information Flow............................................................. 29 Transport Order for Trucks Business Cycle ........................................................ 30 The Port Order ...................................................................................................... 33 Transport data in the Port order........................................................................... 34 Real Time ETA Business Cycle ........................................................................... 36 The IP Technical Architecture.............................................................................. 39



1 EXECUTIVE PUBLISHABLE SUMMARY.

1.1 PROJECT OVERVIEW

The IP Project 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 1st Call for the 5th 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



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



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.



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): non-profit, 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 v1 18122001 December 18th, 2001 11

No part of this document may be reproduced in any form or by any means without permission of the IP Consortium

3 OBJECTIVES OF THE PROJECT

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

• IMO FAL Forms

• “Waterborne Single Desk” pilot in the Marnet project

• BOPCOM Tools

• HAZMAT Directive

Waterborne Single Desk

HAZMAT Dangerous goods

• 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

• Maritime/Customs/Port Authorities:.

• Major shipping lines

• Small shipping lines

• Port Community Systems

• HAZMAT national coordination centres.

2) To define an harmonized model to connect port communities with road and rail branches

• Results of the COREM,WISDOM,ITESIC, INTRARTIP, 3SNET projects for integration with other transport modes

Intermodal Waterborne Node

• 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

• Rail / Road operators

• Port Community Systems

• Container Terminals / Stevedores




3) Develop Systems

• Software Applications and message definitions from the relevant projects

• Existing Port community Systems

EDI messages recommended by the International Maritime Organization (IMO) FAL Forms




• Set of software applications

• EDI messages

• XML messages

• Definition of technical architecture

• IP Portal (Intranet)

Compliance with the procedure defined

4) Implement/test systems • System demonstrator Waterborne Single Desk



• Deliverable 10: Live Operation Evaluation report.

• Large Scale demonstration (14 ports) from Scandinavia to the Mediterranean

5) Design the Implementation Strategy

• Results of the tests

• User Group feedback




• Organization

• Legal responsibilities

• Contractual arrangements

• Signed support by participants in the tests

6) Disseminate result • All Waterborne Single Desk



• Marketing materials

• Presentations

• Web site

• Cover the whole transport sector




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




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 email to: K. Fjortoft (Marintek) at [email protected] ). 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.




4 SCIENTIFIC AND TECHNICAL DESCRIPTION OF THE RESULTS.

The aim of the IP Project 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




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:

Valencia Bremen Helsinki

European Single Desks: Ship Rotation, Dangerous Goods, Virtual Ship Agent (A.1)

Inte

rmod

al N

odes

(A

.2)

agent

transshipmentforwarder

rail carrier

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




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.2.

4.2 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):




• 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.

4.4.1 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.




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 1965. It entered into force on 5 March 1967.

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




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.

4.4.2 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




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:




SHIPPINGLINE /

MARITIMEAGENT

PORTAUTHORITY

A

SHIPPINGAGENT

A

SHIPPINGAGENT

C

PORTAUTHORITY

B

PORTAUTHORITY

C

VOYAGE PLAN

CALL REQUEST

RESPONSE

STATUS OF THE VOYAGE

CALL REQUEST

RESPONSE

RESPONSE

RESPONSE

CALL REQUEST

CALL REQUESTCALL REQUEST

SHIPPINGAGENT

B

CALL REQUEST

CALL REQUEST

RESPONSE

RESPONSERESPONSE

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.




shipping line

voyage info

LocalIP Node

Local Community System

European Single Desk

“ship rotation“

European Single Desk

“dangerous goods“

DG information

voyage plan

voyage plan

voyage plan

forwarder

enquiry/quotation

bookingbooking

port order

VirtualShipAgent

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.




Virtual Ship Agent

businesslogic

remoteterminal

accountingsoftware

accountant

shipperforwarder

webserver

EuropeanSingle Desk“ship rotation”

port-communitysystem 1

port-communitysystem 2

shipping line system 1





administration(i.e. customs)

remoteterminal

voyage plan, enquiry,quotation, booking

voyage plan, rates, booking

voyage plan

EuropeanSingle Desk“dang. goods”

agent

DG notification

The Virtual Ship Agent Business Cycle

4.5.1 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.




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.

4.5.2 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.

4.6.1 “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.




4.6.2 Business Process

Currently, the declaration of dangerous goods in carried out in ports using port-specific 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.




BERMAN

BOOKING

APERAK

XMLMESSAGES

PORTEL

SIC-VLC PROTISNET

INFOLOGISTICA

-

BERMAN

BOOKING

APERAK

XMLMESSAGES

PORT@NET

DBH

DAKOSY

SHIPREP

IntermodalPortal.com

IP Node Port Ause IP DG Service

IP Node Port C don‘t useIP DG Service

* Example of local community systems.

Shipping Agent

Port Authority

IFTDGN

APERAK

IP Node Port B use IP DG Service

Shipping Agent

Port Authority

IFTDGN

APERAK

XML IFTDGNdraft

XML IFTDGNdraft

PORTEL

SIC-VLC PROTISNET

INFOLOGISTICA

European Single Desk“dangerous goods“

European Single Desk“dangerous goods“

The Dangerous Goods Testbed Architecture

The process of Dangerous Goods Declaration is detailed in the following picture:




Authority of Port A Authority of Port B Authority of Port C

Ship Owner

Shipping agent in Port A

Shipping agent in Port B

Shipping agent in Port C

IFTDGN

APERAK

IFTDGN IFTDGN

APERAKAPERAK

draft ofIFTDGN

draft ofIFTDGN

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.




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.

Agent A Agent C

Port A Norway

Dangerousgoodsnotification

Port C Finland

Acknow-ledgementPort B Spain

Agent BCentralised IP on the web

CertifiedIP node

Local portcommunitysystem

CertifiedIP node

Local portcommunitysystem

Dangerous goodsnotification

Acknowledgement

Dangerous goodsnotification

Acknowledgement

EuropeanSingle Desk“dangerous goods“

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




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

Road haulage company

Transport Order, Freight Waybill

Transport Order, Freight Waybill

Client of the road haulier

Freight Invoice

IP

Freight Waybill

Freight Invoice

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




• 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 e-mail 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




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 2002. 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.




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.




Transport data in the Port order




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




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.

VTS station

1) basic data of the vessels (XML)

2) voyage information (XML)

3) ETAs of the vessels (XML)

4) national vessel time schedules(XML)

Port@Net

IP

Real Time ETA Business Cycle

The Real Time ETA module works in the following way:




The Port@Net 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 Port@Net 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 Port@Net system.. With regular intervals, the Port@Net 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.

4.11 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.




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 key-entry 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.




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.

4.12 SYSTEM ARCHITECURE: INTEGRATION OF IP NODES.

In a conceptual level, the integration of IP has been made according to the following picture:

- Ship Rotation- Dangerous Goods- Maritime Booking.- Voyage Offering- Quotations.- Transport Order

Trucks- Real Time ETA.- Port Order

BERMAN

BOOKING

APERAK

XMLMESSAGES

PORTEL

SIC-VLC PROTISNET

INFOLOGISTICA

- Ship Rotation- Dangerous Goods- Maritime Booking.- Voyage Offering- Quotations.- Transport Order

Trucks- Real Time ETA.- Port Order

BERMAN

BOOKING

APERAK

XMLMESSAGES

PORT@NET

DBH

DAKOSY

EUROTRANSPORTNET

SHIPREP

IntermodalPortal.com

XML

IP Node A IP Node B

* Example of local community systems.

The IP Technical Architecture




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)




5 LIST OF DELIVERABLES.

OVERVIEW OF DELIVERABLES

Deliverable Reference Version Access Level

Date of delivery

D1 Overall Intermodal Portal Scenario and Test Cases

D1 Final Restricted June 2000

D2 Waterborne Single Desk Procedure


D3 Waterborne Intermodal Node Procedure


D4 Dangerous Goods Procedure D4 Final Restricted June 2000

D6 Waterborne Single Desk initial System

D6 Final Restricted February 2001

D7 Waterborne Intermodal Node initial System


D8 HAZMAT Dangerous Goods initial System


D9: Integrated IP Demonstrator System

D9 Final Public April 2001

D10 Live Operation Evaluation Report

D10 Final Public February 2002

D11 Feasibility study on barriers for adoption


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




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:




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 Company Leader WP1: Refinement of the Intermodal Portal Concept

Euromar-Portel

WP2: Specification/Harmonization of procedures

ISL

WP3: Internal Integration of technologies

IS

WP4: External Integration

EDI

WP5: Demonstration and Refinement

INFOPORT

WP6: Define deployment approach and legal support

TFK

WP7: Exploitation and dissemination

Euromar-Gyptis

WP8: Project Management

Euromar-APV

WP9: User Group Management

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.




• 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 IP Project.

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




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.




6. Define implementation policies and the legal framework required to launch the Intermodal Portal for commercial exploitation

7. Transfer and disseminate the results.

6.2.1 Project Bar and Pert Chart




Id Task Name1 The IP Project

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 Single Desk

12 T3.2:Integrate/build Demonstrator for Waterborne Intermodal Node

13 T3.3:Integrate/build Demonstrator for Hazmat Dangerous goods

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 deployment

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 Relationships

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

T1 T2 T3 T4 T5 T6 T7 T8 T9año 1 año 2




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)




Projects

Functionalities

Bo

pC

om

Pro

sit

Co

rem

VA

TT

MA

RN

ET

3SN

ET

INT

RA

RT

IP

ITE

SIC

EU

RO

-B

OR

DE

R

INT

ER

PO

RT

TR

IM

INF

OL

OG

SIT

S

SH

IPR

EP

/ P

OR

TW

IN

NO

MIT

DIS

C II

PO

RT

@N

ET

Su

m

VTS Vessel Traffic Systems - - - - ? - - - - - ? - - ? ? ? ? ? - 70 Vessel Tracking & Tracing - ? ? - - ? ? - - - ? ? ? ? ? ? ? ? ? ? ? ? - - 125

Container Tracking & Tracing - - - ? ? ? - - ? - ? ? ? ? ? ? ? ? ? ? - - 100 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 - - - - ? ? ? - ? ? ? ? ? - - 65 te

chn

ical

fun

ctio

nal

itie

s

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 ? - ? - - - - - ? ? ? ? ? ? ? - - 70 dat

a co

nte

nt

Dangerous cargo handling ? - - - ? ? - - - - ? ? ? ? ? ? ? ? ? ? - ? 105




Dangerous cargo pre-notification ? - - - ? ? - - - ? ? ? ? ? ? ? ? ? ? ? - - 105 Freight market - ? ? - - - - ? - - ? ? ? - ? - - - 60

Voyage Definition - - - - ? ? - ? ? - - ? ? ? ? ? ? ? - ? ? 110 Call Request - - - - ? ? - - - - - ? ? - ? ? ? - ? ? 80

DG Declaration - - - - ? ? - - - - ? ? ? ? ? ? - ? ? ? - ? ? 100

Other Administrative communication with authorities ? - - - ? ? - - - - ? ? ? ? - ? ? ? ? - ? 90

Sum 80 85 50 55 190 60 75 50 20 230 255 220 145 225 110 55 140

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




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.




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.

6.2.4 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)




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.

6.2.5 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:




Testbed External System Explanation

Port@Net 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.

The VTS system of the Turku VTS station

this system has been integrated with Port@Net system, from which the national vessel schedules are retrieved to published on the Finnish IP website

Port of Valencia VTS system 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.

RoadNet’s traffic operating system

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

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

Intermodal Node

DAKOSY – Hamburg PCS 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.




Port@Net 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

Port of Valencia Dangerous Goods System

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’s DG National System Portel is the National Authority to collect the information about Dangerous Goods Notifications in Spanish ports

Single Desk Portel’s DUE System for Integrated Spanish Berth & Anchorage Request System

This is a test version system to unify the procedure for the Maritime Authorities in all Spanish Ports

6.2.6 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

countries in the Baltic and Scandinavian Region: Sweden, Norway and Finland. Ports that have

• Real Time ETA • Trasnport Order for

Trucks • HAZMAT Dangerous

Goods




participated in this test phase are:

• Gothemburg

• Stockholm

• Turku German Scenario This Scenario covers

Germany, with the ports of Hamburg, Bremen and Bremerhaven

• Maritime Quotation and Booking

• Sailing Schedule • Port Order Online • Transport Order for

Trucks (demo)

Mediterranean Scenario 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.

• 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.




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.

6.2.7 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:




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. 5.000

Shipping Agents

approx. 5.800

Freight Forwarders

approx. 7.000

Road Transport Firms

approx. 430.000

Rail Transport Firms

approx. 460

Stevedoring Companies

approx. 500

This overview indicates a total market of approx. 450.000 companies being potential candidates for an IP application in their premises. Deducting the road hauliers, a number of approx. 20.000 core ventures is left as potential market for IP applications.




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 • 600.000+ (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,




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 90 minutes (estimated acc. to on-site visits, agents & forwarders) Time required in total per transaction 135 minutes Potential savings by using entirely electronic documentation and assistance (like the virtual portal) approx. 100 minutes or approx. 1.5hrs Cost per working hour in Germany 60,- EUR Potential savings 90,- EUR against total costs of manual processing, approx. 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.




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:

l First period: launching of the project until the beginning of year 2001, to make the project available with its target, concept and organisation.

l Second period : beginning of year 2001 : to present the first results achieved on May 2001.

l Third period: May 2001 - 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 (http://www.intermodalportal.com) targeted to the following audiences: • Project partners




• 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




- Informative Leaflet of Conference: Information Technologies in ports year 2000 (EUROMAR) November 2000

- Presentation to the National Council of Shippers of Benin (EUROMAR – MGI) July 2000

- presentation at Lomé - Togo to the Port Authority (EUROMAR –MGI) November 2000

- Presentation to the Egyptian Ministry of Communication (EUROMAR – MGI) February 2001

- Presentation to the International Fair of Transport and Logistics (EUROMAR – MGI) April 2001

- 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 2001

- 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 www.intermodalportal.com and/or there is a dissemination CD-Rom that can be solicited to Jose Francisco Vidal (Euromar EEIG) at [email protected].

6.2.9 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.




6.2.10 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)




Area Company Role Roadnet Finland Road Transport Mann Lines Shipping Line Finnsteve Port Operator Finnish Maritime Administration

Maritime Administration

Finnish National Board of Customs

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

Scandinavia

Inport Software developer Hafenamt Bremen&Bremerhaven

Ministry of Ports

PWL (Peter W. Lampke) Shipping Agent OWL Ocean World Lines Bremen GmbH & Co

Shipping Line

German Cargo Services Shipping Agent

Germany

China Shipping Agency Shipping Agent Port of Bilbao, Barcelona, Algeciras, Lisbon and Valencia

Port Authorities

Port of Valencia Harbour Master

Harbour Master

Transbull Valencia Shipping Agent MSC Valencia Shipping Agent Port of Livorno and Port of Genoa

Port Authorities

Costamar Shipping Agent Berge Shipping Agent Fratelli Cosulich Sistema Srl Shipping and

Forwarder Agent Saimare SpA Logistic Operator

Mediterranean

Genova Port Harbour Master Office

Harbour Master




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

•




Contact List.




8 RESULTS AND CONCLUSIONS

European integration is currently on the verge of achievement. Economically speaking, the decision-makers in the domain of logistics think now on a macroeconomic level. Thus, the current logistical strategies are built at a European level. Actually, one of the major issues in the logistics field is the coordination of numerous partners of different professions, cultures and sizes. This wish of coordination and harmonisation is translated in practice by the necessity to harmonise complex procedures and by the need of communication between heterogeneous Information Systems. In the field of transport, huge disparities exist if we compare the evolution of the Information Systems of the different transportation modes. So, air carriers, by the intrinsic characteristics of this transportation mode (the speed), have developed years ago tools or information systems allowing a real time management of the goods and a worldwide data exchange. This statement is all the more true in the field of express freight where integrators such as UPS, DHL or Federal Express built effective solutions for tracing and tracking. Other means of transport, especially the maritime transport mode, did not manage to achieve the same increase in that field. This could be partially explained by the fact that intermodal mode links different partners with heterogeneous interests and do not follow the good from door to door. Thus, the operators in the European Union tend naturally to build global information systems and methods aiming to connect the different systems in the member states for an efficient, reliable and fast follow-up of the goods. This objective can be grasped on several levels: • At the security level: the recent maritime disaster of the ERIKA brought out

the difficulty of tracking the ships sailing in European territorial waters. • At the level of a ship’s entrance in a harbour: in the case of a Short Sea

Shipping transport, the same merchandise must be declared several times in the European ports.

• At the level of merchandise tracing: currently, no harmonized European system exists to follow a transportation from door to door.

• At the level of intermodal transportation: by definition intermodality puts in relation actors having disparate systems, not connected to one another, this entails a dilution of the information relative to the follow-up of the goods.

Starting from this statement and taking into account that Information and Communication Technologies (ICT) allow productivity benefits and a better data




exchange, the European Commission DG TREN accepted that EUROMAR EEIG brought together the most acute know-how in the field of ICT applied to logistics field in order to build a maritime communication platform at a European level.

8.1 INTERMODAL PORTAL CONCEPT

IP partners developed the project having as a final aim to improve the integration of ports in the intermodal chain, offering a panel of information and communication tools to the operators and finally to harmonise the administrative procedures at a European level. A web site promoting IP project has been built and hosted at the address: http://www.intermodal.com .

8.1.1 A Single Entry Point of the information

The main focus of the intermodal portal project is the setting up of a single entry point of the data concerning an intermodal transport. The project has developed an application allowing the maritime operators to key in the information at the source and then to dispatch it to the partners of the intermodal chain. So, for the first time, IP links shipping lines, maritime agents and port authorities. This tool aims to improve the administrative procedures when a ship calls at a port. The FAL directive from the International Maritime Organization (IMO) is taken into account by providing an on line key entry of FAL forms. The data entered by the shipping line are then directly redirected to the next port of call of the voyage. This test-bed is for: • the harmonisation of administrative procedures and making them easily

usable in all European ports. • the setting up of a common interface between port authorities, maritime

agents and shipping lines. The Single Desk application demonstrate how freely the data corresponding to a voyage can circulate within the EU eliminating the administrative procedures in each port of call and thus improving Short Sea Shipping inside Europe.




8.1.2 The follow-up of Dangerous goods

The ambition of the IP project was also to support the information flow linked to the transportation of Dangerous Goods. This set of services will facilitate the data exchange at two levels: • At a local plan: data interchange between the port authority and the maritime

agent • At a European level: interchange between ports for dangerous goods. The portal will automatically dispatch the information on dangerous goods to the concerned parties, and the port authority will therefore have a precise view of the dangerous goods at import, export or in transit. IP appears as a communication platform: • warning messages sent at the time of arrival, departure or transit of

dangerous goods • acknowledgement message to authorise or deny the entrance of a DG in a

port. Potential users of these services are the shipping lines and those who are responsible for carrying dangerous goods from port to port; the ship agents who represent the shipping line(s) in a particular port; the authorities designated to perform checks on the transport of dangerous good (Port Authorities, Maritime Authorities, etc.). This test-bed wants to facilitate the harmonisation of the DG declaration and to allow a rigorous follow up of dangerous goods in a port.

8.1.3 The Intermodal node

Intermodal transport implies often complex organisations which link numerous and heterogeneous partners. The approaches of intermodality emphasize economical theories proper to these different actors: shippers, carriers, infrastructures managers, maritime agents, forwarders etc. A strong reorientation concerning the maritime activity has been decided at a political level. It appears indispensable not to consider maritime transportation separately but to be interested in the questions of pre or on-carriage of the merchandise by all the means of transport and then to consider the whole logistic chain.




In this way, Intermodal Portal project aims at the integration of the intermodal transport partners by a smooth data interchange between the different existing Information Systems.

8.2 CONTRIBUTION OF THE IP PROJECT TO THE EUROPEAN TRANSPORT POLICY

Every transport is basically a shared work process, where numerous participants are deployed covering a wide range of interests and duties. Most of these relations and interactions are ruled by tradition and law. Most participants in transport chains identify major areas for improvements in these working routines. With IP, a set of new applications have been developed (as lined out in previous section). These applications do not only cover technical routines but as well inter- and intra-organizational working procedures that fully supports the implementation of a European Transport Policy oriented towards the rationalization of intra-European procedures. Applying innovated processes, for instance generated by the simplified dangerous cargo reporting tool would enable companies and organizations deploying it to benefit from substantial savings hereby. This demonstrates how Information technologies, if applied in a sensible manner, can be of immense help to actually facilitate the implementation of directives that are very difficult to enforce without the support of the right enabling tools. According to a WTO estimate, approx. 7% of world trade volume is being consumed for documentation and administration. This would sum up to approx. 15 bill. USD for the EU being spent on such issues. The potential for any facilitation and cost saving measure in this area is obviously enormous. Improved processes would also contribute significantly to the quality of the service being provided to transport customers. By establishing more streamlined working routines and improved efficient information handling any competitive position of actors in transport service is being improved as well. IP shows that IT techniques cannot only marginally improve and support existing port procedures, IP rather provides innovative technology that allows significant improvements and simpler overall handling. It is this simplification that is required to help Intermodal Transport to achieve a major breakthrough rather than a mere marginal time saving. The tools developed or improved within IP allow business re-engineering while they are also able to support and improve existing procedures. This allows for a smooth change process,




accepting that a fundamental re-engineering cannot often be achieved and makes the IP concept an effective platform to support the implementation of new and more ambitious initiatives to rationalize the business processes of this critical industry at a European level. Within the administration of transport and cargo handling procedures, a broad variety of different procedures can be identified. This circumstance leads to the fact that most tasks relating to administration and organization within waterborne transport are far from being harmonized on the European level; they sometimes differ drastically from one port to the other (even within a country). Therefore, IP provided investigation and practical contribution in the adaptation of the FAL forms, developed by the International Maritime Organization (and supported by an EU Directive). These forms provide recommendations for standard procedures that, once applied overall in Europe, will contribute substantially to trade and transport facilitation. This result is addressed towards standardization bodies, national and regional administrations and policy makers. IP also contributes to the THEMIS project. As one of its tasks this project assesses standardization requirements. Overall, the situation for port related procedures is very complex, as the rules, procedures and standards differ widely for road, rail, and sea transport. Fortunately an alignment is at least underway for the declaration and handling of dangerous cargo.

8.2.1 In the field of transport

The Intermodal Portal project, besides improving port operations supporting quality shipment, supports the European policies of transport, environment, safety and free movement of goods within the European Union. It will act on these concrete factors:

a) Free movement of goods in Europe which is true for truck transports but not for maritime where the same container entering by sea has to be formally declared in each and every port of call

b) Intermodality where logistic operators have to deal with a disparate array of procedures, modal oriented systems and isolated transport services leading to high "friction costs" (in changing transport modes)

c) Short Sea Shipping suffering from difficult and unharmonised administrative procedures preventing Short Sea Shipping as a viable alternative to road transport for short and medium distances




d) Security and Safety: providing a suitable and widespread telematic service to support the implementation of the HAZMAT directive to handle the information flow associated to dangerous goods.

e) Quality Shipping: by providing a sufficient level of service to transport operators in and around seaports in Europe

8.2.2 In the social field

They are two main challenges tackled with the IP project: • To support the change towards the Information Society • To support the use of intermodal chains involving waterborne transport. The reduction of road transport or at least a significant reduction of its growth is considered as an important contribution to the Community social objectives. In the long term perspective, Intermodal Portal will contribute to port efficiency and thus to improve its role for economy and employment. A port is an important service provider and could generate many jobs outside the port and also internally within its own structure. As regards pollution and environment protection, the IP project will contribute to re-balance the various transport means and therefore will take part to the limitation of road transport. The impacts of the IP project mentioned above also improve citizens’ quality of life, especially in area with high traffic and a large risk for traffic congestions on the roads, by reducing the number of truck transports.

8.2.3 In the scientific and technical field

The IP project made use of appropriate tools and project results from 4th FP projects. The technological challenge was to combine and integrate all these components within the information systems operated by the users. The IP project integrates the “classical” EDI interchanges with the new Web (e.g. XML) technologies. So, the services offered can satisfy a big variety of users – independent of their current level of IT implementation.




8.2.4 Conclusion

IP project brings out a wish of harmonization of procedures at a European level for maritime transport operators and then to answer the problems of coordination and integration of several disparate Information Systems. These involvements have an ambition to follow the necessary changes needed by the European Commission in the fields of maritime safety, improvement of data exchange at a European level and in the promotion of short sea shipping.




9 ANNEX 1: THE IP MESSAGES

The methodology for creating the messages is based on creating XML message definitions on the basis of EDIFACT message implementation guides. A method for doing this was developed in the Pharos project. The report “Transformation of EDIFACT message types to XML via UML” describes the details. In this paper the messages are defined by both DTD (Document Type Definition) and XML schemas (W3C October 2000 version.) Acknowledge message The XML message is generated on the basis the EDIFACT message APERAK (Application Error and Acknowledgement message). The XML message is denoted XML-APERAK. The XML-APERAK is used

1. To acknowledge to the message issuer (IP of the port of departure) the receipt of his message.

2. To inform the message issuer that the message received has been rejected due to errors found during processing of the message.

Arrival notification message. The XML message is generated on the basis of the EDIFACT message CUSREP (Customs conveyance report message. This XML message is denoted XML-CUSREP. The XML-CUSREP is used to transfer from the IP node of the port of departure to the IP node of the port of call the following data:

1. Message data: Message number, type, date and time, sender, status. 2. Agent data: Identification of the agent in the port of call. 3. Vessel data: Vessel identification: IMO/Lloyds number, call sign and name.

Vessel characteristics: Length, breadth, dead weight, gross tonnage. 4. Voyage data: Voyage number according to port of departure, port of departure

with area (quay) time of departure, port of call with area (quay) with time of arrival and departure.

Dangerous Goods Notification Message The XML message is generated on the basis of the EDIFACT message IFTDGN (Dangerous Goods Notification Message). This XML message is denoted XML-IFTDGN. The XML-IFTDGN is used to transfer from the IP node of the port of departure to the IP node of the port of call the following data:




1. Message data: Message number, type, date and time, sender, status. 2. Vessel data: Vessel identification. 3. Voyage data: Voyage identification. 4. Cargo data: According to the HAZMAT directive.

Customs Cargo Report The XML message is generated on the basis of the EDIFACT message CUSCAR (Customs Cargo Report Message). This XML message is denoted XML-CUSCAR. The message is used to report cargo data from a carrier or agent. It is possible to report cargo data on two levels:

• Manifest level. Then the message is used to report to Customs for declaration purposes.

• Statistical level. In this case the message is used to report cargo for statistical purposes.

Vessel Data Movement Message The XML message is generated on the basis of the EDIFACT message VESDEP (Vessel Data Movement Message). This XML message is denoted XML-VESDEP. The message is used to report vessel and voyage data. Call Request Message The XML message is generated on the basis of the EDIFACT message BERMAN (Berth Management Message ). This message is denoted XML-BERMAN The Berth management message is a message from a carrier, its agent or means of transport to the authority responsible for port and waterway management, requesting a berth, giving details of the call, vessel, berth requirements and expected operations. Voyage Plan Message The XML-VOYPLAN message has not been generated on the basis of an EDIFACT message, using the same procedures as for the other messages.




10 ANNEX 2: THE POINT OF VIEW OF THE USERS

Finland

10.1.1 Transport Order Module

Topic Reporting Details

User Group The piloting companies and their roles are the following:

Roadnet Finland, road transport company receiving the transport orders as XML messages as well as the freight waybills based on the transport order.

Mann Lines, a shipping line operating a vessel with a rotation between UK, German and Finnish ports. Within the pilot scenario, Mann Lines will the party responsible for the entry of transport orders and freight waybills that will be sent to Roadnet Finland.

Finnsteve, the port operator in the port of Turku and taking care of pre- and on-carriage bookings on behalf of their clients. Finnsteve will also pilot the transport order module by keying in the transport orders and freight waybills to be passed on to Roadnet.

Summary of the work done

The user group around the Transport Order module has been actively taking part in the specification of the functionality.

The requirements for Mann Lines and Finnsteve in order to pilot the system is to have a PC and Internet access, since both of them will be using the website application.

Roadnet Finland has been developing the external integration between the incoming transport order and freight waybill messages and their own operative IT systems. This external integration will be completed by end of July.

The before mentioned companies have been testing and piloting the Transport Order module actively since September 2001.

Mann Lines and Finnsteve have been using the Transport Order web application and Roadnet




Finland integrated the transport order and freight waybill messages to their route planning system.

Feedback from the users

The users have been quite satisfied with the functionality of the transport order module. The two pilots that have used the system have stated that the module is functioning well and is simple to use. Also the integration succeeded with Roadnet’s operative IT system. Main problems were due to the telecommunication failures, but these were solved during the piloting phase.

10.1.2 Real Time ETA


User Group Finnish Maritime Administration, responsible for integrating the VTS-system with the national port community system Port@Net

National Board of Customs; the Customs offices dealing with vessel and cargo clearance would like to receive as accurate ETA information as possible regarding vessels calling Finnish ports. The pilot scenario will focus around the port of Turku, the VTS system of the port of Turku will integrated with Port@Net and Port@Net will be integrated with the Finnish IP node. The IP node will receive as XML files the ETA of the vessels approaching Turku.

Import companies: the importing companies will use the module to browse the vessels bound for Turku and to obtain the port call reference number they need in order to declare the cargo for the Customs office.

Transport companies: the transportation and forwarding companies would like to know the accurate ETA of the vessels calling Turku in order to avoid unnecessary waiting times.


The Real Time ETA module is completed in Finnish, the English version as well.

This module will now publish the national vessel time schedules, that anyone with an internet access can browse through. Due to the budget constraints of the Finnish Maritime Administration, the ETA data coming from the VTS system has not been




coming from the VTS system has not been completed, it will be delayed until year 2002, but the IP system itself contains the data field for the VTS/ETA information as soon as it is transferable.


The need for the national vessel time schedules that are publicly available is really strong, even if the ETA from VTS would be missing, since the Finnish Customs will be implementing their Integrated Customs System during 2002. In order for the users to handle the Customs issues electronically, they need to have the Customs reference number of a port call as well as the actual time of arrival and sailing. The IP application is currently designed to solve these problems.

10.1.3 Dangerous Goods Testbed


User Group Finnlines in Finland: a shipping line running regular line service to several European ports, one of the major ones being Lübeck/Travemünde. Finnlines sends the Dangerous Goods Notifications (DGNs) to the national port community system when their vessels are leaving Finnish ports. Normally they would have fax the DGNs to the next port of call which in this piloting scenario will be Lübeck. Within the piloting scenario these DGNs will be automatically retrieved from Port@Net system and sent to the TraDav as XML messages.

TraDav is the port community provider of ports of Lübeck and Travemünde and will be receiving the Finnlines DGNs to be passed on the Lübeck Port Authority.

Viking Line and Silja Line are car-passenger-ferry lines operating between the ports of Turku and Helsinki in Finland and the port of Stockholm in Sweden. The DGNs entered by these shipping lines into Port@Net when the vessels are leaving Finnish ports will be retrieved and sent to the port of Stockholm as XML messages. These messages are the pre-notifications of the incoming dangerous goods.




Port of Stockholm will be the recipient for these messages and the messages will be read and stored in their own IT system called PortIT.


The module that will retrieve the DGNs from Port@Net’s database and pass them on to the Finnish IP node has been completed. The first pilot was supposed to be the TraDav system receiving the Finnlines DGNs. This piloting scenario unfortunately was never realised due to the fact, that the port authority of Lübeck has to decide whether electronic notifications are accepted.

The other pilot user, port of Stockholm finalised their inreading module for the DGNs of Viking Line and have piloted the receipt of electronic DGNs sent by Port@Net in Finland. These DGNs have been entered into Port@Net application by Viking Line in Finland.


The requirement for receiving DGNs on time and automatically has been several times stated by the port of Stockholm as well as port of Lübeck, since this way the port authorities receive information efficiently and well in advance before the vessels are actually calling their ports.

The system with the port of Stockholm is up and running and will be continued also during 2002. Additionally the transmission of the port call message and the vessel declaration messages were added.

Sweden


User Group Port of Gothenburg: The port of Gothenburg is the major port of Scandinavia with annual cargo turnover 30,4 million tonnes, The port of Gothenburg is a combination of port operator and port authority functions both groups are represented within the IP user group.

Sjöfartsverket – Swedish Maritime Administration (SMA): The Swedish Maritime Administration is a public enterprise within the transport sector. SMA




works to keep the sea lanes open and safe. The Swedish Maritime Administration is the National Competence Authority NCA for the HAZMAT directive.

Svenska Hamnar – Association Ports of Sweden: The aim of the Association Ports of Sweden is to defend the interests of ports, to establish co-operation between ports and to support maritime transport and shipping interests in general. The association supports the ports when it comes to transport-policy, transport research, the interests of ports, their customers and the community which they serve. They also co-operate with port organisations in the other Nordic countries and we are members of the European Seaports Organisation

New member: Inport. Inport used to be owned by the Association Swedish Ports but is today a private company. Inport has developed the product PortIT, a port administration software, that is used by 16 ports in Sweden.


16.02.01 Visit at the Port of Gothenburg including the shipping lines Unifeeder and DFDS TorLine: To find out the user requirements on a system for reporting dangerous goods, the actors below were interviewed. They were also informed about the IP concept.

13.02.01 Presentation of GEGIS at DAKOSY, Hamburg: The responsible authority for dangerous goods in Hamburg is the “Wasserschutzpolizei” (police for water protection). In Hamburg the system GEGIS (a system for handling dangerous goods within a port, including declaration and reporting to the NCA). The system was demonstrated and the IP concept including possible interaction was discussed.

02.01.01 Workshop in the Port of Gothenburg: The Swedish Maritime Administration is planning to buy Port@Net. Port@Net will be used for both ship declaration and declaration of dangerous goods. This will have a major impact on the ports work processes. The objective of the workshop is to provide a forum for information exchange including a first definition of the user requirements. The possible usage of an IP-node will be discussed as well.




15.06.01 Meeting with the port of Gothenburg regarding the analysis of how reporting and administration of dangerous goods is handled in Sweden with the port of Gothenburg as case. The analysis has covered the relationship between the authorities (both the national and the port specific), the operators in the port and the customers, e.g. line agents.

5.10.01 Meeting with Port of Gothenburg, Association Swedish Ports and Sjöfartsverket. Presentation of the analysis carried out on Port of Gothenburg. And discussion on haw Sweden should proceed with the development of a national system.

31.09.01 Meeting with Inport. Discussion on how to integrate the Swedish ports using PortIT in the IP-node network.

Feedback from users

For the Port of Gothenburg, a system for reporting and administration of dangerous goods most include the work in the terminal. That means that all goods that arrives to the terminal (both from the land and seaside) most have been reported and approved. For the port it is also very important that the reporting routines should be as simple as possible for the customer, i.e. no double reporting.

The national maritime administration welcome the development of standard messages within IP.

Inport is preparing PortIT to be able to receive messages from an IP.-node.

Germany

10.1.4 Virtual Ship Agent


User Group Hafenamt Bremen&Bremerhaven: The Ministry for Ports, Transport and Foreign Trade is a ministry on the one hand but on the other hand responsible for the ports owned by the city of Bremen as well. Ownership includes the public owned ports of Bremen-City and Bremerhaven. Primary task of the




Bremen ministry for ports is to foster and ease every economic activity taking place in the port area. This is mainly concerning licensing of properties and land located within the entire port area. The city of Bremen, represented by the ministry for ports, is mainly responsible for constructing and maintaining port infrastructure. This responsibility covers water areas, quays, roads as well as railways located in the port.

PWL (Peter W. Lampke): an independent liner agent representing over 20 shipping lines (general cargo, container, Ro/Ro). PWL also works as port agent and general agent. Their service includes cargo booking, chartering, despatch in the ports, supercargo, container controlling and logistics. PWL has about 130 employees with offices in Bremen, Hamburg and Bremerhaven

OWL Ocean World Lines Bremen GmbH & Co. KG: Liner agency for Bremen and Bremerhaven. Full Container NVOCC Europe / USA / Canada

German Cargo Services (GCS): Liner Agency for Bremen and Hamburg. Break bulk world-wide.

China Shipping Agency (Germany) GmbH: Liner agency for Germany, Scandinavia and Austria. Full Container Service North Continent/Far East and China


The sailing schedule module has gone into production. The users are being trained, and the system is fed with the data from the shipping lines.

The first version of the online enquiry/quotation/booking module is ready for testing. Currently only manual operation by the agents is available, but integration into legacy systems is scheduled to be accomplished this year.

Integration with local IP node (DAKOSY) has been established and is being tested.


Apart from a few details, the users are quite satisfied with the results of the sailing schedule module. Most problems arise from the different work-flows that used to exist in the different agencies. The users expect a great increase in effectivity and productivity as a result of the harmonisation and automation of




as a result of the harmonisation and automation of the sailing schedule production.

Additional remarks

A second Virtual Ship Agent is being deployed in Valencia, Spain.

10.1.5 Port Order @ Online


User Group Port Community System Providers

Port Administrations

Shipping Agents

Freight Forwarders

Stevedores

Container Terminal Operators

Inland Transport Operators (Truck, Rail, Barge)

Freight Forwarders

Port Authorities/Harbour Master


The following modules have been completed and are being tested:

• Vessel Information and ship rotation

• Dangerous Goods (HAZMAT)

• Master Data (Commodities, ISO-Codes for Containers, ..)

• Port-Order data (Customs, ...)


none have been provided

Spain

10.1.6 Single Desk


User Group Port of Bilbao, Barcelona, Algeciras, Lisbon and Valencia are user of this service.




Single Desk users in the Port of Valencia are:

Port Authority of Valencia: It’s the authority to receive the Berth and Anchorage request and is the Authority to authorise them.

Port of Valencia Harbour Master (Capitanía Marítima de Valencia): It’s the Authority to receive the request for the arrival and departure of vessels from Spanish Ports and who authorises navigation through Spain’s seas.

Shipping Agents:

Transbull Valencia: Maritime Agent operating several lines at the Port of Valencia. These lines are Nordana, Compagnie Marrocaine, Medex, Star Shipping, Borointermed and Sanko. They cover Africa, the Mediterranean, America and Middle East.

MSC Valencia: Maritime Agent operating at the Port of Valencia. They represent Mediterranean Shipping Company which cover with it’s lines the whole world.


In the first year of the project all the users indicated above were asked several questions about the procedures included in the project. Several mails, telephone conversations and interviews were held between the users and Infoport Valencia, Innovation Strategies and Portel in order to refine the definition.

13th of March 2001 a meeting was held in Barcelona with Port Authorities of Barcelona, Bilbao, Valencia, Algeciras and Tenerife in order to present them the Single Desk Application, they were also informed about the progress of the Dangerous Goods Application and the definition of the Intermodal Node. The rest of the users invited by mail to use the Pilot.

October 2001 Contacts have been done with the users. They’ve been sent the documentation to use the applications.

Single Desk Web Application has been developed by Innovation Strategies for the different users to have an easy access to the IP node.


The functionality satisfies the users who have been involved in the “Service Level” definition in the IP project.




The APL (Lisbon) make the following conclusions:

As a conclusion to these considerations (...), it is a definitive opinion that this Project could be very interesting to the Port of Lisbon, but requires some development toward integration with our IT solutions, if that is possible.

Many information fields are unnecessary, while others can be adapted to fulfil other needs.

The main issue is that the information is scattered along the levels of insertion, while today that same information is sent all at the same time. This could represent some trouble, but that could be achieved by getting the Technical staff together, and discuss all the implications of those changes / improvements of this solution.

Additional remarks

Under an initiative of PORTEL and Puertos del Estado, the Spanish Maritime Administration is going put into force a ministerial order to harmonise the proceedings for call and berthing request for the Spanish ports. PORTEL will begin to exploit the service for the Spanish ports.

10.1.7 Dangerous Goods


User Group Port of Valencia Users are to test the Dangerous Goods Testbed together with Port of Livorno and Port of Genoa in Italy.

The Users in Valencia are:

Port Authority of Valencia: It’s the authority to receive the Notifications and re-send them to other Ports.

Costamar: It’s a Shipping Agent who works with Costa Container Lines.

Berge: It’s a Shipping Agent who works with I/CGM Sud Lines.

These two Shipping Agents are to send DG Notification to the Port Authority of Valencia and receive the authorisation from it.


Contacts have been done with the users.




work done Infoport Valencia is actually developing the translation from the XML IP DTD into the EDIFACT DG Notification format that the Port of Valencia’s DG Management System needs.


The functionality satisfies the users who have been involved in the “Service Level” definition in the IP project.

10.1.8 Virtual Ship Agent


User Group Spanish Ports are “Demo Users” of this module. The Valencia Maritime Agents Association (ANV) is to co-ordinate a work session with some of its members to show the application and to get feedback.

Port of Valencia, Port of Bilbao, Port of Barcelona, Port of Algeciras and Port of Lisbon are the main "demo users".


Contact has been done with the ANV and the instructions to use the application have been given to them.


The functionality satisfies the users who have already used the application.

Italy


User Group Fratelli Cosulich: a Limited Company incorporated in Trieste with branch offices and activities in Genova, Trieste, Napoli, Milano, Livorno, Ravenna, Venezia, Zurigo, Hong Kong, Singapore, Malta, Manila. The Company has interests and activities in the fields of Tramp and Liner Agency, Ship Management, Manning, Surveys, Travels, Cruises, etc.

Sistema Srl: The company, linked to the Tripcovich group, carries out intensive ship and forwarding agency activities. They are related to remote correspondents in foreign European Countries. Sistema Srl will give a response on our invitation to join IP project User Group on the first half of July.

Saimare SpA: has been providing assistance to ships




and crew since 1924. In 1989 control of the company was acquired by the Spinelli Group, a leading transportation and logistic operator based in Italy. Other Saimare shareholders include key maritime and logistic sector operators and the company management. The company ownership structure and ongoing investments in technological and human resources put Saimare in the position to act as an efficient and reliable partner Italian and International logistic markets. Saimare handles operations in Italian key ports. In addition to head office in Genoa the company has branch offices in La Spezia, Naples/Salerno. with two subsidiary companies operating out of Livorno and Gioia Tauro.

The Genova Port Harbour Master Office (Capitaneria di Porto/Guardia Costiera): it enforces all regulatory and authoritative issues related to navigation safety, vessel traffic control and dangerous goods traffic control. The HMO takes care of sea patrolling for environmental protection purposes, persons and vessel rescue, administrative patrolling, waterborne dangerous goods traffic control and port traffic control.

The HMO is improving its IT resources and is boosting digital procedures which avoid persons and paper to move around. The HMO is equipped with specific software applications that, through full telematic connections, merge various sources of information on a common platform: port layout, vessels berthed, vessels anchored offshore and related administrative / authoritative / planning procedures and status are accessible anytime and can be tracked through their evolution.

The HMO is connected to the Cargo Community System of the port and regularly receives digital documents from the ship operators. In the near future the technological development process will even be pushed further.

ALFASPED, Avandero, Cerisola, DMCO, DETHOMAT, Eurservi, Express, ISCOTRA, Itsw, Ittrans, LOGISTIC, MCS, MEDMAR, Nardi, OTIM, HAPAG, Hugotrumpy, ICS, Sda, OVERSEAS, Provera, SCHENKER, Costa Container Lines, CostaMar, Calmedia, Fanfani, I/CGM SUD, Berge




CostaMar, Calmedia, Fanfani, I/CGM SUD, Berge Maritima, CMA CGM Italy


Formation of new user group in the Port of Cagliari and Port of Leghorn

Testing and sperimenting DG IP service in:

• Line Valencia – Genoa – Livorno

(Start of Demostration: September 2001)

• Port Communities System of Genoa

(Start of Demostration: june 2001)


Users involved hope all their European partners will adopt the DG IP service, to maximize the advantages (all partners simply exchange information on DG by interoperating existing systems with the new proposed solution) and to minimise the disadvantage (overhead to use a new system).

Documents

EUROPEAN COMMISSION – DG-TREN Euromar EEIG Intermodal ... · IP Consortium thIP Final Report v5 06052002 May 6 , 2002 3 VERSION HISTORY Version Date of creation Status Author Changes/Comments