TENDER SPECIFICATIONS ATTACHED TO THE INVITATION TO TENDER

Transcription

1 TENDER SPECIFICATIONS ATTACHED TO THE INVITATION TO TENDER Invitation to tender No: EMSA OP/06/05 concerning a Study on the development of Real Time Data Exchange Information Systems (RTDEIS) 1. Introduction 1.1 General The European Maritime Safety Agency (EMSA) was established under Regulation (EC) No.1406/2002 for the purpose of ensuring a high, uniform and effective level of maritime safety and prevention of pollution by ships. The Vessel Traffic Services (VTSs) are the basic tool to monitor maritime traffic. The incorporation of the Automatic Identification System (AIS), compulsory after the 31st of December 2004 on board all passengers vessels and cargo ships over 300 gross tonnage on international voyages, will enhance safety of navigation, protection of the environment, Search and Rescue (SAR) operations, investigations of marine accidents, security, control of illegal immigration and smuggling, and finally the overall efficiency of traffic. However, to get an overall picture of traffic, to be able to forecast the dangers and the risks, to be in a position to know the situation outside the areas of responsibility of VTSs and to carry out risk analysis, it would be necessary to implement Real Time Data Exchange Information Systems (RTDEIS) for the main E.U. areas. The Member States 1 have developed a sufficient number of Vessel Traffic Services (VTS), Maritime Reporting Systems (MRS) and Automatic Identification Systems (AIS) and they plan to implement major additional infrastructure (mainly AIS networks) before the end of On 27 and 28 January 2005, EMSA organised a workshop 2 to review issues related to the traffic monitoring infrastructure of the Member States and to discuss with the Member States the feasibility of establishing RTDEIS. One of the conclusions of the workshop was: Certain Member States have already taken initiatives and defined the specific framework for the data exchange between their national traffic monitoring systems by adopting commonly accepted technical solutions and practices (Baltic and North Sea). The workshop supported the concept of developing the regional traffic monitoring centres in virtual mode (national centres sharing the same traffic image without creating a physical central centre ). Some of the benefits of the concept are : a. The full real traffic image of all vessels fitted with AIS and sailing in the selected area would be relayed between the coastal stations in real time mode. b. The Member States of the region will be able to elaborate on statistics on traffic entering and leaving a specific area and to identify general navigation patterns. This would enable proper risk assessment in specific areas, and help to improve the decision-making process regarding recommended safety of navigation measures. 1 For the purposes of this project the term Member States refers to all existing Member States of E.U. as well as to Norway and Iceland. 2 More information on the conclusions and the presentations of the Workshop are available at the Procurement section (sub section related to the present call for tender) of the EMSA web site. Page 1 of 21

2 The development of a physical centre needs to be further studied in regard to technical, financial and administrative implications. The study intended through this tender is a response to the interest of the Member States to promote the development or improvement of a traffic monitoring system infrastructure in the various E.U. areas and to comply with the requirements as laid down in various E.U. policy papers, Directives or Decisions. The study should help design Real Time Data Exchange Information Systems (RTDEIS) for the main E.U. areas. 1.2 Legislative background information White Paper on Common Transport Policy The Commission's White Paper on the development of a Common Transport Policy calls for optimum use to be made of existing capacities and for the integration of all networks relating to the various modes of transport in a trans-european network for the road, rail, inland waterway, sea and air transport of passengers and goods and for combined transport. The establishment and development of trans-european networks contribute to the attainment of major Community objectives, such as the smooth functioning of the internal market and the strengthening of economic and social cohesion Decision No 1692/96/EC of the European Parliament and of the Council of 23 July 1996 on Community guidelines for the development of the trans- European transport network The purpose of the Decision is to establish the guidelines covering the objectives, priorities and broad lines of measures envisaged in the area of the trans-european transport network. According to Article 5 of the Decision, the priorities envisaged in the area of the trans-european transport network shall be: a. establishment and development of the connections, key links and interconnections needed to eliminate bottlenecks, fill in missing sections and complete major routes; b. establishment and development of infrastructure for access to the network, making it possible to link island, landlocked and peripheral regions with the central regions of the Community; c. the optimum combination and integration of the various modes of transport; d. integration of environmental concerns into the design and development of the network; e. gradual achievement of interoperability of network components; f. optimization of the capacity and efficiency of existing infrastructure; g. establishment of and improvement in interconnection points and intermodal platforms; h. improved safety and network reliability; i. the development and establishment of systems for the management and control of network traffic and user information with a view to optimizing use of the infrastructures; j. studies contributing to improved design and better implementation of the trans- European transport network. In particular the trans-european shipping management and information network shall concern: coastal and port shipping management systems, vessel positioning systems, reporting systems for vessels transporting dangerous or polluting goods, communications systems for distress and safety at sea, so as to guarantee a high level of safety and efficiency of shipping and environmental protection in shipping zones belonging to Community Member States. Page 2 of 21

3 1.2.3 Directive 2002/59/EC of the European Parliament and the Council of 27 June 2002 establishing a Community vessel traffic monitoring and information system and repealing Council Directive 93/75/EC According to Article 9 paragraph 2 of the Directive 2002/59, Member States have to complete the process of building up all necessary equipment and shore-based installations by the end of Also Member States are to ensure that the appropriate equipment for relaying the information to, and exchanging it between, the national systems of Member States will be operational at the latest one year thereafter. To have the data from a number of stand alone AIS systems shared, it is technically recommended to have a central system that receives/distributes data from/to all of the parties involved. The study intended through this tender procedure is a response to the preamble (17) of the Directive 2002/59 whereby: Information management centres ought to be set up in the Community s maritime regions so as to facilitate the exchange or sharing of useful data in relation to traffic monitoring and the implementation of this Directive. 1.3 SafeSeaNet (SSN) During the Workshop of 27 and 28 January 2005, the Member States reaffirmed the importance of SafeSeaNet 3 (SSN) as a tool that should further facilitate data exchange between the Member States. Any new systems (such as the regional traffic monitoring systems) shall be fully compatible with the infrastructure developed in the SSN framework, which will remain the main tool for the exchange of maritime safety data between the Member States at E.U level. Within the framework of SSN the Member States decided to divide E.U. waters in five regions as follows : NS-CH BALTIC ATL MED-W MED-E Figure 1 Regional Traffic Monitoring Centres The description of the SSN regions is the following: 3 More information of the SafeSeaNet is available at the Procurement section (sub section related to the present call for tender) of the EMSA web site Page 3 of 21

4 Geographical Area Access Rights Baltic Denmark, Estonia, Finland, Germany, Latvia, Lithuania, Poland, Sweden, North Sea and Channel Atlantic Western Mediterranean Sea Eastern Mediterranean Sea European Union Belgium, Denmark, France, Germany, the Netherlands, Norway, Sweden, UK. France, Ireland, Portugal, Spain, UK, Malta. Italy, France Spain, Cyprus, Greece, Italy, Malta, Slovenia All Member States The above mentioned regions are not necessarily the areas where the RTDEIS will be developed. It is possible that the number and the borders of the areas should be modified. 1.4 Need for new real time data exchange systems Certain regions in EU waters are already planning or already developing a real time data exchange system. This technology has been deployed in the framework of the HELCOM Copenhagen declaration, whereby the Baltic Sates will cooperate to establish a common Baltic Sea monitoring system for maritime traffic based on AIS national data by 1 July Other Member States have not yet defined the system they intend to implement to be in compliance with the requirements of Article 9 of the above mentioned Directive. Therefore it is urgent to define and disseminate on time, a technical solution for the relaying of information between national systems in a proper and harmonised way. Considering the above, EMSA decided to step forward and, with the help of the study intended by this tender, promote the development of coherent new systems based on the principle of real time AIS data exchange between Member States situated in the same geographical area. These new systems should, as far as possible, use the infrastructure developed in the SSN framework; at least they should be complementary to SSN, which will remain the main tool for the exchange of non real time data between the Member States in all geographical regions. The development of these new real time systems is expected to create a great potential and to produce important operational and administrative benefits to the Member States and safety at sea such as: a. The full real traffic image of all vessels fitted with AIS and sailing in a selected area would be relayed between the coastal stations in real time mode. This feature would be of high value in the case of coordinated actions between Member States (e.g. incidents such as SAR, pollution, security etc.). b. The Member States of a given region would be able to elaborate on statistics on traffic entering and leaving a specific area (within the indicated passage lines) and to identify general navigation patterns. This would enable proper Formal Safety Assessments of the risks in specific areas, and help to improve the decision making process regarding recommended safety of navigation measures. Page 4 of 21

5 2. Contract objectives and scope of the study 2.1 Objectives The objectives of the study are: to develop a methodology, guidelines and examples for the development of RTDEIS network in technical, administrative, financial and legal aspects based on the conditions within participating countries; to prepare a specification for an appropriate system architecture at all relevant system levels; to design tools for enhanced network operations allowing for interoperability of individual local or regional solutions. Both virtual and physical mode RTDEIS shall be studied; to define the means to monitor the development of the network, to evaluate systems and services and to steer further development of the network towards an EU wide vessel traffic management and information system. Detailed information about the study requirements are given in section Phases of the study The project will be developed in four phases as follows: Phase one (expected to run from month 1 to month 5 of the contract): Detailed definition of the implications (technical, financial and administrative) of the development of the regional traffic monitoring centres) and stakeholder needs analysis Data collection Current situation in the E.U. The contractor shall study and assess the current status (technical, physical and organisational environment) in all of the Member States operating maritime traffic monitoring services, review current practices for VTS/ VTMIS 4 interoperability, and record technical and/ or organisational constraints/ financial organisational/ legal implications/ technical organisational interventions required in national traffic monitoring infrastructures. The contractor shall be given access to the returns of the questionnaires that EMSA sent to the Member States on 10/6/2004 whereby relevant information has been gathered. The contractor should also study and assess any existing common projects (or agreements for projects) between the Member States for connecting their national or local systems in order to exchange data Existing regional systems (e.g. Baltic and North sea) The contractor shall study the work achieved in the framework of the HELCOM Copenhagen Declaration. This work intended a common Baltic Sea monitoring system for maritime traffic based on national AIS data by 1 July 2005, including the technical specifications for this. Two basic components are needed for the implementation of the Baltic Sea monitoring system: the establishment of national networks in each Baltic Sea State and a decision on how to gain access to these national systems. To this end, the Baltic States tried to identify possible technical, economic or legal restraints in any of the Baltic Sea States that would impede the establishment of such a system. The AIS Working Group which was established in order to carry out this task, has taken due account of the work 4 The term VTMIS has different meanings; however for the purpose of the study, VTMIS is the task of networking existing information flows and traffic monitoring systems that allows the interoperability of individual local solutions. Page 5 of 21

6 carried out on this issue in other international fora, notably IMO, EU and IALA. In this the AIS Working Group noted that the establishment of land-based AIS monitoring systems and the exchange of AIS data between the Baltic Sea States is to be considered as a part of a bigger system, with the overall aim to ensure the safety of navigation in the Baltic Sea area. The contractor shall also study the work achieved in the framework of the Interreg III North Sea Programme and particularly the Safety at Sea project S). Some of the actions of the S project are related to the study under request. The contractor shall also record the relevant initiatives that have been undertaken in other areas between Member States at bilateral or regional level or between Member States and third countries. Any possible agreements between two or more Member States or between two or more Member States and third countries will also be studied and assessed Current practices in other modes of transport within the E.U. The contractor shall study and assess the current status of any real time data exchange information systems existing in other sectors of transport (such as railway, air or road transport) Relevant studies conducted in the E.U. The contractor should conduct a review of the relevant studies conducted under EU framework projects related to: VTS interoperability Integration of VTS into VTMIS Networks of VTS/ VTMIS exchanging information among the VTS of neighbouring countries The goal is to examine if and how these studies might be used to extract requirements for the RTDEIS network and contribute in the definition of the operational/ technical concept of the RTDEIS network Data analysis The contractor shall collect / analyse and present in a coherent way the requirements (e.g., tasks, processes, information flows, etc) in relation to the establishment of virtual and physical RTDEISs and translate them into Functional Specifications. The contractor has to clearly distinguish which of the requirements are already existing and expressed through projects or other relevant initiatives and which have been expressed during the process of the collection of data for the purpose of the study. The objectives of Functional Specifications are: Define data models used for the representation of information elements. Depict the entire logic of the system to be built through sequence diagrams. Define interactivity and information exchange with other external systems. Describe user interfaces (screen layouts) and reports content and layout. Define the test cases and a preliminary test plan for the system to be built. The activity of defining the Functional Specifications entails: Requirements Study and Analysis. The requirements produced in the context of the requirements definition activity will be studied and analysed. Sequence Diagrams Production. Sequence diagrams will be produced to depict the information system's internal flow. These diagrams will include the description of the basic flow of each function, the alternative flows, and the exception flows. High-Level Data Model Production. The Data Model of the system will be described by means of Entity Relationship Diagrams (ERD) including entities, relationships between them, and the main attributes used in transactional operations. Page 6 of 21

7 Production of Screen/Report Layouts. The sequence diagrams and data models will be complemented by user interface and report layouts that will provide a comprehensible means of depicting the look-and-feel of the application(s) to be produced. These layouts will act as an initial representation of the system and will be used as a reference point for the system development. Test Cases/Preliminary Test Plan Production. This regards the production of test scenarios/cases concerning the application(s) functionality, reliability, and performance. In addition to the test scenarios/cases, a preliminary test plan will be produced that will cover organisational aspects of testing, time-schedules, etc. This plan will be finalised in the context of the System Design activity, described further below. On the basis of the collected information and requirements, as well as the technological evolutions on the state of the art enabling the real time and/ or near real time 5 exchange of information, the contractor has to draw up one or more potential high level organisational models and technical approaches for each one 6 of the foreseen RTDEISs (refer to the figure 1). The contractor shall review and analyse as much as possible the associated costs and benefits 7 and record the relevant functional requirements. After the completion of phase 1, the contractor shall submit a draft report to EMSA, not later than five (5) months after the signature of the contract. Within ten (10) days after the submission, EMSA will give its comments. The final version of the report of phase one (which shall fully reflect EMSA s comments) is to be submitted ten (10) days thereafter. Phase two (expected to run from month 5 to month 7 of the contract): Development of draft guidelines / Experts review No1 After the completion of phase 1, the contractor shall prepare guidelines regarding the system s architecture and the complete set of functional specifications. The contractor should draft the possible alternative solutions and the priorities regarding the functions of the RTDEIS as well as a proposal for the proof of concept. By the end of phase 2, the contractor shall perform an expert review of the proposed approach (by presenting it, for approval, to the Member State representatives, the Commission and EMSA). A workshop shall be organised by EMSA in the city it is located with the objective to receive feedback from the Member States and to verify or adjust the proposed solutions according to the Member States feedback. The contractor shall participate and be responsible for drafting the agenda of the workshop (in cooperation with EMSA). He shall prepare the presentations as well as the supportive documentation that will be distributed to the workshop participants. All of the relevant documentation will be provided to EMSA in advance and will be put on the EMSA web site. After the completion of phase two, the contractor shall submit a draft interim report to EMSA, no later than seven (7) months after commencing the work. Within 10 days after the submission, EMSA will give its comments. The final Interim report that shall fully 5 Near real time exchange should be understood in the context of state of the art techniques such, for example, internet related technologies allowing the transmission of traffic image related information from location (A) to location (B) with a delay measured in a scale of 1-2 seconds. 6 It can be anticipated that the requirements from region to region may vary substantially so there could be a possibility that an organisational approach suitable for a region not to be compatible with a given situation in a different region. 7 The cost benefit analysis will be completed at the second phase when detailed system architecture will emerge. Page 7 of 21

8 reflect EMSA s comments is to be submitted 10 days thereafter. Only after the approval of the Interim report, may the contractor claim for the interim payment. Phase three (expected to run from month 7 to month 9 of the contract): Development of a system architecture corresponding to the agreed models for RTDEIS deployment in each region On the basis of the functional specifications - as indicated above - the contractor shall review the functional specifications and study/ propose detailed system architecture (physical, logical) for each one of the RTDEISs. In addition the contractor shall define the way of implementing the interactions with national traffic monitoring infrastructures, and the EMSA infrastructure (in particular to SafeSeaNet). The costs and benefits (potential socio-economic benefits/ impacts to maritime safety/ security/ environment) associated with the implementation of the each RTDEIS as well as the Pan-European RTDEIS network should be re-assessed at this stage. The document must include guidelines and recommendations on technical, organisatonal and legal measures that need to be undertaken at national level in order to enable interoperability with other Member States in both scenarios: a virtual model for RTDEIS organisation and with the physical RTDEIS node in the area. The required interventions at the level of EMSA s site should be also clearly identified in the report Proposal for Proof of concept (demonstration of the operation of RTDEIS in one of the regions) The contractor shall draw up the terms of reference for a pilot project that could be the object of a future separate contract to demonstrate the proposed solution and architecture. The contractor will have to propose more than one demonstration project that have to be based on the following alternative scenarios: a. Functional demonstration of the proposed solution should be set up to show how interoperability problems among national infrastructures could be addressed and how the proposed information exchange mechanism will function in practical terms. The goal of the demonstration is to identify potential problems and refine the architecture. The demo could be based on simulation and should not involve actual Member States systems. b. In close collaboration/ consultation with at least three Member States operating in European regions where one of the RTDEISs would likely be set. Phase four (expected to run from month 9 to month 10 of the contract): Experts review No 2 / Final report The contractor shall perform another expert review of the proposed approach (by presenting it to the Member State representatives, the relevant Commission services and EMSA). A workshop shall be organised, by EMSA (with the assistance of the contractor), with the objective to receive feedback from the Member States and to verify or adjust the proposed solutions according to the Member States, Commission s and EMSA services feedback. EMSA s and the contractor s responsibilities will be the same as defined in the second paragraph of paragraph The draft final report is to be submitted to EMSA no later than ten (10) months after contract signature. Within ten days after the submission of this draft final report, EMSA will provide the contractor with its comments on the draft final report. The final version of the final report, which shall fully reflect EMSA s comments, is to be submitted ten days thereafter. Page 8 of 21

9 3. Study Requirements 3.1 General The study should capture and record all of the essential details and information related to the organisational basis of the system. The following factors should be examined and relevant requirements should be extracted (for all layers of the system national/ regional/ EU-EMSA): Staff structure, management structure and IT policy of organisations participating in the RTDEIS network Communications structure Safety and security Assistance (e.g. on line help tools, manuals, training, etc) required Privacy Legal issues The proposed solutions will have to fully reflect the provisions of Decision No. 1692/96/EC, Directive 2002/59/EC and Regulation 1406/ The examination should be done in light of the specific role and mission in relation to traffic management and monitoring: EU Commission s services role (DG TREN and others following up policy implementation) EMSA s role (coordination, operational harmonization) Member States role (policy enforcement, traffic monitoring operations) The study should clearly identify the potential user groups involved in data exchange procedures as well as in the operation and maintenance of the RTDEIS related infrastructure at any level- national, regional, and EMSA. The system design will have to be adapted to the characteristics of each user group. The main goals of the users in interacting with/ using the system should be described. The associated duties and tasks, procedures and processes that these groups are involved in should be analysed in order to extract all those requirements affecting system design and deployment The study should make a proposal on countries / geographical areas/ sub-areas that should be grouped under a given regional RTDEIS. The areas indicated in the map have to be considered as indicative only. Therefore the study has to concentrate on the possible technical solutions for networking the national systems, and on indicating the alternative technologies and possibilities, and leave to the Member States and the Commission services the decision about the number and the boundaries of the sea areas that will be grouped into a regional RTDEIS The study should present the performance and the quality attributes of the system (i.e. the non functional requirements related to system design and system architecture, human/ machine interactions, applications, maintenance, availability, security, robustness, flexibility, scalability, expendability, etc) The study should clearly identify the functional requirements (as defined in paragraph 2.2.2) relevant to the technical environment of the system, including those referring to the system design & architecture, user workstations (hardware and software environment), configuration/ maintenance workstations (hardware and software environment), servers (hardware and software) and peripheral devices. Relevant technical constraints should be identified. Page 9 of 21

10 For any site candidate to host components of the system all those elements having an impact on system design choices, installation, operation or performance must be recorded, e.g. requirements relevant to: Thermal and atmospheric environment Auditory Environment Vibration or instability Visual Environment Space User posture Location, place of installation Health and Safety hazards related to system use Protective clothing and equipment Potential Standards or international/ local regulations relevant to the above The study should not make any proposal on the locations where the physical RTDEIS should be situated. 3.2 Specific study requirements relevant the international layer of the RTDEIS network (i.e. requirements specific to virtual or physical type of RTDEISs) The study team should thoroughly analyse the information flows and examine all of the procedures relevant to data collecting / processing / storing and displaying. All of the relevant attributes of the RTDEIS network need to be analysed, recorded and specified. Linking some areas and harmonising as much as possible existing information flows and systems can best further develop the RTDEIS. Such initiatives are in line and supportive of a pan European approach. The following items shall be addressed: a) Possible data types and messages (associated to AIS, VTS, SSN, MRS) b) Content of info according to the existing international and national regulations c) Types of ships participating in traffic monitoring schemes, types of reports and reporting obligations / procedures d) Definition of types of AIS binary messages 8 to be exchanged. In this respect must be noted that some Member States (or users) may wish to exchange more messages and data than other Member States/ users. Therefore the contractor should identify a minimum set as well as a maximum set of messages that could be exchanged. e) Update rates (min and max) Particular attention should be given to addressing for each one of the foreseen virtual (or alternatively physical ) nodes in the RTDEIS network the following: 1) Data processing techniques essential for handling duplicated info (i.e. data on the same target originated from different sensors and/ or different sources) 2) Synchronization method for traffic image data compiled from a number of sources 3) Backup / restore procedures 4) Database management 5) Traffic image replay 6) Presentation techniques (specification of GIS tools functionality, compatibility of electronic charts with the S57 standard, etc) 7) Data filtering criteria 8) Web interfaces of the system 8 AIS binary messages provide a variety of capabilities for pre-defined information packages. Recommendation ITU-R M specifies the technical characteristics and structure of the AIS binary messages. To avoid system overload, the number of binary messages should be limited. Page 10 of 21

11 9) RTDEIS Network Compatibility with E.U. network systems (e.g. TESTA 9 ) 10) Bandwidth requirements 11) Procedures and tools relevant to system administration / configuration and status monitoring (individual computers, network communications etc) a) Failure detection/ Alarms (operational, technical etc.)/ Fault Logging b) Definition of users access rights (who has rights to send or to receive data according to specific filters set, access system services via the web, etc.) c) System parameters setting 12) Network security policies a) Encryption b) User identification c) Firewalls d) Physical security 13) Procedures and tools relevant to system maintenance, technical support 14) Making available statistics on: a) System operations at regional, national and EMSA level such as : passage lines statistics : information about how many ships cross a passage line. The results should be divided into categories like passing direction, ship nationality, ship type etc. Historical tracks : historical tracks can be used to analyze how a set of ships have travelled density plot: generate geo graphs showing lines and traffic density b) System status (diagnostic statistics) Furthermore, particular attention should be given to capturing requirements and specifying the interfaces for real and/ or near real time data exchange and sharing: a) Between the RTDEIS centres of the network b) Between a given RTDEIS centre and the national traffic monitoring infrastructure of countries monitored by the RTDEIS c) Between each one of the RTDEIS centres and EMSA node 3.3 Specific study requirements relevant to the national layer of the RTDEIS network (i.e. associated with interventions to the national traffic monitoring infrastructure of the Member States) The potential introduction of RTDEISs imposes a number of interventions to the National Traffic Monitoring Infrastructure (NTMI) of the Member States: For instance intervention/ upgrades will be required in order to integrate the various national traffic monitoring tools (VTS, AIS, MRS) to compile a complete and full traffic image in order to be exchanged with other NTMIs/ RTDEISs/ EMSA The following should be taken into account (as these are closely related to the scope and the mission of the RTDEIS network): Data concerning maritime traffic (such as ship tracks, ship originated messages) available to the various NTMI components (originated from the currently disparate AIS, VTS, MRS, SSN national nodes) that need to be exchanged with other NTMIs/ RTDEISs/ EMSA Data available to EMSA (such as in SSN) or other databases such as Sirenac and Equasis. 9 TESTA (Trans-European Services for Telematics between Administrations) is a private network that gives public administrations access to modern telecommunication services for daily dealings with other public sector bodies across Europe. Its purpose is to provide European Institutions and Agencies, as well as administrations in the Member States, with a network infrastructure that ensures easy, reliable exchange of data efficiently and securely. Page 11 of 21

12 Other important traffic monitoring related information that should be made available to national/ interregional level such as ships routing systems It is expected that this study will present implications related to the above and will thoroughly record all the requirements imposing changes to the technical/ organisational/ physical environment of NTMIs with respect to the introduction of RTDEISs. Furthermore it is expected that the study will provide guidelines and recommendations on interventions required at technical level. In relation to the latter it is anticipated for instance that the study will recommend alternative technical solutions and suitable integrated network topologies (e.g. star, ring, etc) enabling the interoperability of systems that need to interact at national level and supply/ receive data from the RTDEIS network The study has to indicate the available technical solutions and best practices available to the Member States. The objective is to indicate the alternative options and to provide elements for consideration including cost to assist Member States to select the solution that should better fit to their own requirements, needs and policies. 3.4 Specific requirements relevant to the participation of EMSA into the RTDEIS network EMSA will participate in the RTDEIS network and share information with the RTDEISs. However EMSA s mission and operational aims and goals are different from those of the RTDEIS centres and / or national traffic monitoring authorities. The role of EMSA is described in Regulation 1406/2002. It is noted that EMSA does not involve itself in the operations of the Member States and should act mainly as an interface between the RTDEIS and the European Commission information network The study should address all of the following issues : capture requirements, specify solutions, propose an architecture and provide technical specifications for the EMSA node within the RTDEIS. Particular attention should be given, as in the case of the RTDEIS nodes, addressing the following: 1) Data processing techniques essential for handling duplicated info (i.e. data on the same target originated from different sensors and/ or different sources) 2) Synchronization method for traffic image data compiled from a number of sources 3) Backup / restore procedures 4) Database management 5) Traffic image replay 6) Presentation (specification of GIS tools functionality, compatibility of electronic charts with the S57 standard, etc) 7) Data filtering criteria 8) Web interfaces of the system 9) RTDEIS Network Compatibility with TESTA 10) Bandwidth requirements 11) Procedures and tools relevant to system administration / configuration and status monitoring (individual computers, network communications etc) a) Failure detection/ Alarms (operational, technical etc.)/ Fault Logging b) Definition of users access rights (who has rights to send or to receive data according to specific filters set, access system services via the web, etc.) c) System parameters setting 12) Network security policies a) Encryption 10 According to the definition of Article 3 paragraph (p) of the Directive 2002/59 ships routing systems means any system of one or more routes or routing measures aimed at reducing the risk of casualties: it includes traffic separation schemes, two-way routes, recommended tracks, areas to be avoided, inshore traffic zones, roundabouts, precautionary areas and deep-water routes. Page 12 of 21

13 b) User identification c) Firewalls d) Physical security 13) Procedures and tools relevant to system maintenance, technical support 14) Making available statistics on: a) System operations (passage lines statistics, density plot etc.) at regional, national and E.U. level) b) Data quality (how data quality evolves over time, workload, etc) c) System status (diagnostic statistics) 3.5 Specific issues that need to be addressed and other requirements of the study The study should analyse the following issues and propose solutions/ make recommendations: Operational concept for Long Range Identification and Tracking (LRIT) units / Possibility for integrating LRIT in the RTDEIS network The objective of the LRIT function is to collect information for identifying a ship and tracking it (position and time position) in a long-range area. The existing Tracking Service collecting the data from Satellite Service Providers will furnish LRIT services. The LRIT information will be supplied to a Contracting government entitled to receive it by a LRIT Data Centre. The overall system would be under the oversight of a LRIT coordinator acting on behalf the IMO responsibility. It is possible to have several LRIT Data Centres disseminated over the world and connected to a list of countries. The functional requirements of the LRIT DC have already been defined. The main task will be to act as a Mission Control Centre in charge of maintaining databases and connections with the Contracting Governments. The implementation and the location of a European LRIT DC have to be fixed, may be in the context of the development of the RTDEIS for which EMSA is responsible. The SafeSeaNet network should play a role for supporting the interchange of LRIT data between the E.U. Member States Whether it is feasible to put RTDEIS network under SSN umbrella SSN is a system that enables the data to be exchanged between the Member States in non real time mode. However SSN has to be considered as the tool that should further facilitate data exchange between the Member States. The RTDEIS shall be fully compatible with the infrastructure developed in the SSN framework, which should remain the main tool for the exchange of maritime safety data between the Member States at E.U level How RTDEIS could contribute to reducing the reporting obligation of ships masters The continuous development of new vessel traffic reporting systems in many E.U. areas has resulted in the increasing need for vessels to repeat the same reports many times as they sail through the different E.U. sea areas. Some E.U. Chambers of Shipping are very concerned that vessels which are in (e.g.) the WETREP system and then go into the CALDOVREP system may have to send another report rather than relying on the two systems to transfer date from one system to another. The study should investigate how this situation could be remedied by the introduction of the RTDEIS. Page 13 of 21

14 4. Contract and project implementation structure 4.1 EMSA The European Maritime Safety Agency Unit E1, in charge of Technical Co-operation and Development / Ship Reporting will be responsible for managing the contract. EMSA is currently based in Brussels, Belgium but will be relocated to Lisbon, Portugal. Bids should consider the 1 st of April 2006 as the estimated date for the relocation. The Contractor will in any case receive at least three months notice regarding the relocation in order to adapt his working arrangements to the new location of EMSA. 4.2 Tenderer The tenderer has to specify in his bid the team which will be responsible for managing the contract. Full details of the project management team members (project manager, technical project co-ordinator, horizontal activity leader, work package leaders etc.) as well as their responsibilities should be defined. The tenderers will include into their bids detailed information regarding the project implementation structure (each work package should be clearly defined) and methodology. The project implementation structure will include (as a minimum) the following: Quality control Guidelines for quality control and quality assurance and the monitoring responsibilities should be defined in the bids. The contractor shall perform the study and provide the products in accordance with technical norms, standards and procedures based on best professional practice Work package description and relations A total overview should be given on the man-days and the cost for each work package. The relations between the work packages should be defined. During the project implementation, EMSA will have the right to reallocate the offered man-days between the various tasks, should this be necessary due to the real needs of the project. 4.3 Project planning and deliverables The project should respect the following planning: Signature of the contract estimated date: 1st December Kick-off meeting following the signature of the contract (within two weeks) Report of phase one within 5 months after the signature of the Contract by the last contracting part (as defined in paragraph ). Experts review 1 - within 7 months after the signature of the Contract by the last contracting part (as defined in paragraph ). Interim report (after the completion of phase 2) within 7 months after the signature of the Contract by the last contracting part (as defined in paragraph ). After its acceptance the contractor may claim for the interim payment. Report of phase three within 9 months after the signature of the Contract by the last contracting part (as defined in paragraph ). Report of phase four (including experts review 2 within 10 months after the signature of the Contract by the last contracting part (as defined in paragraph ). Final report - has to be submitted as defined in paragraph Additional interim meeting if deemed necessary (as defined in paragraph ) Page 14 of 21

15 All deliverables shall be in English Kick-off meeting The work shall start from the signature of the contract. Shortly after the signature of the contract (within two weeks maximum) a kick-off meeting will be held in Brussels in order to define the details of the work to be undertaken. During the kick-off meeting, EMSA will provide to the contractor all of the relevant information collected through the returns of the questionnaires that EMSA sent to the Member States (see paragraph ) D1: (Phase one). Data collection / analysis The report of phase one should make reference to all of the issues identified under the objectives of paragraphs and in the previous section. It is expected to be delivered by month D2: (Phase two): Development of draft guidelines / Experts review No1 The interim report shall make reference to all of the issues identified under the objective of paragraph It is expected to be delivered by month 7. The proceedings of the workshop organized for the expert review of the approach shall be annexed to the report D3: (Phase three): Development of a system architecture corresponding to the agreed models for RTDEIS deployment in each region) / Proposal for Proof of concept (demonstration of the operation of RTDEIS in one of the regions) The report of phase three is related to the objectives of paragraphs and It is expected to be delivered by month 9. The report should outline the configuration of the demonstration and detail the scenarios to be used for the demonstration D4: (Phase four): Experts review No 2 / Final report The report of phase four is related to all objectives as well as to the project management procedures. It is expected to be delivered by month 10. In addition the proceedings of the workshop organized for the expert review of the approach should be annexed to the report. It will provide a summary of the activities conducted and will include a summary of the main achievements and recommendations of the study. In case that the activities under phase three (3) of the project will impose a refinement of the system architecture document, an updated version of D3 must be annexed to the report. The draft final report is to be submitted to EMSA no later than ten (10) months after commencing the work. Within ten days after the submission of this draft final report, EMSA will provide the contractor with its comments on the draft final report. The final version of the final report, which shall fully reflect EMSA s comments, is to be submitted ten days thereafter Additional interim meeting EMSA may call for additional meetings if this should be considered necessary for the better execution of the project. These meetings will enable the contracting parties to discuss the work accomplished. The contractor will have to take fully into consideration any suggestion made by the Agency. Subject to the contract needs, the contracting parties may shift the time when these meeting will be held. Should additional meetings (other than the ones listed under 4.3) be necessary, EMSA will reimburse relating expenses for such additional meetings in accordance with the provisions of the Contract. Page 15 of 21

16 5. Description of the expert s team experts responsibilities and project management structure and methodology 5.1. Tenderers shall explain in their bids the project management structure and practices to assure timely execution of the work and high quality of the deliverables. 5.2 The bid should include at minimum the following details on the workplan: Workbreakdown structure (at minimum a two level breakdown is required: workpackage / task level with indication of activities to be executed under each task) Workpackage / task descriptions (objectives/ methods of conducting the work/ activities per task/ duration of workpackage/ resources allocated (person-days) in each task / experts involved in each task/ clear indication of the contributions to the task/ workpackage to the deliverables of the study Gant chart PERT chart 5.3. Full details of the project team members (project manager, technical project coordinator, work package leaders etc.) as well as their responsibilities should be provided with the quotation. The tenderers should include in their bids adequate information clarifying: The specific expertise of each expert justifying his (her) participation in a specific task of the workplan. The person-days allocation of each expert in the individual tasks in the proposed workplan. 5.4 Tenderers should provide with their bids a detailed curriculum vitae of each staff member responsible for carrying out the work, including his or her educational background, degrees and diplomas, professional experience, research work, publications and linguistic skills. The CVs shall be presented, preferably, in accordance with the Agency Recommendation on a common European format for curricula vitae, published in OJ L79 of 22 March 2002, p. 66 ( Guidelines for quality control, quality assurance, and monitoring responsibilities shall be defined in the bids. The contractor shall perform the services and provide the products in accordance with technical norms, standards and procedures based on best professional practice in the informatics field, and in particular with the ISO 9000 standards. 5.6 The following shall be considered as minimum requirements for the successful bidder: Provision of a project and financial planning manual: this will include in general terms the organisation and Work Packages (W.P.) tasks definition, who does what and when, internal communications and relations, progress and cost-reporting guidelines, budget planning and control. It will also include documentation standards. Provision of a quality control manual: The quality control manual will specify: o Quality control & assurance procedures for the execution of the work and the production of deliverables o o o Quality requirements on deliverables, publications and dissemination of results Responsibilities of partners/ experts, work package leaders, technical coordinators, Quality manager and Project management in the Quality control & assurance processes The minimum requirements for reports, including requirements on summaries, and other deliverables, scheduling of meetings, and communication Page 16 of 21

17 procedures to guarantee fluent administrative and financial agreements with the EC Detailed project planning, Assessment and review reports; Progress reports and cost statements. In addition to the reports required in paragraph 4.3, consolidated progress reports will be provided (every 2 months); The contractor will be asked to report on the technical aspects discussed at the meetings relevant to the study that he will attend. Final reports: the project will be concluded with a Final Report as indicated in paragraph The tenderer should provide in the bids detailed description regarding the above requirements. 6. Estimate of the budget The budget of the project is Euros. 7. Terms of payment Payments shall be issued in accordance to the provisions of the draft contract available on the Procurement Section on the EMSA website at the following address: 8. Terms of contract In drawing up his bid, the tenderer should bear in mind the terms of the draft contract attached to this invitation to tender. The European Maritime Safety Agency (EMSA) may, before the contract is signed, either abandon the procurement or cancel the award procedure without the tenderers being entitled to claim any compensation. 9. Financial guarantees The selected bidder will have to provide a financial guarantee in the form of a bank guarantee or equivalent supplied by a bank or an authorised financial institution equal to the amount of the pre-financing (30% of the total amount of the contract). 10. Sub contracting If tenders intend to either sub contract part of the work or realise the work in cooperation with another partner they should indicate in their offer which part will be subcontracted, as well as the name and qualifications of the subcontractor or partner. (NB: overall responsibility for the work remains with the tenderer). 11. Requirements as to the tender Bids can be submitted in any of the official languages of the EU. The working language of the Agency is English. Bids must include an English version of the documents/information requested under point 14.5 and 15.1 of the present tender specifications. The tender must be presented as follows and must include: Part A: including all the information and documents required by the contracting authority for the appraisal of tenders on the basis of the Selection/Exclusion criteria set out under points 13 to 14.4 of these specifications; Page 17 of 21