Invitation to tender No. EMSA/OP/06/08 concerning contracts for Delivery of ASP / CSP Services for the EU LRIT Data Centre

Transcription

1 TENDER ENCLOSURE I - TENDER SPECIFICATIONS ATTACHED TO THE INVITATION TO TENDER Invitation to tender No. EMSA/OP/06/08 concerning contracts for Delivery of ASP / CSP Services for the EU LRIT Data Centre Table of contents 1. Background and LRIT system components Background The IMO requirements Overall international LRIT framework and system components General provisions LRIT Co-ordination Obligations of the parties LRIT Data Distribution Plan THE EU LRIT SYSTEM architecture for the EU LRIT SYSTEM The shipborne equipment, CSP and ASP EU LRIT Ship Database Register EU LRIT Data Centre and EMSA Monitoring Interface Invoicing and Billing System Contract objective and service overview ASP/CSP operation Vessel to EU DC ASP/CSP operation EU DC to vessel Data messages types LRIT messages Type 1, 2, 3 ship position reports LRIT messages Type 4 and 5 Request Messages For Message Type 7 - Receipt messages Information/Exception Message (type 101): ASP System Status message (type 102) Ship Check/Reset Request message (type 103) Ship Database Update Notification message (type 104) Ship Database Update Request message (type 105) Ship Database Update Response message (type 106) Requirements: ASP/CSP operation Requirements imposed by IMO System performance Latency times Network coverage Journaling / Billing information LRIT messages Non default operation Polling of information Communication between ASP and EU LRIT Data Centre Messages Page 1 of 92 06/06/2008 Tender Specifications ASP v1.doc

2 Communication Interface Security integration of vessels in the system Ship database issues Content and formats of the Ship database Vessel integration Hosting Type Approval testing of shipborne equipment Quality Assurance Contract management responsible body Timetable Project Planning / Documents to be submitted Budgeted amount Terms of payment Terms of contract Grouping of service providers Sub contracting Price Financial Guarantee Information of the service provider Legal position means of proof required Exclusion Criteria Grounds for exclusion Selection Criteria Economic and financial capacity means of proof required Technical and professional capacity - means of proof required Criteria for the award of contract (according to Article 4) Technical award criteria (50 points) Fulfilment of requirements (20 points) Quality of the system and quality assurance (10 points) Hosting and infrastructure (10 points) Management (10 points) Price award criteria (50 points) Contracts will not be awarded to tenderers under special circumstances Presentation of the bids to EMSA - Requirements as to the tender Prefix to the bid Part A Part B Part C Part D: False declarations by tenderers No commitment by the Agency Retention of tenders No reimbursement of tender expenses Information resources Annex A.1. Reference Documents Annex A.2. Abbreviations, acronyms and definitions Annex A.3. Data format of LRIT messages Annex A.4. Compliance Matrix - List of Technical Requirements Page 2 of 92

3 1. Background and LRIT system components 1.0. BACKGROUND The European Maritime Safety Agency (hereafter referred to as the Agency or EMSA ) was established under Regulation 1406/2002/EC for the purpose of ensuring a high, uniform and effective level of maritime safety Following the Council Resolution of 2 October 2007, EU Member States decided to establish an EU LRIT Data Centre (EU LRIT DC). According to the Council Resolution, the Commission is in charge of managing the EU LRIT DC, in cooperation with Member States, through the European Maritime Safety Agency (EMSA). The Agency, in particular, is in charge of the technical development, operation and maintenance of the EU LRIT DC. It also stresses that the objective of the EU LRIT DC should include maritime security, Search and Rescue (SAR), maritime safety and protection of the marine environment, taking into consideration respective developments within the IMO context The objective of the EU LRIT DC is the identification and tracking of EU Member States, Norwegian and Iceland flagged ships which will be integrated in the wider LRIT system on an international level. Furthermore, via the EU LRIT DC, the European coastal states can obtain LRIT information for all ships coming to their ports. The LRIT system will also contribute to the simplification of the mandatory reporting requested by Directive 2002/59 (Port Notification, Ship Notification MRS) and Regulation 725/2004on enhancing ship and port facility security. The possibility of collecting the EU ship data in a unique database will contribute to the quality of service for other applications like Port State Control (PSC), CleanSeaNet, SafeSeaNet, that need to have access to accurate ship data and will facilitate the provision of statistics for the benefit of the entire Community The Council Resolution of 2 October 2007 also indicates that provision should be made for the participation of the overseas countries and territories including considering further discussion on the financial consequences. Furthermore, Norway and Iceland, as members of the EEA, should also participate Annex A.1 summarises the various reference documents from the IMO and the EU that describe the relevant requirements and will be referred to throughout this document The IMO requirements On 19 May 2006, the International Maritime Organization (IMO) adopted Resolutions of the Marine Safety Committee MSC.202(81) and MSC.211(81) which states amendments to the International Convention of Safety of Life At Sea, 1974 (SOLAS) and introduces the timely establishment of the Long-Range Identification and Tracking system (LRIT) The objective of the LRIT system is the global identification and tracking of ships. The requirements concerning LRIT have been introduced into the International Page 3 of 92

4 Convention for the Safety of Life at Sea (SOLAS), 1974, Chapter V ( Safety of Navigation ), Regulation In accordance with Paragraph 8.1 of Regulation 19-1, Contracting Governments shall be able to receive long-range identification and tracking information about ships for security and other purposes as agreed by the Organization. Such other purposes would for instance include Search and Rescue (SAR), as explicitly mentioned in the new SOLAS provisions, as well as maritime safety in general and marine environment protection purposes as agreed by Resolution MSC.242(83) adopted on 12 October Furthermore, IMO also adopted on 19 May 2006, Resolution MSC.210(81) which establishes performance standards and functional requirements for the LRIT of ships. This states that the all LRIT Data Centres and the International LRIT Data Exchange should conform to functional requirements not inferior to those specified in the Annex to the Resolution. In addition, it states that Contracting Governments to the SOLAS Convention should ensure that shipborne systems and equipment used meet the requirements of this regulation V/19-1 of the SOLAS Convention. Few changes were made to the performance standards and functional requirements during the IMO 83 rd Meeting of the Maritime Safety Committee (MSC 83) on 3 to 11 October 2007 and the final form was approved during the IMO 84 th MSC meeting (MSC 84/WP.8/Add.2) on 7 to 16 May 2008 through the Resolution MSC 263(84) - Revised Performance standards and functional requirements for the long-range identification and tracking of ships At IMO MSC (82) in December 2006, it was decided that the LRIT data centres (national or regional) should be ready to integrate ships data as from the 1 st of July 2008 and not later than 1 st of October At IMO MSC (83) in October 2007 and at IMO MSC (84) in May 2008, Member States declared their firm intention for the establishment of their Data Centre (National, Regional or International by IMO) to ensure that 4 position messages per day are stored and available for those actors entitled to access the LRIT information. The final working international LRIT system should receive, store and disseminate LRIT information on behalf of all Contracting SOLAS Governments OVERALL INTERNATIONAL LRIT FRAMEWORK AND SYSTEM COMPONENTS General provisions The LRIT system and architecture is based on the performance standards stated in IMO Resolution MSC.263(84) (replacement of MSC.210(81)). The LRIT system receives, stores and disseminates LRIT information on behalf of all Contracting SOLAS Governments It consists of the following components: the shipborne LRIT information transmitting equipment, the Communication Service Provider(s) (CSP), the Application Service Provider(s) (ASP), the LRIT Data Centre(s), including any related Vessel Monitoring System(s), Page 4 of 92

5 the LRIT Data Distribution Plan (LRIT DDP) and the International LRIT Data Exchange (IDE) These components are shown in Figure 1 and how they link to each other and to the National and Regional Data Centres. The shipborne equipment first transmits the relevant LRIT data which includes the shipborne equipment identifier, positional data and the Time Stamp. The data flows from the vessels to the CSP s which provide services and link to the various parts of the LRIT system using communications protocols in order to ensure the end-to end secure transfer of the LRIT information The ASP also ensures that the LRIT information is collected and routed in a reliable and secure manner. Furthermore, and most importantly, the ASP should add dedicated data to each transmission of LRIT information (see also 3.1 for the ASP) Figure 1 below shows an overview of the LRIT components and the network connections between them. Other DC s Satellite CSP IDE Data Centre ASP ASP - Adding MMSI/IMO number to datagram Users Figure 1 INTERNATIONAL LRIT COMPONENTS Figure 2 provides an illustration of the International LRIT system architecture including the various LRIT components. The LRIT information will be provided to Contracting Governments and Search and Rescue services entitled to receive the data, upon request, through a system of national, regional, and co-operative LRIT data centres, using the LRIT International Data Exchange (IDE). The temporary LRIT International Data Exchange will be established and operated by the United States on a contingency basis. The IDE will route LRIT information between LRIT Data Centres. Page 5 of 92

6 The IMO will establish and maintain the LRIT Data Distribution Plan which will include a list of Contracting Governments and Search and Rescue services entitled to receive LRIT information and their contact details. Furthermore, they will also have information on the boundaries of geographic areas within each Contracting Government entitled to receive LRIT information, information on standing orders given by a Contracting Government and other information supplied by Administrations, etc. These are detailed further in the IMO Resolution MSC.263(84) (replacement of MSC.210(81)). Figure 2 LRIT SYSTEM ARCHITECTURE It is clear from the IMO Resolution MSC.263(84) (replacement of MSC.210(81)) that LRIT communications using land-line links should provide for data security methods such as authorization and authentication to ensure confidentiality and integrity. Lastly, the system performance should include LRIT information being available to an LRIT Data User within 15 minutes from the time it is transmitted by the ship and that on-demand LRIT information reports should be provided to an LRIT Data User within 30 minutes from the time the LRIT Data User requested the information. Furthermore there are certain requirements in terms of quality of service that need to be followed LRIT Co-ordination Certain aspects of the performance of the LRIT system are reviewed or audited by an LRIT Co-ordinator acting on behalf of all SOLAS Contracting Governments. Page 6 of 92

7 All Regional or Co-operative LRIT Data centres should automatically maintain journal(s) for all of the internally routed LRIT information and transmit these journals to the IDE at regular intervals. The performance of all LRIT Data Centres should be audited by the LRIT co-ordinator Obligations of the parties According to Resolution MSC.263(84) (replacement of MSC.210(81)) each Contracting Government should decide to which LRIT Data Centre ships entitled to fly its flag are required to transmit LRIT information. Each Administration should provide the selected LRIT Data Centre with the following information: the name of the ship, IMO number, call sign and Maritime Mobile Service Identity (MMSI), for each of the ships entitled to fly its flag which is required to transmit information Upon the transfer of the flag of a ship which is required to transmit LRIT information to another State, the Administration whose flag the ship is now entitled to fly should provide without undue delay to the selected LRIT Data Centre in addition to the information mentioned: the effective date and time (UTC) of transfer; and the State whose flag the ship was formally entitled to fly, if known The Contracting Governments will also update the LRIT Data Centre when there are any changes to the above mentioned information Each Contracting Government should obtain the LRIT information to which it is entitled to under the provisions of SOLAS regulation V/19-1, and has requested, from the designated LRIT Data Centre. Each Contracting Government should indicate to the LRIT Data Centre the criteria for receiving such LRIT information, according to the Data Distribution Plan (DDP) managed by the IMO LRIT Data Distribution Plan The International Maritime Organization (IMO) establishes and maintains the LRIT Data Distribution Plan (DDP). According to Resolution MSC.263(84) (replacement of MSC.210(81)) the LRIT Data Distribution Plan includes: 1. a list of Contracting Governments and Search and Rescue services entitled to receive LRIT information, and their points of contact; 2. information on the boundaries of geographic areas within which each Contracting Government is entitled to receive LRIT information about ships in the area; 3. information on any standing orders given by a Contracting Government; 4. information supplied by Administrations on the boundaries of geographic territorial sea; 5. information supplied by Administrations pursuant to the list of Contracting Governments to which the LRIT information should not be provided; Page 7 of 92

8 6. a list of ports and port facilities together with the associated geographic coordinates (based on WGS 84 datum) located within the territory of each Contracting Government; 7. a list of the National, Regional, Co-operative and International LRIT Data Centre(s) and their points of contact; and 8. a record indicating which LRIT Data Centre is collecting and archiving LRIT information for each of the Contracting Governments The DDP will therefore be populated by the Contracting Governments with the IMO managing it. The DDP will be made available by IMO to the EU LRIT Data Centre. All LRIT communications using land-line links should comply for data security purposes with requirements such as authorization, authentication, confidentiality and integrity. 2. THE EU LRIT SYSTEM 2.0. ARCHITECTURE FOR THE EU LRIT SYSTEM The proposed system architecture and general links between the EU LRIT Data Centre and other components of the system such as the links with the IDE, DDP, and EU LRIT Ship database are shown in Figure 3. Page 8 of 92

9 Position Report National ships register GMDSS databases CSP - Complete position report with MMSI/IMO# - Execute remote configuration Other Data Centres LRIT Request EU LRIT Ship Database EU LRIT Ship database interface EU LRIT Ship Database EU LRIT Data Centre ASP Interface M e s s a g e LRIT User Interface P r o c e s s n g DDP Interface IDE a n d A r c h v n g Interface Page 9 of 92 Monitoring Interface Monitoring Interface EMSA Billing EMSA ABAC i i i Invoice Information Ship owner Remote configuation Remote configuation Position Report ASP Flag State / Port State Coastal State / SAR MS NCA, MRCC Request/Poll LRIT data via SafeSeaNet National Authorities IMO DDP Server LRIT Request IDE List of LRIT Ships Remote Configuation Position Reports DDP STIRES Interface Billing Interface Journal LRIT Data Centre interface EMSA Monitoring Interface MI Operator Administration Quality of Service Quality of Data STIRES LRIT Messages Billing Processes Monitor/Administer Ship Database Monitor/Administer Data Centre Add/Update LRIT Ship Journal DC/ASP Interface Ship Database Interface STIRES Give access to shipborne equipment ID Remote configuation Position Report Update DDP Figure 3 EU LRIT System Architecture

10 The shipborne equipment, CSP and ASP An LRIT message is transmitted from the ship via its shipborne equipment which includes the shipborne equipment identifier, positional data and the time stamp. This is transmitted via a satellite through the Communication Service Provider (CSP) to the Application Service Provider (ASP) The ASP then provides the EU LRIT Data Centre with the complete LRIT information by adding the MMSI, IMO number, Name of ship and several timestamps to the datagram. This is then passed to the EU LRIT Data Centre. All of these links are made using communication protocols in order to ensure the end-to end secure transfer of the LRIT information The Agency through this invitation to tender EMSA/OP/06/08 plans to outsource the ASP function. Existing commercial Application Service Providers are in the most suitable position to relay with different Communication Service Providers to receive the ship positioning information communicated by satellite to the EU LRIT Data Centre. Although it is predictable most ships will use their INMARSAT C existing standard, the overall system must also be able to receive and process information using other communication systems compliant with the LRIT performance standards and functional requirements (e.g. IRIDIUM, INMARSAT D+, etc ). This means that the shipborne equipment should transmit the LRIT information using a communication system which provides coverage in all areas where the ship operates EU LRIT Ship Database Register An EU Ship Database Register will be compiled, based upon the information and subsequent updates which will be provided directly by EU Member States as Flag States, in accordance with IMO Resolution A.887(21) concerning the registration databases for the GMDSS. The European Member States (EU MS) will have direct access to populate the database via the SSN interface. Only Member States/Flag States can define which ships are obliged to report to the EU LRIT Data Centre. This register will have to be regularly (daily) updated by the competent Flag State administrations and will enable the ASP to transmit only the ship information relevant to the EU LRIT DC EU LRIT Data Centre and EMSA Monitoring Interface Through a second tender EMSA/OP/07/08 the Agency will contract the service providing the EU LRIT Data Centre functionalities and the monitoring capabilities. The Agency will have a monitoring interface to supervise the quality of the service and data within the EU LRIT Data Centre. Besides transmitting and archiving LRIT reports, other functionalities and interfaces will have to be developed (interfaces with the ASP, IDE and DDP) under the scope of the EU LRIT Data Centre At system level, the main functions of the EU LRIT DC are to: Page 10 of 92

11 Collect, store and archive the LRIT reports provided by the ships instructed by their Administration (MS) to report to the EU DC Distribute the mandatory messages/day/ship in accordance with DDP requirements Provide on request an LRIT report through the IDE Request and process LRIT reports received from the IDE Provide on request the LRIT report to the EU end users Process the request received from the EU end users Comply with the communication protocols established by IMO Comply with the system security performance requirements Support the external interfaces to the DDP and IDE in compliance with IMO requirements Support the auditing process and maintain journals The EU LRIT DC in effect receives, stores, and disseminates LRIT information on behalf of all Member States as Flag States The list of Contracting Governments and Search and Rescue services registered with the EU LRIT Data Centre will be defined in the DDP (managed by IMO) and will contribute to determine the eligibility criteria for which governments and Search and Rescue centres are able to receive the LRIT messages. The EU LRIT Data Centre will have access to the DDP through the IMO Invoicing and Billing System In the EU Council Resolution of 2 October 2007, it was decided that overseas territories and third countries will be allowed to make use of the EU LRIT DC and receive LRIT messages. Costs will have to be covered by them or the requesting Flag States The EU LRIT DC therefore has to invoice in the following cases: Member States requesting more than 4 messages per vessel per day for EU flagged vessels; Overseas territories for using the services of the EU LRIT DC; Third countries for using the services of the EU LRIT DC. Depending on the final international regime: Member States will have to pay for LRIT messages received via the IDE from other LRIT Data Centres (non EU flagged vessels); The EU LRIT DC will receive income for messages of EU flagged vessels requested by other LRIT Data Centres via de IDE The EU LRIT DC will interface with an invoicing and billing system provided via EMSA to cover the financial needs of the EU LRIT system, including the following: Retrieving information on incoming and outgoing LRIT messages Page 11 of 92

12 Registering/labelling/tagging the LRIT information messages (senders and addressees) Producing a price message for the International Data Exchange (IDE) Producing financial journals (overviews) Providing information/statistics to verify incoming invoices (from the ASP and other Data Centres) Providing EMSA basic statistics per client for the purpose of creating invoices Providing information on the status of credits EMSA has with the ASP and the status of credits that Member States and other clients have with EMSA. 3. Contract objective and service overview The objective of the contract is to provide ASP/CSP services for the EU LRIT system, which will be based on the IMO LRIT specifications and will receive LRIT information from ships of EU Member States, Norway and Iceland, interested Overseas Territories and possibly Third Countries to be forwarded to the EU LRIT Data Centre The functional components are shown in Figure 4 and how they link to each other and to the EU LRIT Data Centre. The shipborne equipment first transmits the relevant LRIT data which includes the shipborne equipment identifier, positional data and the Time Stamp. The data flows from the vessels to the CSP s which provide services and link to the various parts of the LRIT system using communications protocols in order to ensure the end-to end secure transfer of the LRIT information. The ASP then provides the communication protocol interface between the CSP and the EU LRIT Data Centre to enable the following minimum functionalities: 1. remote integration of the shipborne equipment into an LRIT Data Centre; 2. configuration of shipborne equipment for transmission of LRIT information; 3. modification of the interval transmission of LRIT information; 4. suspension of transmission of LRIT information; 5. on demand transmission of LRIT information; and 6. automatic recovery and management of transmission of LRIT information. Page 12 of 92

13 Remote configuation (rep. rate, on/off) Datagram Remote configuation (rep. rate, on/off) Datagram Receiving shipborne ID, MMSI Receiving shipborne ID, MMSI Requesting shipborne ID Figure 4 Functional diagram of the ASP/CSP and EU LRIT DC interaction The ASP will be responsible for establishing the connections to the CSP, so that the Agency will only interface with the ASP for the purpose of this contract. The contract will also cover the airtime costs incurred due to communication with the vessels and associated with the mandatory reports EMSA asks the tenderers to consider the full LRIT system, when proposing their bids. This especially applies to all interface aspects as only matching interface mechanisms will allow an efficient service The LRIT system was first defined by the provisions of SOLAS chapter Regulation V regulation 19-1 specified in MSC.202(81) The LRIT system was technically specified by the IMO Maritime Safety Committee in Resolution MSC.210(81), amended and modified by Resolution MSC.254(83) which provides the Performance standards and functional requirements of the LRIT system. These resolutions have been replaced by Resolution MSC.263(84) adopted at the 84 th meeting of MSC These performance standards and functional requirements are detailed by the IMO Ad Hoc LRIT Working Group on Engineering Aspects of Long-Range Identification and Tracking of Ships document MSC 83/6/1, amended and modified by following sessions of the Ad Hoc LRIT Working Group (MSC 84/6/1/Add.1. The Technical specifications for the IDC, IDE, Communication, DDP and Billing were finally approved by the 84 th meeting of the MSC and are provided by IMO Circular MSC.1/Circ Page 13 of 92

14 The tenderer shall always take into account the most recent IMO specifications for drafting the bid, even if these specifications are published after the dispatch of this call for tender The definitions by IMO are amended by the requirements given in this document for the purpose of implementation of the EU LRIT co-operative System. In case of contradicting or new definitions coming out of the final MSC 84 documents (especially IMO Circular MSC.1/Circ.1257, IMO Circular MSC.1/Circ.1259 and Resolution MSC.263(84)), the tenderer is asked to highlight this in the bid and to provide a solution according to these new IMO specifications To achieve the best possible service the Agency wishes to encourage the Industry to be innovative in providing and offering a comprehensive service and welcomes any proposal that has been well thought out and complies with all IMO definitions and the requirements within this document The ASP has to act in support of the Service Contract for the EU LRIT Data Centre. The ASP contractor (the company awarded this tender) and the EU LRIT DC contractor (tender EMSA/OP/07/08) will have to coordinate and work together and to specify in detail the interfaces between them. The procedures and specifications will be drafted by the EU LRIT DC contractor and will be agreed between both contractors under the chair of the Agency Subject to the evaluation of the bids and of the prices offered for each of the satellite communication systems, EMSA will contract one ASP ASP/CSP OPERATION VESSEL TO EU DC Tracking of any applicable ship begins with LRIT positional data being transmitted from the shipborne equipment. The LRIT information transmitted includes the identification, the ship s GNSS position (based on the WGS 84 datum), date and time associated with the GNSS position, as described in paragraph 1 and table 1 of Resolution MSC.263(84) (replacement of MSC.210(81)). The shipborne equipment will be capable of automatically transmitting, without human intervention on board the ship, the ship s LRIT information at 6-hour intervals to an LRIT Data Centre per default. If requested, the update rate might be reduced down to 15 minutes The LRIT information content of the vessel shipborne equipment is given in Table 1 below. Page 14 of 92

15 Parameter Comments Shipborne equipment Identifier The identifier used by the shipborne equipment. Positional Data The GNSS position (latitude and longitude) of the ship (based on the WGS 84 datum). Position: The equipment should be capable of transmitting the GNSS position (latitude and longitude) of the ship (based on WGS 84 datum) as prescribed by SOLAS regulation V/19-1, without human interaction on board the ship. On-demand (1) ) position reports: The equipment should be capable of responding to a request to transmit LRIT information on demand without human interaction onboard the ship, irrespective of where the ship is located. Positional data Pre-scheduled (2) position reports: The equipment should be capable of being remotely configured to transmit LRIT information at intervals ranging from a minimum of 15 minutes to periods of 6 hours to the LRIT Data Centre, irrespective of where the ship is located and without human interaction on board the ship. Time Stamp 1 The date and time (3) associated with the GNSS position. The equipment should be capable of transmitting the time (3) associated with the GNSS position with each transmission of LRIT information. Notes: (1) On-demand position reports means transmission of LRIT information as a result of either receipt of polling command or of remote configuration of the equipment so as to transmit at intervals other than the preset ones. (2) Pre-scheduled position reports means transmission of LRIT information at the preset transmit intervals. The default value for the preset transmit interval is 6 hours. (3) All times should be indicated as Universal Co-ordinated Time (UTC). Table 1 Data to be transmitted from the shipborne equipment The CSP provides the communication infrastructure and services that are necessary for establishing a communication path between the ship and the ASP. The LRIT information transmitted from the ship will travel across the communication path set up by the CSP to the ASP The ASP, after receiving the LRIT information from the ship via the CSP, will parse the incoming messages by reading and/or editing only the data relevant for its service and will add additional information to the LRIT message The ASP should add the following data to each transmission of LRIT information from a ship (Table 2): Page 15 of 92

16 Parameter Comments Ship Identity (1) Name of Ship (3) Time stamp 2 Time stamp 3 EU LRIT DC Identifier The IMO ship identification number (1) and MMSI for the ship. Name of Ship which has transmitted the LRIT information in roman letters using UTF -8 encoding The date and time (2) the position report is received by the ASP. The date and time (2) the position report is forwarded from the ASP to EU DC. The identity of the EU DC as indicated by the allocated Unique Identifier. Notes: (1) See regulation XI-1/3 and Assembly Resolution A.600(15) on IMO ship identification number scheme. (2) All times should be indicated as Universal Co-ordinated Time (UTC). (3) The delivery of this parameter was proposed by the LRIT AdHov Working group and is expected to be confirmed at the MSC 84 Table 2 Data added by ASP The new, expanded message containing integrated data transmitted by the shipborne equipment and data added by the ASP is then transmitted to the EU LRIT DC for further processing and distribution The ASP ensures that the LRIT information is collected and routed in a reliable and secure manner Finally the EU LRIT Data Centre will store all incoming LRIT information from ships instructed by their Flag State administrations to transmit LRIT information and will disseminate this information to LRIT Data Users according to the Data Distribution Plan (DDP). This is beyond the scope of this tender and is addressed in the EMSA tender EMSA/OP/07/08 regarding the EU LRIT Data Centre ASP/CSP OPERATION EU DC TO VESSEL The functionality required for the programming and transfer of commands to the shipborne equipment is provided by the ASP All remote configuration activities are limited to the LRIT data operations. They do not include any basic configuration of shipborne equipment The ASP shall 1. process the LRIT position request message from the LRIT DC which might be a poll or change of periodic rate, including start and stop request; 2. process LRIT position request messages based on the value of the request duration parameter. Page 16 of 92

17 3.3. Data messages types Table 3 below provides a summary of all IMO defined LRIT messages. Some of these messages are used as is or slightly adapted for the communication between ASP and EU DC. New message types will be used for specific functions For the ASP/CSP operations only the message types 1 to 5 and 7 are relevant as the other message types solely apply to the DC, IDE and final Data users, to which the ASP has no direct link. The message types not relevant for the ASP/CSP operations are greyed out and are listed only for information purposes The definitions for the message types 1 to 5 and 7 are based on the initial draft from the Ad Hoc Working Group on Engineering Aspects of Long-Range Identification and Tracking of Ships, MSC 83/6/1. These definitions will be updated by IMO Circular MSC.1/Circ.1259 which is expected to be published in June Page 17 of 92

18 Message Type Message Name Message Description Direction LRIT Positional Data (position report) Messages 1 Periodic Position Report Regular periodic ship position report ASP -> DC 2 Polled Position Report Ship position report as a result of a poll request. 3 SAR Position Report Ship position report as a result of a SAR request. ASP -> DC ASP -> DC LRIT Request Messages LRIT Ship Position Request Messages 4 Ship Position Request Request for polled ship position report. DC -> ASP 5 SAR Poll Request SAR request for poll of specific ship s position. DC -> ASP LRIT SAR SURPIC Request Message 6 SAR SURPIC Request SAR request for poll of ships in specific area. Other Messages 7 Receipt Receipt message relaying inability to respond to a LRIT request or report message. ASP -> DC and DC -> ASP 8 DDP Notification Notification that an updated version of the DDP file is available. 9 DDP Request Request for current copy of the DDP or incremental copy. 10 DDP Update Updated DDP (full or partial). 11 System Status Routine 30-minute status message from the IDE to each Data Centre (or vice versa), advising that the system is healthy. 12 R/CDC issued Billing and transaction Report Routine monthly report generated by a R/CDC or the IDC and sent to the IDE.* 13 Pricing Notification Notification that a new pricing list for between DC charges is in place. 14 Pricing Request Request for updated pricing list 15 Pricing Update Updated pricing list full** Note: * Awaiting policy decision ** Awaiting policy decision related to set published price list in the IDE Table 3 Summary of LRIT messages Table 4 below provides a summary of all message types needed to ensure a proper handshaking and interface between the ASP and the DC. These messages are not defined in IMO documents. Page 18 of 92

19 Message Type Message Name Message Description Direction System health data 101 Information/Exception Message to be sent to EU DC in case of errors or unexpected behaviour of the system 102 ASP System Status (Ping) Routine 30-minute status message from the ASP to the EU DC, advising that the system is healthy. 103 Ship Check/Reset Request Message to be received from the EU DC requesting a communication status check for a given ship ASP -> DC ASP -> DC DC -> ASP Ship database handling 104 Ship Database Update Notification 105 Ship Database Update Request 106 Ship Database Update Response Message to be received from the EU DC informing the ASP whether the LRIT Ship Database has been updated or not Message to be sent to the EU DC requesting an update of the LRIT Ship Database Message to be received from the EU DC providing a full or incremental update of the LRIT Ship Database DC -> ASP ASP -> DC DC -> ASP Table 4 Summary of messages for interface between ASP and DC Each of above messages is here below presented in tabular format (Table 6 until Table 14) with the following columns: Page 19 of 92

20 Column Parameter Provided By Parameter Values Description Parameter Description Indicating the particular LRIT component that provides the parameter information contained in the LRIT message Listing the various parameter names contained within the LRIT message Listing the potential values of each associated parameter Providing brief information pertaining to each of the various parameters in the LRIT message LRIT Segments Indicating which of the LRIT communications segments contain the parameter (Figure 2 of MSC 83/6/1, Annex 3) Processed Format Defining the specific format for each parameter Note: The definition of the various processed formats listed in the Processed format column are: n represents 1 ASCII decimal digit (0-9). n1 nn c represents 1 to n ASCII decimal digits. represents 1 ASCII alphabetic character. c1 cn - represents 1 to n ASCII alphabetic characters. YYYY:MM:DD:HH:mm represents the Year:Month:Day:Hour:Minute. Year is 4 ASCII decimal digits from , Month is 2 ASCII decimal digits from 01 to 12, Day is 2 ASCII decimal digits from 01 to 31, Hour is a 2 ASCII decimal digits from 00 23, Minute is 2 ASCII decimal digits from ss (where required) represents seconds, which is 2 ASCII decimal digits from TEXT unformatted alpha numeric text string Table 5 Message parameters LRIT messages Type 1, 2, 3 ship position reports Position reports (messages of type 1, 2, and 3) are sent by the ASP to the EU DC. The EU DC will process, archive and, if needed, forward the messages to the IDE or the EU Users according to the DDP Table 6 outlines the parameters associated with the positional data messages 1, 2 and 3 (ship position reports). The ASP should follow the format in which the EU LRIT DC has to transmit the LRIT ship position reports as specified in Table 6 to the IDE. The Ship to CSP to ASP communication may transmit LRIT position report messages amongst themselves in any format that they choose The parameter CSP ID# provides the unique LRIT component ID of the CSP that transmitted the LRIT positional data message to the ASP. Page 20 of 92

21 Parameter provided by Parameter Values Description LRIT segments Processed format WGS84 latitude position of Latitude Latitude the ship:degree, minutes and decimal minutes to two decimal places N (North) / S (South) B, C, D nn.nn.nn.c LRIT shipborne equipment Longitude Longitude WGS84 longitude position of the ship:degree, minutes and decimal minutes to two decimal places E (East) / W (West) B, C, D nnn.nn.nn.c Time Stamp 1 Time 1 Date and time when position was taken in UTC. B, C, D YYYY:MM:DD: HH:mm Shipborne equipment identifier Equip# The identifier used by shipborne equipment B, C, D c 1.c n ASP ID# ASP# LRIT ID of the ASP B, C, D nnnn CSP ID# CSP# LTIR ID of the CSP B, C, D nnnn Message type 1, 2, 3 Message type number: B, C, D nn 1- Periodic report LRIT ASP 2- Polled report 3- SAR report Message ID# Unique number Unique message number generated by using: ASP ID, local date time stamp and unique sequence number. B, C, D nnnnyyyymmdd HHmmssnnnnn Reference ID# 0, Message ID The message ID# of the associated requested message. It is only valid for a response to a request message. B, C, D nnnnyyyymmdd HHmmssnnnnn IMO # IMO # IMO ship identification number of the ship being tracked. B, C, D nnnnnnn MMSI# MMSI# Maritime Mobile Service Identity number of the ship being tracked. B, C, D nnnnnnnnn Time stamp 2 Time2 Date and time ASP B, C, D YYYY:MM:DD: Page 21 of 92

22 Parameter provided by Parameter Values Description LRIT receives message (UTC) segments Processed format HH:mm:ss Time stamp 3 Time3 Date and time ASP transmits message (UTC) B, C, D YYYY:MM:DD: HH:mm:ss Table 6 Summary of LRIT positional data (position report) - message 1, 2 and LRIT messages Type 4 and 5 Request Messages LRIT messages received from the LRIT Data Users interface or the IDE interface that have been identified as ship position request messages or SAR poll request messages will be checked by the EU DC to determine if the ship of interest is reporting to the EU DC, the eligibility of the request and if any interaction with the vessel shipborne equipment is necessary If the LRIT request message is a poll, a stop or a change in the periodic reporting interval message, then the message will be sent to the ASP for further processing Table 7 outlines the parameters associated with the ship position request messages. The EU LRIT DC is responsible for formatting the LRIT ship position request messages. Page 22 of 92

23 Parameter provided by Parameter Values Description LRIT segments Processed format Message type 4, 5 Message type number: 4- Ship position request B, C, D nn 5- SAR poll request Message ID# Unique number Unique message number generated by using: LRIT ASP ID, Date and unique sequence number. B, C, D nnnnyyyymm DDHHmmss nnnnn IMO# IMO# IMO ship identification number of the ship to be tracked B, C, D nnnnnnn LRIT Data User Provider User ID# LRIT ID of the Data User (Contracting Government) to which the ship is registered. B, C, D nnnn LRIT Data User Access type 1,2,3,4,5,6 This LRIT parameter is set based upon LRIT Data User s requester entitlement to receive LRIT Data: 1- Coastal 2- Flag 3- Port with distance trigger from port or port facility 4- Port with distance trigger from coast 5- Port with time trigger 6- SAR B, C, D n Port or Port Facility 00000, UN/LOCODE or IMO port facility # UN/LOCODE code for the port or IMO port facility # for the port facility that the ship is planning on entering. Parameter is only valid for Access Type 3, 4 and 5. B, C, D c 1 c n Distance Nautical miles Distance in nautical miles from the Port, Port facility or coastline where tracking should commence. Parameter is only valid for Access Type 3 and 4. B, C, D nnnn Request type 1,2,3,4,5, 6,7,8,9,10,11 Request type: 1- One time poll of ship 2-15 minutes periodic rate 3-30 minutes periodic rate 4-1 hour periodic rate 5-3 hours periodic rate B, C, D nn Page 23 of 92

24 Parameter provided by Parameter Values Description LRIT segments 6-6 hours periodic rate 7- Archive Data request 8- Stop/don t start sending reports 9- Most recent position report hours periodic rate hours periodic rate Processed format Request Start:Stop START refers to the time when B, C, D YYYY:MM:DD: Duration LRIT position reports are requested to begin. STOP refers to the end time for HH:mm:YYYY: MM:DD:HH:mm receiving LRIT reports. A value of: 0000:00:00:00: :00:00: 00:00 indicates that parameter is not valid. (Contracting Governments may decide to use repeat polling or periodic rate modification to obtain variable position report intervals.) LRIT Data User ID# LRIT ID of the LRIT Data User B, C, D nnnn User issuing the request. Requester Time stamp Time Date and Time when LRIT Data B, C, D YYYY:MM:DD: YYYY:MM:DD :HH:mm:ss User transmits message to its DC. HH:mm:ss EU LRIT Data DDP Version# Unique DDP version number used by D, C n 1 n n Centre number DC. Test 0, 1 Setting indicating if message is test message or regular LRIT message. D, C n 0- Regular LRIT message 1- Test message Table 7 Summary of LRIT request messages (messages 4 and 5) Page 24 of 92

25 For Message Type 7 - Receipt messages Table 8 outlines the receipt message. The receipt message is issued in order to acknowledge the receipt of an LRIT request message that cannot be processed for some reason. When the ASP receives an LRIT request message it should process the request message and either send the requested information or send a receipt message with the appropriate receipt code informing the requester of the message why the request message could not be provided. Page 25 of 92

26 Parameter provided by Parameter Values Description LRIT segments Processed format Message type 7 Message type number: 7 Receipt message B, C, D, E, F nn Message ID# Unique Unique message number B, C, D, E, F nnnnyyyymm number generated by using: LRIT Component ID, Date and unique sequence number. DDHHmmss nnnnn Reference ID Message ID The reference ID is the B, C, D, E, F nnnnyyyymm of a request message message ID of a request message that has been received. DDHHmmss nnnnn Receipt Code 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 0- Not entitled to data 1- No ships in SAR SURPIC area 2- IDE not available B, C, D, E, F nn LRIT Network component: Data Centre, ASP, IDE or LRIT Data User 3- DC not available 4- CSP not available 5- Ship not responding 6- Ship not available 7- System Fault 8- Could not load DDP 9- Incorrect DDP version, message not transmitted Destination LRIT network LRIT ID of intended recipient B, C, D, E, F nnnn component (ASP, DC, IDE, LRIT Data ID User) of the receipt message. Originator LRIT network LRIT ID of issuer (ASP, DC, B, C, D, E, F nnnn component IDE, LRIT Data User) of the ID receipt message. Message Text Text message indicating the nature of the receipt message. B, C, D, E, F TEXT Time stamp Time UTC Date and time when LRIT node B, C, D, E, F YYYY:MM:DD: YYYY:MM:DD: transmits receipt message. HH:mm:ss HH:mm:ss Data Centre DDP version # Unique DDP version number used by C, D n 1.n n or IDE number DC Test 0, 1 Setting indicating if message is test message or regular LRIT message. C, D n Page 26 of 92

27 Parameter provided by Parameter Values Description LRIT segments 0- Regular LRIT message 1- Test message Processed format Table 8 Summary of receipt message (message 7) Information/Exception Message (type 101): This message shall be sent by the ASP to the EU DC in reply the Ship Check Request messages (type 103) in case of a change in the network assignment of a vessel and in case of errors or unexpected behaviour of the system Errors or unexpected behaviour of the system are the following situations: Missing periodic position report: a planned position report from a ship has not been received by the ASP after a predefined period of time (according IMO Type Approval specifications, drafted in IMO Circular MSC.1/Circ.1257, adopted by MSC 84). The time interval between two messages too short (according IMO Type Approval specifications, drafted in IMO Circular MSC.1/Circ.1257, adopted by MSC 84). Communication failure to the Land Earth Station System failure of the CSP Communication failure to the CSP System failure of the ASP Others Page 27 of 92

28 Parameter provided by Parameter Values Description LRIT segments Processed format Message type 101 Exception Message B, C, D nn ASP/CSP Message ID# Unique number Unique message number generated by using: LRIT ASP ID, Date and unique sequence number. B, C, D nnnnyyyymm DDHHmmss nnnnn Reference ID Message ID of a request message The reference ID is the message ID of a request message that has been received. B, C, D, E, F nnnnyyyymm DDHHmmss nnnnn Time stamp Time UTC YYYY:MM:DD: Date and time when this message is transmitted. B YYYY:MM:DD: HH:mm:ss HH:mm:ss IMO# IMO# The IMO number of the ship which tracking caused the exception Message Code 0,1,..,8,999 0 no exception encountered 1 - Missing periodic position report 2 Periodic rate too high (overreporting) 3 Periodic rate too low (underreporting) 4 Communication failure to the Land Earth Station 5 System failure of the CSP 6 Communication failure to the CSP 7 System failure of the ASP 8 Network assignment 999 Other B B nnnnnnn nnnn Short Description Text Short description of the exception (max 300 characters) B TEXT Destination LRIT network component ID LRIT ID of the EU DC B nnnn ASP ID# ASP# LRIT ID of the ASP B nnnn Page 28 of 92

29 Parameter provided by Parameter Values Description LRIT segments Processed format CSP ID# CSP# LTIR ID of the CSP B, C, D nnnn Communication Network 1, 2, 3, Vessel Communication Network ID B nn 1 INMARSAT C 2 INMARSAT D+ 3 IRIDIUM Test 0,1 Setting indicating if message is test message or regular LRIT message. 0- Regular LRIT message 1- Test message B n Current periodic rate [optional] 2,3,4,5, 6, 8, 10,11 Last processed request type at ASP: 2-15 minutes periodic rate B, C, D nn 3-30 minutes periodic rate 4-1 hour periodic rate 5-3 hours periodic rate 6-6 hours periodic rate 8- Stop/don t start sending reports hours periodic rate hours periodic rate Table 9 Summary of Exception message (message 101) ASP System Status message (type 102) This message shall be sent by the ASP to the EU DC with a predefined frequency in order to show that the communication link and the ASP system are active. If the EU DC does not acknowledge the reception, ASP operators must contact the EMSA Operator by other direct means (for instance telephone) and inform them of the situation. Page 29 of 92

30 Parameter provided by Parameter Values Description LRIT segments Processed format Message type 102 ASP System Status Message B nnn ASP/CSP Message ID# Unique Unique message number B nnnnyyyymm number generated by using: LRIT ASP ID, Date and unique sequence number. DDHHmmss nnnnn Time Stamp Time Date and time when this message is transmitted. B YYYY:MM:DD: HH:mm:ss ASP System The ASP system status is B n Status nominal and all functions are available 1 One or more ASP functions are not available 2 All ASP functions are not available due to maintenance 3 - All ASP functions are not available due to system failure Description Text A short description of the nature of the problem, if status is not 0 (max 300 characters) B TEXT Destination LRIT network component ID LRIT ID of the EU DC B nnnn Originator LRIT network component ID LRIT ID of ASP B nnnn Test 0,1 Setting indicating if message is test message or regular LRIT message. 0- Regular LRIT message 1- Test message B n LRIT Ship TEXT The current version of the LRIT B cccc.cc Database current Ship Database stored at the EU DC version Table 10 Summary of ASP System Status message (message 102) Page 30 of 92

31 Ship Check/Reset Request message (type 103) This message is received by the ASP when the EU DC wants to know the status of the communication link and the shipborne equipment of a given ship. The ASP will perform the status check and respond to the EU DC with the Information/Exception message (type 101). Parameter provided by Parameter Values Description LRIT segments Processed format Message type 103 Ship Status Check Request Message B nnn EU DC Message ID# Unique number Unique message number generated by using: LRIT ASP ID, Date and unique sequence number. B nnnnyyyymm DDHHmmss nnnnn Time Stamp Time Date and time when this message is transmitted. IMO# IMO# The IMO number of the ship to be checked Action 0,1,2 The action to be performed by the ASP: 0- Reset of shipborne equipment (if functionality is available) 1- Disable communication for this vessel 2- Check on reporting periodic rate of the vessel B B B YYYY:MM:DD: HH:mm:ss nnnnnnn nn Destination Originator LRIT network component ID LRIT network component ID LRIT ID of the ASP B nnnn LRIT ID of the EU DC B nnnn Test 0,1 Setting indicating if message is test message or regular LRIT message. 0- Regular LRIT message 1- Test message B n Table 11 Summary of the Ship Status Check Request message (message 103) Page 31 of 92

32 Ship Database Update Notification message (type 104) This message is sent on a daily basis by the EU DC to the ASP to inform whether the ship database has been updated or not. Parameter provided by Parameter Values Description LRIT segments Processed format Message type 104 Ship Database Update Notification B nn EU DC Message ID# Unique Unique message number B, C, D nnnnyyyymm number generated by using: LRIT EU DC ID, Date and unique sequence number. DDHHmmss nnnnn Time Stamp Time Date and time when this message is transmitted. B YYYY:MM:DD: HH:mm:ss Notification 0,1 0 The LRIT Ship Database B nnnn Type HAS NOT been updated after the last notification 1 The LRIT Ship Database HAS been updated after the last notification LRIT Ship TEXT The current version of the LRIT B cccc.cc Database Ship Database version Destination LRIT network component ID LRIT ID of the ASP B nnnn Originator LRIT network component ID LRIT ID of EU DC B nnnn Test 0,1 Setting indicating if message is test message or regular LRIT message. 0- Regular LRIT message 1- Test message B n Table 12 Summary of Ship Database Update Notification message (message 104) Page 32 of 92

33 Ship Database Update Request message (type 105) This message is sent by the ASP to the EU DC to request an update of the ship database. The update can be incremental, with respect to the previous version, or full. The EU DC will reply with a corresponding response (message type 106). Parameter provided by Parameter Values Description LRIT segments Processed format Message type 105 Ship Database Update Request B nn ASP/CSP Message ID# Unique number Unique message number generated by using: LRIT ASP ID, Date and unique sequence number. B nnnnyyyymm DDHHmmss nnnnn Time Stamp Time Date and time when this message is transmitted. Update Type 0,1 0 Incremental 1 Full B B YYYY:MM:DD: HH:mm:ss nnnn LRIT Ship Database version TEXT The current version of the LRIT Ship Database stored at the ASP; if type is 0, the requested incremental update is relative to this version number B cccc.cc Destination Originator LRIT network component ID LRIT network component ID LRIT ID of the ASP B nnnn LRIT ID of EU DC B nnnn Test 0,1 Setting indicating if message is test message or regular LRIT message. 0- Regular LRIT message 1- Test message B n Table 13 Summary of Ship Database Update request message (message 105) Page 33 of 92

34 Ship Database Update Response message (type 106) This message is sent by the EU DC to the ASP to transfer an update of the ship database. The update can be incremental or full, according to the request (type 106) previously sent by the ASP. Page 34 of 92

35 Parameter provided by Parameter Values Description LRIT Message type 106 Ship Database Update segments Processed format Response B nn EU DC Message ID# Unique number Unique message number generated by using: LRIT EU DC ID, Date and unique sequence number. B nnnnyyyymm DDHHmmss nnnnn Time Stamp Time Date and time when this message is transmitted. Update Type 0,1,2 0 Incremental 1 Full 2 Not available; in case the incremental update is relative to an old database version B B YYYY:MM:DD: HH:mm:ss nnnn LRIT Ship Database current version TEXT The current version of the LRIT Ship Database stored at the EU DC B cccc.cc LRIT Ship Database previous version TEXT The previous version of the LRIT Ship Database, to which the incremental update must be applied B cccc.cc Note: This parameter is available only in case of incremental update Update File File The file containing the database update (full or incremental) B File Destination Originator LRIT network component ID LRIT network component ID LRIT ID of the ASP B nnnn LRIT ID of EU DC B nnnn Test 0,1 Setting indicating if message is test message or regular LRIT message. 0- Regular LRIT message 1- Test message B n Table 14 Summary of Ship Database Update Response messages (message 106) Page 35 of 92

36 4. Requirements: ASP/CSP operation The requirements given in this chapter will be all subject to evaluation All the requirements formulated with the terms shall, must and has to are mandatory to fulfil If the tenderer has to deviate from the requirements, as set out in this document, then the tenderer must present equivalent requirements and must justify the deviation(s). EMSA reserves the right to disagree with the deviation and the proposed solution The phrase ship owner should be understood throughout this document as the responsible shipping company or the ship operator responsible for the ship s exploitation References in this document like chapter, paragraph or article are referring to this document unless other reference documents are identified explicitly REQUIREMENTS IMPOSED BY IMO The IMO and the Contracting Governments are still in the process of refining the final LRIT system specifications. The present status was adopted at MSC 84 and is expected to be published in June Further refinements might be undertaken, if necessary. Requirements The contractor has to operate in compliance with the provisions of SOLAS chapter Regulation V regulation 19-1 specified in Resolution MSC.202(81) Resolution MSC.263(84) (replacement of MSC.210(81)) provides the performance standards and functional requirements of the LRIT system which have to be fulfilled and adhered to by the contractor The contractor has to be in compliance with the specifications determined by IMO Circular MSC.1/Circ.1259 Interim revised technical specifications for the LRIT system The contractor has to implement the system according to the most recent LRIT system specifications as defined by IMO. Page 36 of 92

37 4.2. SYSTEM PERFORMANCE The EU LRIT system will provide the service to all EU MS, Norway and Iceland for the vessels under their flag. Overseas territories of the EU MS and third countries also have the possibility to use the EU LRIT system under certain conditions The EU flagged vessels which fall under the LRIT regulation are estimated to be around 10,000 ships. If the vessels from the overseas territories are included this number might significantly increase With a mandatory message reporting set at every 6 hours this translates to approximately over 15 Million messages per year. If we include additional messages due to requests from Contracting Governments to increase the message frequency this could be a much higher number. Requirements The contractor must be capable of processing 20 Million messages per year The system must be capable of processing and delivering at least 100 LRIT messages per minute In case the LRIT message rate increases to more than 100 messages per minute, then the contractor has to provide a first-in-first-out (FIFO) buffer ensuring, that no information will be lost In case of a special request by an authorized user, the system must be capable of processing LRIT messages from a vessel at least every 15 minutes The health of the systems shall be permanently checked by the contractor and shall be reported to the EU LRIT DC through periodic ASP system status report messages (type 102) indicating proper operation of the system. The default rate for this check is 30 minutes but can be changed on request The ASP shall check, that the data is being received and that it is on time and evaluate the situation in case of data delivery failure (positional data and acknowledgments). In case of failure or non-conformant operation an Information/Exception message type 101 has to be sent to the EU DC. (See also Article 4.3.1) The ASP shall in case of over-reporting (the shipborne equipment is transmitting more frequently than it is configured for) issue an Information/Exception message type 101 to be sent to the EU DC. (See also Article 4.3.1) The contractor shall be able to disable the communication line via the CSP, LES and/or communication service provider in case the shipborne equipment is non-compliant or malfunctioning should the EU LRIT DC Monitoring Interface Page 37 of 92

38 Operator (MIO) request this. After disabling the communication line, there should be no further airtime costs The contractor shall ensure an availability of the system of 97.5% during a 24h period and 99.5% over one month Latency times Requirements The individual LRIT information/message shall be available at the LRIT Data Centre at least 1 minute (1σ) 2 after the vessel information/message has been received by the CSP On-demand LRIT information reports: the execution of poll requests and the following processing of LRIT messages must be processed within 15 minutes if the vessel is in immediate visibility of the communication satellite and 30 minutes 3 otherwise after the request via the EU LRIT DC has been received The integration of vessels and their shipborne equipment into the service of the contractor shall not last longer than 24 hours, if the required ship information is available in the ship databases (Article 4.6.1). If additional data has to be retrieved by the contractor, the integration shall be performed within 48 hours The contractor has to setup a fast procedure to integrate shipborne equipment of a particular ship into the service in case of emergencies. The tenderer is requested to provide this procedure and to specify the expected integration time in the bid. 1 The availability rates have been deducted from the IMO specifications which are defining a combined availability of ASP/CSP and DC operations. Therefore for the individual system the square roots of 95% resp. 99% have been taken. 2 1σ refers to the distribution of latency time by using a Gaussian distribution centred on the origin. 3 Reference: MSC.1/Circ Page 38 of 92

39 Network coverage With the aim to provide a full global coverage (including the polar areas) and according to a EU Member State survey on the usage of communication networks on the vessels under their flag, the following communication networks were identified to be used for the EU LRIT system: INMARSAT C incl. INMARSAT mini C, INMARSAT D+, IRIDIUM Additional networks may be used by dedicated vessels or will be used in the future and therefore the tenderer is strongly invited to provide a full list of supported communication networks (exceeding the list given above), meeting all the functional requirements to comply with all of the IMO specifications for LRIT The tenderers have to provide the geographical coverage of their supported networks with their bids. Requirements The INMARSAT C incl. the INMARSAT mini C communication network has to be supported by the tenderer The INMARSAT D+ communication network has to be supported by the tenderer The IRIDIUM communication network has to be supported by the tenderer In case of proprietary communication standards of the above requested networks (e.g. applicable for INMARSAT D+ terminals), the contractor must have the capability to re-program the shipborne equipment according to the supported communication standard The tenderer will have an advantage if he is able to provide a list of further supported communication links which fulfil and comply with the IMO specifications for LRIT. EMSA reserves the right to include all or some of these networks into the service/contract Journaling / Billing information The journals of all exchanged messages will be used for quality checking and billing purposes. The journaling information has to be generated by the contractor and shall be available to EMSA and the EU LRIT DC at all time. Requirements The contractor shall monitor the ASP - EU LRIT DC interface and maintain a Page 39 of 92

40 journal of all incoming and outgoing messages, reporting interval changes and any billable transactions. All billing relevant data transfer has to be labelled accordingly. The journaling data has to be delivered in an XML format The communication network being used has to be included in the journal for all LRIT messages towards and from the vessel Journaling / billing information shall be available to the Agency at all times through an electronic request At the Agency s request, the contractor has to provide the activity log related to any message of type 1 to 5, 7 (activities by the ASP, CSP and vessel) and of type 101 to The XML schema for the journaling shall be developed by the contractor LRIT MESSAGES For the LRIT message types 1, 2 and 3 (Article 3.3.1) the ASP has to add to the information received from the CSP the information listed in Table 2 of Article 3.1 to achieve the full LRIT position message as requested by IMO. The LRIT message types 1, 2, 3 and type 7 (Article 3.3.3) will be delivered by the ASP as XML files. Vice versa the ASP must be capable to read and to interpret the LRIT messages type 4 and 5 (Article 3.3.2) which are again XML files. Requirements For the LRIT message types 1, 2 and 3 the contractor has to add to the information received from the CSP the information listed in Table 2 of article 3.1, The LRIT message types 1, 2 and 3 (chapter 3.3.1) and type 7 (Article 3.3.3) have to be delivered by the contractor as XML files. The draft format of the XML file is shown in Annex A The contractor must be capable to read and to interpret the LRIT messages type 4 and 5 (Article 3.3.2) which are again XML files. The draft formats of the XML files are shown in Annex A Non default operation In case of over-reporting (messages are received from the vessels more frequently than requested) or under-reporting (messages are not available in Page 40 of 92

41 time) the EU LRIT DC Monitoring Interface Operator (MIO) decides on necessary actions to be undertaken The MIO informs the ASP on actions to be undertaken via message type 103 e.g. request for investigation, checking the shipborne equipment, stopping of communication, resetting the shipborne equipment The ASP shall autonomously (independently) investigate non-compliances of received or expected messages. The following rules for autonomous investigation apply: Single requests: If the message is not available after 30 min. or If the IMO Type approval criteria (IMO circular MSC.1/Circ.1257, adopted by MSC 84) are not met by the shipborne equipment Periodic requests: under-reporting has to be investigated: If the message is not available according to the IMO Type approval criteria (IMO circular MSC.1/Circ.1257, adopted by MSC 84) Periodic requests: over-reporting has to be investigated: If a message is already received after a certain fraction of the requested reporting interval and after a given number of these over reported messages are received within a certain time period The parameters: fraction, number of over-reports and time interval will be defined by MIO and will reflect past experiences Non reporting vessels shall be checked through polling requests sent by the ASP to be able to discriminate between failures of the shipborne equipment including power off, the satellite/land earth station, the CSP or ASP, or a disabling of a message transmission issued by the vessel If further failure information e.g. no GPS location or any other wrong token in the message is available, the ASP is requested to provide the information The ASP has to check if the LRIT information received is plausible in terms of time, location and vessel information; The ASP has to report the investigations with an Information/Exception message type 101 (chapter 3.3.4) to the MIO within 24 hours In case of a failure of the shipborne equipment, the ASP has to try to reconfigure the device and/or has to contact the ship owner to initiate a remedial Page 41 of 92

42 action. If the failure cannot be solved, the contractor has to inform the Agency within 24 hours after the first failure has occurred. Requirements The ASP shall autonomously investigate non-compliances of received messages according to the rules given in this chapter ( ff.) The ASP has to report the investigations with an Information/Exception message type 101 (chapter 3.3.4) to the MIO The ASP has to check if the LRIT information received is plausible in terms of time, location and vessel information; Non reporting vessels shall be checked through polling requests sent by the ASP to be able to determine the reason of the failure In case of a failure of the shipborne equipment the ASP has to try to reconfigure the device and/or has to contact the ship owner to initiate a remedial action. If the failure cannot be solved, the contractor has to inform the Agency within 24 hours after the first failure has occurred POLLING OF INFORMATION Requirements The contractor shall process the LRIT position request message from the LRIT DC which might be a Poll (i.e. the poll request for a single report of an LRIT message type 2 or 3), periodic request (i.e. the request for reporting LRIT messages type 1 every hour rather than the default poll request for every 6 hours) or stop request (no further LRIT messages will be sent by the vessel) The ASP has to check that each remote configuration will be acknowledged by the shipborne equipment If the remote configuring process was not successful, then the ASP has to repeat the process. If the shipborne equipment still cannot be remotely configured, then the contractor has to issue a non-delivery report to the LRIT DC. Page 42 of 92

43 4.5. COMMUNICATION BETWEEN ASP AND EU LRIT DATA CENTRE Messages The data link from the EU DC to the ASP and vice versa from the ASP to the EU DC shall guarantee a fast, reliable, and secure transfer of ship position requests to be processed by the ASP and of ship position reports to the EU DC Several system messages will be exchanged between ASP and EU DC to ensure that the data link is active and that in the event of errors the EU DC is informed The communication is based on message types 1 to 5, 7 and 101 to 106 as described in chapter 3.3. They only concern vessels contained in the LRIT Ship Database Additional system messages, if needed by the ASP, shall be described in detail in the bid. The corresponding specifications shall be provided by the contractor within the first month of the implementation phase The XSD files for the messages types 101 to 106 shall be drafted by the contractor of the EU LRIT DC and shall be agreed between the contractors of the ASP and the EU LRIT DC under the chair of EMSA (see Article ). Requirements The ASP has to process and forward all received ship position messages to the EU DC The ASP has to process all the requests received from the EU DC The ASP has to send all required system messages to the EU DC The ASP has to monitor that any sent message to the vessel is acknowledged by the vessel, or by the Land Earth Station (LES) in such cases where the acknowledgment will imply additional airtime costs The XML Schema (XSD files) of the messages have been adopted by MSC 84 (Ref. MSC 84/6/1/Add.4) and have to be implemented by the contractor. The drafts are attached to this document (point Annex A.3) and shall be considered by the contractor as a reference when preparing the bid, even if minor changes are expected at the IMO level before the start of the project Some messages could also carry binary attachments in the form of ZIP files (MIME media type application/zip ). Page 43 of 92

44 Communication Interface In the event that the Contractor is also the winning tenderer of the EU LRIT Data Centre tender (ref. EMSA/OP/07/08) and both ASP and EU DC systems are hosted in the same environment and share the same local network, EMSA will accept the use of a different communication interface proposed by the contractor, in addition to the interfaces as described in this document. Requirements All communication links shall comply with the functional description given in Resolution MSC.263(84) (replacement of MSC.210(81)) (see also req ) The communication between ASP and EU DC shall be based on Web Services using the communication protocol, SOAP v. 1.2 over the HTTPS Internet protocol For every communication concerning LRIT messages, two asynchronous oneway messages connections are established between each SOAP node: one with the message and one with the acknowledgment. (SOAP 1.2 protocol) The ASP has to acknowledge all messages from the EU DC via the SOAP protocol The ASP has to monitor that any sent message to the EU DC is acknowledged by the EU DC via the SOAP protocol Security Due to the LRIT information being security and economically very sensitive data, the IMO has set some guidance on LRIT system security (Resolution MSC.263(84) - replacement of MSC.210(81)) which shall be followed by the contractor A 2-way Secure Sockets Layer (SSL) shall be used when an Internet connection (HTTPs) is established. This cryptographic system will be used to encrypt the exchanged data using 128-bit encryption when a communication is established. Using the SSL, the confidentiality as well as the integrity of data is ensured Any connection to the Internet shall be protected by a firewall according the current industry security standards. The firewalls will be used to prevent unauthorised users to access the network and block messages with malicious content The use of Public Key Infrastructure (PKI) and Digital Certificates is requested for any communication over the Internet between the ASP and the EU LRIT DC. The Certificates will be issued by a Certificate Authority (CA) selected by EMSA and Page 44 of 92

45 the Contractor will provide the information needed directly to the CA. The X.509 standard will be used. Requirements way HTTP/SSL to be used for any communication over the Internet Data security based on a two way certification using PKI digital keys, URL and an optional set of IP addresses. The ASP has to install the digital certificate (X.509 standard) (provided by a Certification Authority selected by EMSA) and maintain its validity SOAP v.1.2 to be used for the exchange of XML messages The data security concept shall be described in the bid As a minimum the contractor shall use firewalls in conjunction with the encryption of data for data security The ASP shall perform standard virus checking, anti-hacking and network security procedures on all messages to prevent malicious attacks INTEGRATION OF VESSELS IN THE SYSTEM SHIP DATABASE ISSUES The tenderer must be capable to set up the communication with the vessels identified by an IMO number delivered by the Agency. This vessel integration process is described in article The Agency will provide the list of ships by delivering the ship database as described in the following article Content and formats of the Ship database The vessel IMO number and additional information, if available, are stored in a EU ship database (EU ship DB) and will be available to the ASP. The format of this data delivery is an XML file. Member States may modify their entry in the EU ship DB at any time and therefore updated versions will be available frequently Only vessels with shipborne equipment type approved by the Administration of the flag state (Article 4.8) will be listed in the EU ship DB The EU ship DB contains the following mandatory information for each individual vessel 4 : IMO number MMSI Number Ship Name 4 According to IMO resolution 887(21) Page 45 of 92

46 Call Sign Additional data if available: Shipborne communication identifier (e.g. in case of INMARSAT C: DNID) Contact point/person Telephone number FAX number Text field for further information The update/new version of the EU ship DB after changes performed by a MS will be transmitted to the ASP according to the following sequential process: 1. After each EU ship DB update, the EU DC will transmit a database notification message (type 105) to the ASP to inform it that a new version of the EU ship DB is operational and available for download. 2. If the EU ship DB has received no change from any MS since the previous version of the EU ship DB was released, then the database notification message (type 105) shall indicate, in the message parameter, that there is no new incremental update because there have been no changes in the EU ship DB since the previous update. 3. Upon receipt of a Ship data Notification message informing a new version is operational and available for download, the ASP shall request the last updated version from the EU LRIT DC server (message type 106) 4. The EU LRIT DC server will respond with an update message (type 107) including the physical database as a file attachment (either an incremental update or the entire Ship database as requested). The EU ship DB will be provided by the ship database server in XML-format. 5. The ASP will upload the EU ship DB and update the internal databases accordingly For every communication concerning the ship database information (SOAP 1.2), two asynchronous secure one-way messages connections are established between each SOAP node: one with the ship database information and one with the acknowledgment. Alternatively secure FTP might be used if the amount of data so requires The Agency reserves the right to decide during the lifetime of the contract that the ship database will always be delivered in its entirety. Requirements The tenderer must be able to receive and process the ship database information as required The contractor has to activate new ship database information within 15 minutes without impairing the processing performance of the standard LRIT message handling. Page 46 of 92

47 The tenderer has to analyse each update of the ship database on new, modified or deleted vessel information Vessel integration The tenderer has to follow the procedure indicated in Figure 5 for vessels which are assigned to him through the ship database: Assignment request by the Agency start of process Analysing of available data Ship owner is known no Determination of the ship owner based on IMO number If communication ID is unknown or has to be assigned unknown/ to be assigned Request the ship borne equipment parameters from the ship owner or the network providers Assign the communication channel for LRIT messages to the ASP/CSP by establishing the link to the land earth station and configuring the ship borne equipment accordingly Assignment has to be done for the whole operating area of the vessel (default: worldwide) The ASP has to take over the airtime costs End of assignment process Figure 5 Process of integration of vessels in the system If available, the Agency will provide the contractor with the name and contact point of the ship owner and shipborne equipment/communication parameters In case of missing ship owner information and shipborne equipment/communication parameters, the tenderer has to: Page 47 of 92

48 determine the Ship owner (and its points of contact details) based on the IMO number or MMSI number depending on the availability of the information request the shipborne equipment/communication parameters (e.g. the terminal, serial number and DNID in case of INMARSAT-C) from the ship owner or the network providers For shipborne equipment, capable to operate several recipient addresses (like INMARSAT C is able to store several DNID s for different purposes) the ASP has to establish the procedure to reconfigure the shipborne equipment; such, that all LRIT messages will be directed to the CSP defined by the ASP For shipborne equipment allowing only point-to-point communication (e.g. IRIDIUM, INMARSAT D+) the ASP has to establish the procedure to reconfigure the shipborne equipment such that the device is solely dedicated to sending LRIT messages and addresses all messages to the CSP defined by the ASP In case the ship owner does not want to dedicate point-to-point operating shipborne equipment solely to the LRIT functionality, then the ship owner has to provide the CSP functionality himself and has to report the LRIT message in the standard format as described in Annex A.3 to the ASP for further processing. In this case the ship owner will have to cover the airtime and CSP costs himself The Agency will provide the contractor with the relevant legal documents to indicate that the selected ASP is entitled on behalf of the Flag States/Contracting Governments to receive the LRIT messages for further distribution to the EU LRIT DC and to configure the shipborne equipment of the vessels under their jurisdiction Communication shall be possible for all areas the vessel is operating in and which are supported by the communication network system. The contractor has to ensure that all communication ID s necessary for the vessel operations are assigned; e.g. for the INMARSAT C network, the contractor has to ensure that DNIDs are allocated for all INMARSAT navigation areas in which an individual vessel might operating in. Requirements The tenderer must be capable to set up the communication with the vessels identified by an IMO number delivered by the Agency The contractor has to establish the link to the land earth station, to the CSP and has to configure the shipborne equipment accordingly The contractor has to cover any costs of the LRIT messages imposed by the CSP and has to inform the billing system of the communication network that he is taking over the airtime costs accordingly The contractor must be capable of obtaining information, which are missing in Page 48 of 92

49 the ship database, in order to integrate vessels into the EU LRIT system The ASP has to establish the procedure to reconfigure the shipborne equipment, such, that all LRIT messages will be directed to the CSP defined by the ASP Communication shall be possible for all areas the vessel is operating in and which are supported by the communication network system HOSTING The hosting environment provided by the tenderer has to follow the IMO recommended criteria for the location of IDE and IDC and shall comply with the requirements of this document The hosting conditions aim to provide a safe working environment for the data which will be transferred to the EU LRIT DC and LRIT end users, including physical and operational safety of the hardware equipment, as well as the security of the site and security of the data. The physical location of the ASP shall be such so as to ensure the availability requirements and provide the expected quality of service Due to the LRIT information being security and economically very sensitive data and that the IMO has stated certain rules on security the hosting shall be in a secure location and shall include adequate 24 hour physical security to access the rooms where the servers/hardware are located including monitoring who goes in/out of the room and protection from, inter alia, vandalism, environmental disasters and fire, etc The ASP s internet connection shall have a tier 1/2 structure to guarantee a solid connection to the backbone without or with very little hops (nodes between) to reach the backbone. To fulfil the requirement the contractor shall declare that all its nodes are compliant with this. Below you will find the accepted definition of what it means: A Tier-1 backbone is a network which is transit-less, where it purchases or acquires no transit from any other party to maintain connectivity to the rest of the world. Tier-1 backbones are typically the largest backbones on the Internet, and all of the Tier-1s peer between each other to maintain connectivity. A Tier-2 backbone is a network which acquires transit from another party (such as a Tier-1 backbone), but also peers with other networks to reduce its reliance on transit provider routes. Largest Tier-2 backbones that are close to achieving Tier-1 status are also sometimes susceptible to loss of connectivity during a depeering event, as such networks only receive partial transit service to reach networks it does not peer with. Page 49 of 92

50 Data communication interface: The final delivery of the data to EMSA s operations centre shall be made over an Ethernet interface with IP as a network layer protocol. Where there is a need for placing other telecommunications equipment on or within the building, this will be facilitated by EMSA. Should the tenderer require a site survey to be carried out or require information on EMSA s terrestrial telecommunications connections in order for a potential tenderer to build a proposal, EMSA will provide the required information Backup for the supply, processing, routing and the storage of data must be available and shall be separated physically. An immediate switch to the backup in case of a failure has to be ensured to avoid any data loss. This architecture shall be described within the bid A redundant system has to be implemented in case of internet failures, physical problems on the hosting/environment/building, etc.. Regular backups and disaster recovery plan have to be established and described in the bid The ASP shall have back-up servers with seamless switch-over between servers. The main and backup equipment and systems shall be geographically distributed to the extent that is practically and reasonable possible The hosting and security concept shall be described in the bid. Requirements As LRIT messages and vessel operations are performed on a 24h/day basis the contractor shall provide a permanent point of contact for technical issues to carry out service operation, housekeeping and maintenance duties as necessary The ASP has to be connected to the internet by a tier 1/2 structure. The tenderer has to declare its compliance and shall provide the list of ISPs it is using to connect to the internet The system shall be based on COTS (Commercial Of The Shelf) components, which shall be demonstrated in the bid The contractor should have a network in place or present operating experience with CSP s, Land Earth Stations and the communication networks TYPE APPROVAL TESTING OF SHIPBORNE EQUIPMENT Only ships fitted with shipborne equipment type approved by their Flag State administration will be monitored by the European co-operative LRIT system. It is under the responsibility of the administration to type approve the shipborne equipment and deliver the relevant certificate of LRIT compliance to the ship owners. Page 50 of 92

51 The ship owners/flag states are free to contract any ASP for conformity testing they want. Nevertheless to facilitate the process for the ship owners/flag states, the tenderer shall be able to perform conformity tests of the shipborne equipment in accordance with the IMO LRIT requirements testing matrix (Ref: IMO Circular MSC.1/Circ.1257 and to be adopted at MSC 84), which then enables the Contracting Governments / Flag States to certify the shipborne equipment to be type approved for use for LRIT Once an ASP has issued a Statement of conformity report to the ship owner, the Flag State can issue a Certificate of compliance to the ship owner for carriage on the ship. This certificate should be valid for the duration the ship remains with the same Flag The tenderer has to draft in its bid the foreseen test procedure for the shipborne equipment taking into account the IMO LRIT requirements testing matrix. Requirements The contractor must be able to perform type approval testing of shipborne equipment in accordance with the IMO LRIT requirements testing matrix (Ref: IMO Circular MSC.1/Circ.1257 and to be adopted at MSC 84) which enables the Flag States to issue a certificate of compliance For this reason the contractor must issue the standard test reports as envisaged by IMO (Ref: IMO Circular MSC.1/Circ.1257) The contractor has to provide the test scheme for shipborne equipment to be in-line and comply with the IMO LRIT requirements testing matrix. This will enable other ASPs, selected by a ship owner or flag states, to perform the type approval testing ensuring the compatibility with the EU LRIT system. 5. Quality Assurance The tenderer shall propose a Quality Plan that describes the methodology and the procedures for the management and monitoring of the system and which will apply to all services during operational production. The quality procedures shall cover all aspects of service provision including the quality control of: Communication between the ASP and the CSPs Communication between the CSPs and shipborne equipment Communication between the ASP and the EU DC Interoperability between the CSPs if applicable Validity of messages flowing through the ASP Data processing performance at ASP Error-detection and non conformities Archiving and retrieval, media handling Page 51 of 92

52 Data formatting All services provided by the ASP/CSP shall be accompanied by a quality control indicator to be delivered periodically to EMSA by the ASP. The indicators will give EMSA the possibility to assess the quality of service against the specifications in terms of: Response time for polled position reports Response time for change of periodic rate requests Processing time for periodic position reports Messages throughput, overall and per message type System availability and data link availability between the ASP and the EU DC Quality management shall be performed by the ASP/CSP according to industrial best practices and a Quality Management Plan shall be provided. Any Quality Management standard followed by the tenderer shall be specified in their bid and any specific tailoring required by the project shall be identified and pointed out Detailed documentation on the interface with the EU LRIT DC ( Interface Control Document, ICD) shall be provided, including a description of any system messages that can be exchanged with the EU DC A Test Plan document (testing of the interfaces ASP/CSP and ASP/DC and the testing of the individual elements of the service) will be provided by the contractor and discussed during the Kick-off meeting. The plan will ensure that the ASP system correctly provides the expected services and that the communication with the EU DC is reliable and meets the required performance standards An Operations Manual will be provided, describing the procedures that the Monitoring interface operators should perform in normal operation and in the event of malfunctioning of the ASP. The manual shall at least include the following: Contacts of ASP technical support Periodic system testing procedures Testing procedures for the integration of new ships Disaster recovery procedures Requirements The ASP has to deliver a Quality Management Plan, describing quality control procedures, indicators and deliverables which shall be developed and followed by the tenderer. This plan shall also cover the service improvement processes (e.g. processing of change requests and non-conformities) Operations Manual to be developed by the ASP to be used by the LRIT Monitoring Interface Operator at EMSA. Page 52 of 92

53 Interface Control Document for CSP/ASP/EU DC communication shall be developed and provided by the ASP Test Plan for interfaces validation, ship integration and service operation shall be developed and provided by the ASP The ASP has to deliver a System Handbook, describing in detail the technical and administrative processes for each individual communication network supported and of the ASP activities, the security concepts for data handling and system hosting The ASP has to provide the following documentation according to the timetable given in article 8: Project Management Plan Quality Management Plan Operations Manual Interface Control Document Test Plan for interfaces validation, ship integration and service operation System handbook 6. Contract management responsible body The European Maritime Safety Agency, Unit C.3 Satellite Based Monitoring Services will be responsible for managing the contract. 7. Timetable The work shall start from the date of the signature of the framework contract. The kick-off meeting will be organised by EMSA, at the date of the signature of the contract or shortly thereafter. Its purpose shall be to enable all contracting parties to discuss the project to be fulfilled by the contractor, as well as to settle all the details of the work to be undertaken. The contractor s project manager, responsible for the work to be undertaken, will be present at the kick-off meeting The tenderer shall provide a detailed plan of activities and timelines for the implementation period with the bid. Event Date, Location Comment Signature of contract Kick-off meeting 1 st technical implementation meeting t0 t0+2 weeks at EMSA t0+2 months at contractors location Following the signature of the contract The initial test plan will be discussed Page 53 of 92

54 Starting with type approvals First technical approval of the service t0+2 months t0+3 months If requested by ship owners 5 /flag states. 1 st Progress meeting t0+3½ months at EMSA Following the service acceptance tests Service in commissioning phase Final technical approval of the service Service in full operation t0+3½ months t0+6 months t0+6 months 2 nd Progress meeting t0+12 months at EMSA 3 rd Progress meeting Final meeting t0+24 months location tbd. by EMSA t0+36 months at EMSA Based on the annual review with EU MS and evaluation of the service performance and service utility Further implementation meetings may be organised as appropriate. Requirements The contractor has to follow the timetable as provided in these tender specifications. Any change to the timetable requires an adoption by the contracting parties. 8. Project Planning / Documents to be submitted As already defined in Article : The ASP has to act in support of the Service Contract for the EU LRIT Data Centre. The contractor of the ASP (this tender) and the contractor of the EU LRIT DC (tender EMSA/OP/07/08) have to coordinate their interactions and to specify in detail the interfaces between them. The procedures and specifications will be drafted by the contractor of the EU LRIT DC and will be agreed between both contractors under the chair of the Agency The documents to be provided by the ASP after to fulfil the obligations of the contract are identified in the table below. The project shall respect the following timetable for delivery of these documents: 5 The phrase ship owner should be understood as the responsible ship company or operator responsible for ship s exploitation Page 54 of 92

55 Event Date Comment Signature of contract Project management plan Agreement between the contractors of ASP and EU LRIT DC and EMSA on the interface implementation and working procedures D1: Data format protocols / interface protocols D2: Type approval testing scheme t0 t0+½ months t0+1 month t0+1 month t0+1½ months See Article 4.8 D3: Test plan t0+2 months D4: Quality management plan assessment procedure, improvement process, validation protocol t0+2½ months Documentation on the quality management process D5: Completion report t0+3½ months Report on the service implementation and service test result D6: System Handbook t0+4 months Verification report & Annual progress report Verification report & Annual progress report Verification report & Final progress report t0+11 months t0+23 months t0+35 months Including Update of the service description and specification Including Update of the service description and specification Including Update of the service description and specification Requirements The contractor has to provide the documentation as listed in these tender specifications. 9. Budgeted amount The maximum allocated budget for the duration of the contract is 7 Million subject to annual confirmation by the Budgetary Authority The budget indicated must cover all costs (e.g. airtime costs, costs for setting up the service, in particular the interface and the communication link, integrating of ships, testing, correcting data, maintenance and upgrades, and training sessions) for the duration of the contract. No additional funds will be available. 10. Terms of payment Payments procedures, over-reporting handling and penalties for service noncompliance shall be issued in accordance to the provisions of the draft framework Page 55 of 92

56 and specific contract(s) (Tender Enclosure II) available under the Procurement Section relevant to the present call to tender on the EMSA website at the following address: Service non-compliance will be evaluated against Service availability Non-delivery rate of the ASP (not of the vessels) Delivery delays evaluated on a statistical set of 100 messages per month over the duration of the whole specific contract Costs for bulk of messages and vessel integration in the system will be paid in advance in accordance to the provisions of the draft framework and specific contract(s) (Tender Enclosure II) available under the Procurement Section relevant to the present call to tender on the EMSA website at the following address: Terms of contract In drawing up a bid, the tenderer should bear in mind the terms of the draft framework and specific contract(s) contained in Tender Enclosure II available under the Procurement Section relevant to the present call to tender on the EMSA website at the following address: The framework contract(s) will be signed for a duration of 3 (three) years with the possibility to extend the contract by one more year under the same conditions The Framework Contract shall be implemented by Specific Contracts covering: 1. The set-up costs. The Specific Contract shall be issued at the time of signature of the framework contract; 2. The purchase of messages and vessel integrations in the system. Each Specific Contract will cover the costs for both, the messages and vessel integration. Each Specific Contract can be called upon in different steps and need to be covered by a bank guarantee (see 14.1). The costs of the delivered messages and the performed vessel integrations will be deducted from this fixed amount of Euros. At the end of each Specific Contract, the remaining amount of Euros will be recalculated retrospectively for the duration of the Specific Contract by taking into account the prices corresponding to the amount of delivered messages and vessel integrations per time interval. 3. Further developments, if appropriate The ownership of the LRIT data will be solely by EMSA and the Contracting Governments participating in the EU LRIT Data Centre as defined in the draft framework contract (Tender Enclosure II). Page 56 of 92

57 12. Grouping of service providers Groupings, irrespective of their legal form, may submit bids. Tenderers may, after forming a grouping, submit a joint bid on condition that it complies with the rules of competition. Such groupings (or consortia) must specify the company or person heading the project and must also submit a copy of the document authorising this company or person to submit a bid If awarded, the contract will be signed by the company of the person heading the project, who will be, vis à vis EMSA, the only contracting party responsible for the performance of this contract. Tenders from consortia of firms or groups of service providers, contractors or suppliers must specify the role, qualifications and experience of each member or group. 13. Sub contracting If the tenderer intends to either subcontract part of the work or realise the work in co-operation with other partners he shall indicate in his bid which part will be subcontracted, as well as the name and qualifications of the subcontractor or partner. The overall responsibility for the work remains with the tenderer. 14. Price Prices must include all costs (including travel expenses) Prices must be quoted in Euro using (with the exception of the countries within the EURO zone) the conversion rates published in the C series of the Official Journal of the European Union on the day when the contract notice was published Prices related to the delivery of the service and service products are subject to the fixed price levels offered to EMSA by the contractor. These prices are valid for the duration of the contract and not subject to revision for the first year of performance of the Contract. Prices may only be revised upwards or downwards each year, where such revision is requested by one of the contracting parties by registered letter received by the other no later than three months before the anniversary of the date on which the Contract was signed. This revision shall be determined by the Monetary Union Index of Consumer Prices (MUICP) published by the Office for Official Publications of the European Communities in the Eurostat monthly bulletin at Revision of the prices indicated in Article I.3.3 may only be requested if the MUICP records a price level evolution of 3% or more for a consecutive period of 12 months. Revision shall be calculated in accordance with the provisions set in the Contract Under Article 3 and 4 of the Protocol on the privileges and immunities of the European Communities, EMSA is exempt from all duties, taxes and other charges, including VAT. This applies to EMSA pursuant to Regulation 1406/2002/EC These duties, taxes and other charges can therefore not enter into the calculation included in the bid. The VAT amount must be shown separately. Page 57 of 92

58 Tenderers are requested to present a price breakdown for each communication network Tenderers should provide a price breakdown which shows the service set-up costs, the unit costs for messages and vessel integrations, the fees for further developments and the costs of conformity testing. Any costs which are not covered by these categories have to be included in the individual message costs EMSA is expecting an increase of messages per year within the lifetime of the contract This pricing shall be done on a unit basis (e.g. message, integration of one vessel into the system, working day) According to the specifications by the IMO, the vessel owner does not have to pay for its LRIT messages. The airtime costs will be requested by the CSP and have to be balanced by the ASP, who will forward the costs to the Agency as part of the message unit price. Therefore the contractor will take over the costs of the LRIT messages, the CSP and the airtime costs including the costs of the LES According to the SOLAS convention the ship shall not incur any charges for transmitting LRIT information. Consequently, the ships reporting to the EU LRIT DC do not have to pay for their LRIT messages The billing scenario should be as follows: the ship pays no money, the CSPs invoice the ASP the ASP applies on each message an overhead cost and bills the Agency The contractor has to state explicitly the airtime costs of each communication network in its bid Tenderers should note that the prices offered will be compared to current commercial rates for single vessel position information. Given the messages to be procured under this contract, it is expected that prices offered should be lower than rates currently being paid by Member States The tenderer is requested to fill in all the prices for the bulk amounts listed in the tables below, which are available as an Excel template from the EMSA website (Tender Enclosure III) and to provide the worksheet in printed and in digital format together with the bid. Deviations or modifications to the tables are not allowed. Page 58 of 92

59 Unit costs INMARSAT C INMARSAT D+ IRIDIUM Further communication links as identified in Prices per LRIT message by ordering the following amount per year Less than 100, ,000 to 499, ,000 to 1.999, ,000 to 9.999, ,000 and more INMARSAT C INMARSAT D+ IRIDIUM Further communication links as identified in Prices per LRIT polling by ordering the following amount per year Less than 5,000 5,000 to 19,999 20,000 to 99, ,000 to 499, ,000 and more INMARSAT C Retrieving the ship related information (para ) Integration of vessel into the system (para ff.) INMARSAT D+ Retrieving the ship related information (para ) Integration of vessel into the system (para ff.) IRIDIUM Retrieving the ship related information (para ) Integration of vessel into the system (para ff.) Further communication links as identified in Retrieving the ship related information (para ) Integration of vessel into the system (para ff.) Prices per vessel integration in the system in number of vessel integrations per year Less than to to to and more Page 59 of 92

60 Fixed costs of the service Implementation costs related to developing/adapting the interface to the LRIT data centre and internally to the CSPs The setup-costs should cover all necessary adaptations of the system to be compliant with the existing and future LRIT related IMO specifications until the service is accepted for operational performance. Price for implementation Set-up and implementation costs Costs of further developments Further developments which might have to be undertaken due to changes in the LRIT specifications introduced by IMO after the service is accepted for operational performance. These developments should be charged on a time and materials basis where there should be fixed prices for one working day. Price of one day Senior specialist: programmer, engineer, manager (more than 10 years work experience) Project specialist: programmer, engineer, manager (more than 5 years work experience) Junior programmer, engineer, manager (less than 5 years work experience) Costs of conformity testing The type approval tests done by the ASP will be performed for the vessel owner. Therefore the vessel owner will be the ordering entity and responsible for the costs. The information and pricing on type approval tests within the bid will be made available to vessel owners via the EU Member States who are part of the EU LRIT system. The ASP is bound to provide the conformity test service to the vessel owners under the proposed conditions if requested by the vessel owner. Price for one conformity testing Costs for conformity testing of shipborne equipment to be compliant with the IMO specifications FINANCIAL GUARANTEE The Contractor will be required to establish a duly constituted financial guarantee before any pre-payment can be made by EMSA The Contractor will need to provide the financial guarantee in the form of a bank guarantee or equivalent supplied by a bank or an authorised financial institution (guarantor). Such a bank guarantee will need to be valid up to the maximum Page 60 of 92

61 amount requested as pre-payment. Any cost related to providing such a financing guarantee will be borne solely by the Contractor. 15. Information of the service provider This Article details the information concerning the personal situation of the service provider and information and formalities necessary for the evaluation of the minimum economic, financial and technical capacity required The tenderer should note the following very important points: Failure to submit relevant information by the tenderer will be a ground for rejection of their bid from the procurement process. The responsibility lies with the tenderer to verify that all documentation requested in this Invitation to Tender is provided LEGAL POSITION MEANS OF PROOF REQUIRED When submitting their bid, tenderers are requested to complete and enclose the Legal Entity Form and requested accompanying documentation, available on the Procurement Section (Legal Entity Form) on the EMSA Website at the following address: EXCLUSION CRITERIA Grounds for exclusion To be eligible for participating in this contract award procedure, tenderers must not be in any of the following exclusion grounds 6 : (a) they are bankrupt or being wound up, are having their affairs administered by the courts, have entered into an arrangement with creditors, have suspended business activities, are the subject of proceedings concerning those matters, or are in any analogous situation arising from a similar procedure provided for in national legislation or regulations; (b) they have been convicted of an offence concerning their professional conduct by a judgement which has the force of res judicata; (c) they have been guilty of grave professional misconduct proven by any means which the contracting authority can justify; (d) they have not fulfilled obligations relating to the payment of social security contributions or the payment of taxes in accordance with the legal provisions of the country in which they are established or with those of the country of the contracting authority or those of the country where the contract is to be performed; (e) they have been the subject of a judgement which has the force of res judicata for fraud, corruption, involvement in a criminal organisation or any other illegal activity detrimental to the Communities' financial interests; 6 Article 93 of Council Regulation (EC, Euratom) No 1605/2002 of 25 June 2002 on the Financial Regulation applicable to the general budget of the European Communities (OJ L 248 of ) Page 61 of 92

62 (f) following another procurement procedure or grant award procedure financed by the Community budget, they have been declared to be in serious breach of contract for failure to comply with their contractual obligations. For this purpose the Declaration of Honour available on the Procurement Section (Declaration of Honour) on the EMSA Website at the following address: shall be completed and signed. Bids that do not contain such a Declaration of Honour will not be taken into consideration for the evaluation Please note that prior to being awarded the contract the tenderer will have to provide additional proof evidencing eligibility EMSA shall accept, as satisfactory evidence that the tenderer is not in one of the situations described in point (a), (b) or (e) above, production of a recent extract from the judicial record or, failing that, a recent equivalent document issued by a judicial or administrative authority in the country of origin or provenance showing that those requirements are satisfied EMSA accepts, as satisfactory evidence that the tenderer is not in the situation described in point (d) above a recent certificate issued by the competent authority of the State concerned Where no such certificate is issued in the country concerned, it may be replaced by a sworn or, failing that, a solemn statement made by the interested party before a judicial or administrative authority, a notary or a qualified professional body in his country of origin or provenance SELECTION CRITERIA Economic and financial capacity means of proof required To prove their financial and economic capacity, tenderers should provide with their bid at least one of the following documents: (1) Appropriate statements from banks or evidence of professional risk indemnity insurance; (2) Balance sheets or extracts from balance sheets and profit and loss accounts for the last three financial years for which accounts have been closed, where publication of the balance sheet is required under the company law of the country in which the tenderer is established; (3) A statement of overall turnover and turnover relating to the relevant services for the last three financial years This documentation will be evaluated according to international company rating practice. The Agency reserves the right to request any documentary evidence it Page 62 of 92

63 deems necessary or useful in order to verify the candidates economic and financial standing For semi public or non-profit organisations, the annual budget of the last year should be submitted. If the requested documentation is not applicable, an appropriate justification must be provided Technical and professional capacity - means of proof required To prove their technical and professional capacity tenderers should provide proof of the following mandatory criteria with their application: Relevant experience: This proof will consist of a list identifying work carried out during at least the last three years that is of relevance and/or analogous to the services to be provided. This list should clearly show: a description of the services previously offered by the company/consortia, with an indication of the objectives, contracting parties, duration and budget the tenderers level of experience for the provision of services on an operational basis; Any evidence, statement or testimonial from the customer, from the public sector or private sector, relating to the performance and/or quality of the services previously provided by the tenderer Evidence of ASP/CSP functionality: to prove the functionality, the tenderers have to demonstrate their existing relationships with the CSP s, which will demonstrate their capability to receive LRIT data and ensure remote integration of the ship borne equipment via different communication networks Furthermore, if the tenderers have current or previous experience as an ASP on a national level this should be stated as well as the country Because of the international nature of the contract, the tender has to provide evidence to demonstrate their capabilities to offer all services under the present contract in the English language Tenderers should provide with their bid detailed curriculum vitae of the operational persons and the key technical and management persons who will be delivering the service under the proposed contract. The curriculum vitae shall include the educational background, degrees and diplomas, professional experience Tenderers should provide the number of staff working in the development team of the service and of staff working operationally on a 24/7 basis The tenderer shall submit a description of the operational facilities used to perform the tasks. The following components should be described: computing, archiving, networking and telecommunication infrastructure; hosting environment; electrical power supply system; disaster recovery site(s); all other facilities relevant for the provision of the service. Page 63 of 92

64 16. Criteria for the award of contract (according to Article 4) The contract will be awarded to the tenderer who submits the most economically advantageous bid (the best quality - price ratio) The award criteria which will be used have the following weighting: Technical award criteria (50%) Price award criteria (50%) TECHNICAL AWARD CRITERIA (50 POINTS) The service requirements are contained within Article 4 of this document. These requirements will be used by the Agency to assess the technical aspects proposed in the bids. To facilitate this evaluation, tenderers are requested to complete a compliance matrix (Annex A.4), which is available as an Excel template from the EMSA website (Tender Enclosure IV) and to provide the worksheet in printed and in digital format together with the bid. The compliance matrix will be used by the Agency to evaluate the bids for their level of compliance with the service requirements described in this document. A deviation or modification of the tables is not allowed A series of technical award criteria will be used to evaluate technical aspects of the products and services proposed by the company/consortia. These criteria are listed below, together with a short explanation and requests for supporting documentation. If the tenderer cannot meet the requirements fully, the tenderer must justify any deviation and must provide documentation on what alternative level of service it can provide, offering a similar quality, which has to be in compliance with the IMO specifications. EMSA reserves the right to disagree with the deviation and the proposed solution Whenever a particular characteristic is said to be an advantage within the technical description in Articles 3 and 4, it shall be understood, that the bids which fulfil such characteristics will be evaluated higher The tenderer must reach at minimum 60% of each technical award criteria in order to be considered for the tender Fulfilment of requirements (20 points) IMO Requirements The tenderer has to comply with all IMO Requirements for the LRIT system and as minimum meet the requirements indicated in Article 4.1. Due to the current refinements of the LRIT system at the IMO, the tenderer should always take into account the most recent specifications by IMO. System Performance Page 64 of 92

65 The ASP must be capable to process a high number of messages per year and ensure a high availability of the ASP system. The tenderer must provide documentation indicating its system performance and its compliance with all requirements in Article 4.2, particularly with the delivery of the individual LRIT messages within the required timeframe (Article 4.2.1) and the specifications on the network coverage (Article 4.2.2) Implementation The proposed implementation of the ASP/CSP system as described in Articles and 4.3 to 4.5 (except Security) will be analysed and evaluated accordingly by assessing the fulfilment of the requirements in general and particular the design, procedures and robustness of the system. Integration of ships in the system The tenderer will be evaluated on its procedures on how to set up the communication with the vessels identified by an IMO number delivered by the Agency (via its ship database ), integrate them into the EU LRIT system, and as a minimum comply with the requirements set out in Article 4.6 and 4.8 Type approval The tenderer has to draft in its bid the foreseen test procedure for the shipborne equipment taking into account the IMO LRIT requirements testing matrix. The procedure will be evaluated. Additional networks Additional networks will be analysed on their operational relevance and will be evaluated accordingly Quality of the system and quality assurance (10 points) The regular mechanism for system quality checking and assurance used to perform the tasks under the terms of the contract will be evaluated according to the requirements in Article 5 and additionally in terms of the procedures to check the overall functioning, performance and quality of the system Hosting and infrastructure (10 points) The tenderer shall show that it complies with all hosting and security requirements stated in Articles and 4.7. The hosting and security concept shall be described in the bid Tenderers shall describe the operational capacity for provision of services on a 365 day 24 hour basis, and availability of trained permanent operator personnel. Page 65 of 92

66 The operational facilities used to perform the tasks under the terms of the contract will be evaluated: computing, archiving, networking and telecommunication infrastructure; hosting environment; electrical power supply system; disaster recovery site(s); all other facilities relevant for the provision of the service The mechanism for data security used to perform the tasks under the terms of the contract will be analysed and evaluated Management (10 points) Strong project management is required for the execution of this service. Meeting deadlines for service application development, adaptation and roll-out are critical in light of the short time frame between the award of the contract and the schedule for a European wide service to be up and running. Consequently, tenderers must provide the following documents for evaluation; Proposed team structure and the involvement and interaction of each team member within the project. Outline Service Implementation Plan Draft project plan (showing tasks, schedule and milestones) for the service implementation Outline Service Test and Acceptance Plan End to end service test plan prior to service roll out, including user evaluation criteria PRICE AWARD CRITERIA (50 POINTS) The Agency will consider all price elements as award criteria for evaluation of the bids. The price evaluation will be done based upon the following scenario: First half year Second half 2 nd year of 3 rd year of of contract year of contract contract contract European flagged none Linearly 10,000 10,000 vessels under the increasing to LRIT service 9,000 Vessel integrations to the system 3,000 6,000 2,000 1,000 4 standard messages per day and per vessel The network distribution is as follows: 85% INMARSAT C and Mini C 10% INMARSAT D+ 5% IRIDIUM Page 66 of 92

67 Vessel integrations to the system: for 1/2 of the vessels the communication ID is not available Up to 10% of all requested messages might have to be checked Further developments will require 20 days of works for a Junior programmer, 10 days of works for a Project specialist and 10 days of works for a Senior specialist The set-up costs The evaluation will take the whole lifetime of the contract (3 years) into account The ceiling of LRIT messages according to IMO is specified at a price of 25 to 35 cents US. Nevertheless the present airtime costs are known to be at least less than 25% of this amount The ratio between the airtime costs and the prices of one message will be assessed. 17. Contracts will not be awarded to tenderers under special circumstances Contracts will not be awarded to tenderers who, during the procurement procedure: (a) are subject to a conflict of interest; (b) are guilty of misrepresentation in supplying the information required by the contracting authority as a condition of participation in the contract procedure or fail to supply this information. 18. Presentation of the bids to EMSA - Requirements as to the tender Each submission will be treated as an individual/unique bid and accordingly a full set of all relevant supporting documentation must be submitted with each bid Where equivalences and/or variants are being offered by the tenderer (with respect to the technical specifications), they must be duly motivated and justified It is important to note that: Bids can be submitted in any of the official languages of the EU. The working language of the Agency, as in the maritime industry, is English. Consequently, it would be highly appreciated if documents are submitted in English. Nevertheless bids must include a copy in English of the documents/information requested under Articles (Technical and professional capacity) and 16.1 (Technical award criteria) of the present tender specifications. Page 67 of 92

68 This includes: The name, phone number and of the persons who will be responsible for the technical and contractual management of any resulting contract and who would be nominated as such in the contract. The name, address, fax, phone number and of the tenderer s contact person to whom all communications related to the invitation to tender should be addressed. The name, address, fax, phone number and of each subcontractor proposed. The name of the author(s) of the Tender. References and experiences of the company or all companies involved in the consortium Tenderers must consider that failure to submit relevant information may be a ground for rejection of the bid from the procurement process Tenderers should ensure that the required documentation relating to the following points (at a minimum) are included in their bid(s) Tenderers are requested to present their bids in the following format and numbering scheme. This will aid evaluation as well as assisting tenderers in ensuring that all the required documentation is submitted PREFIX TO THE BID The tender must include: Signed cover letter indicating the name and position of the person authorised to sign the contract and the bank account on which payments are to be made Financial Form completed, signed and stamped: available on the Procurement PART A Section (Financial Form) on the EMSA Website at the following address: All the information and documents required by EMSA as the contracting authority for the appraisal of tenders on the basis of the Legal Position, Exclusion Criteria and Economic and Financial capacity (part of the criteria set out under Articles 15 of these specifications) For the contents please refer to the following Articles within this document A.1. Sub contracting (Article 13) A.2. Legal form to be taken by the grouping if service providers to whom the contract is being awarded (Article 12) A.3. Legal position (Article 15.1) Legal Entity Form A.4. Exclusion Criteria (Article 15.2) A.5. Economic and financial capacity (Article ) Page 68 of 92

69 18.3. PART B All the information and documents required by EMSA as the contracting authority for the appraisal of tenders on the basis of the Technical and professional capacity (part of the Selection Criteria) set out under Article of these specifications. Tenderers are requested to include a copy in English of the documents requested under this Article For the contents please refer to Articles within this document B.1. Relevant experience: This proof will consist of a list identifying work carried out during at least the last three years that is of relevance and/or analogous to the services to be provided. (Article ) B.2. Evidence of ASP/CSP functionality (Article ) B.3. Evidence of current or previous experience as an ASP on a national level (Article ). B.4. Evidence of operational capacity in the English language (Article ) B.5. Detailed curriculum vitae of the operational persons and the key technical and management persons who will be delivering the service under the proposed contract. (Article ) B.6. Evidence of the number of staff working in the development team of the service and of staff working operationally on a 24/7 basis. (Article ) B.7. Submit a brief description of the operational facilities. (Article ) PART C All the information and documents required by EMSA as the contracting authority for the appraisal of tenders on the basis of the Technical Award Criteria set out under Article 16.1 of these specifications; Tenderers are requested to include a copy in English of the documents requested under this Article. C.1. IMO Requirements (Article ) C.2. System Performance (incl. Operational capacity and latency timing) (Article ) C.3. Implementation (incl. a description of the supported networks and their data flows and coverage) (Article ) C.4. Integration of ships in the system (Article ) C.5. Type approval (Article ) C.6. Additional networks (Article ) C.7. Quality Assurance (Article ) C.8. Hosting (incl. data security concept) (Article ) C.9. Management (Article ) The fulfilment of the requirements have to be stated in a compliance matrix (Annex A.4), which is available as an Excel template from the EMSA website (Tender Enclosure IV) and to provide the worksheet in printed and in digital format together with the bid. C.10. Compliance matrix (see Article and the template in Annex A.4) Page 69 of 92

70 18.5. PART D: Setting out prices in accordance with Article 14 of these specifications required by EMSA as the contracting authority for the appraisal of tenders on the basis of the Price Award Criteria set out under Article 16.2 of these specifications; For the contents of the price breakdown tables please refer to Articles to within this document D.1. Prices per LRIT message by ordering X amount of messages per year D.2. Prices per LRIT polling by ordering X amount of messages per year D.3. Prices per vessel integration by ordering X amount of units per year. D.4. Set-up and implementation costs D.5. Further Development costs D.6. Costs of conformity testing The tenderer is requested to fill in all the prices (see Articles to for the tables) in the Excel template, which is available from the EMSA website (Tender Enclosure III) and to provide the worksheet in printed and in digital format together with the bid. 19. False declarations by tenderers Without prejudice to the application of penalties laid down in the contract, tenderers and contractors who have been guilty of making false declarations concerning situations referred to in Article 15 above or have been found to have seriously failed to meet their contractual obligations in an earlier procurement procedure or grant shall be subject to Administrative and financial penalties set out in Article 133 of Commission Regulation 2342/2002 of 23/12/2002. (OJ L 357 of 31/12/2002). 20. No commitment by the Agency Invitation to Tender does not bind the Agency in any way to place a contract, and the Agency reserves the right to place a contract for the whole or only part of the activities covered by the Invitation to Tender. 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. 21. Retention of tenders Any document submitted in reply to this Invitation to Tender shall become the property of the Agency, which will use proprietary information solely for the purpose of the evaluation of the Tender. 22. No reimbursement of tender expenses Expenses incurred in the preparation and dispatch of the Tender will not be reimbursed. Page 70 of 92

71 23. Information resources Companies/consortia are advised to consult the EMSA websites for links to reference documents and further information on LRIT. The following list is not exhaustive. EMSA website: Maritime Safety section. Through the Maritime Safety section there is access to a section on Technical Cooperation and then an area on EU Vessels Traffic Monitoring and then LRIT. There are a range of hyperlinks and documents. EMSA website: Procurement section. Through the Procurement section there is access to a range of hyperlinks and documents including: - Open call to tender EMSA/OP/06/08 - Service contracts for Delivery of ASP / CSP Services for the EU LRIT Data Centre - Open call to tender EMSA/OP/07/08 - Service contracts for Establishing EU LRIT DC services - Open call to tender EMSA/OP/08/08 - Service contracts for LRIT Invoicing and Billing services European Commission Website: - Maritime Transport area: Council Resolution from 2 October on the set-up of the EU LRIT system: - IMO Website: - Contains all the relevant documents on the LRIT system Page 71 of 92

72 Annex A.1. Reference Documents Id Reference Title R1 Directive 2002/59 R2 EMSA/OP/06/2008 R3 EMSA/OP/07/2008 R4 EMSA/OP/08/2008 R5 EU Council Resolution R6 MSC 83/6/1 R7 MSC 83/WP6/rev.1 R8 MSC 84/6/1/Add.1 R9 MSC 84/WP.8/Add.2 R10 MSC.1/Circ R11 MSC.1/Circ R12 Resolution A.887(21) R13 Resolution MSC.202(81) R14 Resolution MSC.210(81) R15 Resolution MSC.211(81) R16 Resolution MSC.242(83) R17 Resolution MSC.254(83) Directive 2002/59/EC of European Parliament and of Council of 27 June 2002 establishing a Community vessel traffic monitoring and information and repealing Council Directive 93/75/EEC Tender No. EMSA/OP/06/08 concerning contracts for Delivery of ASP / CSP Services for the EU LRIT Data Centre Tender No EMSA/OP/07/2008 for The development, implementation and operation of the EU LRIT Data Centre Tender No EMSA/OP/08/2008 for Service contracts for LRIT Invoicing and Billing services EU Council Resolution dated 2 October 2007 establishing an EU LRIT Data Centre (EU LRIT DC) Draft Technical specifications IMO LRIT report of the Working group Report of the 2nd Session of the Ad Hoc LRIT Group Draft report of the Maritime safety Committee on its 84 th session Guidance on the survey and certification of compliance of ships with the requirement to transmit LRIT information approved on May 2008 (replacement of MSC Circulaire 2843/corr.1) Available draft: MSC84/WP5/Add.2 Annex 3 Interim revised technical specifications for the LRIT system approved on May 2008 Available drafts: MSC84/WP5/Add.1 Annex 7 MSC 84/6/1/Add.2 Establishment, updating and retrieval of information contained in the registration databases for the global maritime distress and safety system (GMDSS) adopted on 25 November 1999 Adoption of amendments to the international convention for the safety of life at sea, 1974, as amended adopted on 19 May 2006 Performance standards and functional requirements for the long-range identification and tracking of ships adopted on 19 May 2006 amended by MSC 254(83) revised by resolution MSC.263(84) Arrangements for the timely establishment of the longrange identification and tracking system adopted on 19 May 2006, with subsequent changes in Draft MSC.1 Circular on Guidance on the implementation of the LRIT system (MSC 84/WP5/Add.2 - Annex 5) Use of LRIT for Maritime Safety and Environment protection purposes Amendments of Res.210(81) adopted on 12 October 2007 revised by resolution MSC.263(84) Page 72 of 92

73 Id Reference Title R18 Resolution MSC.263(84) Revised performance standards and functional requirements for the long-range identification and tracking (LRIT) of ships adopted on May 2008 Available draft: MSC84/WP5/Add.1 Annex 2 R19 Regulation 1406/2002 Commission Regulation (EC) No 1406/2002 of the European Parliament and of the Council of 27 June 2002 establishing a European Maritime Safety Agency R20 Regulation 2342/2002 Commission Regulation (EC, Euratom) No 2342/2002 of 23 December 2002 laying down detailed rules for the implementation of Council Regulation (EC, Euratom) No 1605/2002 on the Financial Regulation applicable to the general budget of the European Communities R21 Regulation 725/2004 Commission Regulation (EC) No 725/2004 of the European parliament and of the Council on enhancing ship and port facility security R22 SOLAS Regulation V/19-1 International Convention for the Safety of Life at Sea (SOLAS), 1974 (Chapter V - Safety of navigation, Regulation 19 - Carriage requirements for shipborne navigational systems and equipment) References in italic letters are obsolete. Page 73 of 92

74 Annex A.2. Abbreviations, acronyms and definitions AIS ADM AMN ASP BPEL COSS COTS CG CSP DBA DC DDP EIS EMSA EU EU MS ETL GUI IDC IDE IMO IMSO Automatic Identification System Administrator Administrator Manual Application Service Provider Business Process Execution Language Committee on Safe Seas and the Prevention of Pollution from Ships Commercial off-the-shelf Contracting Governments Communication Service Provider Database Administrator LRIT Data Centre LRIT Data Distribution Plan European Index Server European Maritime Safety Agency European Union European Member States Extract-Transform-Load process Graphical User Interface International LRIT Data Centre International LRIT Data Exchange International Maritime Organisation International Mobile Satellite Organisation LES LRIT MIO MSC MMSI NCA NPOC PKI PQP PSC QoS QoD RFP SAR Land Earth Station Long Range Identification and Tracking Monitoring Interface Operator Maritime Safety Committee (IMO) Maritime Mobile Service Identity National Contact Authority National Point Of Contact Public Key Infrastructure Project Quality Plan Port State Control Quality of Service Quality of Data Request for Proposal Search and Rescue SAR SURPIC Search and Rescue Surface Picture SOAP SOLAS SSL SWP TLS VPN WBS WS Simple Object Access Protocol International Convention for the Safety of Life at Sea Secure Sockets Layer Shipping Working Party Transport Layer Security Virtual Private Network Work Breakdown Structure Web Service Page 74 of 92

75 Annex A.3. Data format of LRIT messages INTRODUCTION This document contains the description of the messages used by the LRIT system as currently defined by IMO The LRIT messages are files written in the Extensible Markup Language (XML), version 1.1 ( The structure and content of the messages is described here using the XML Schema language ( Specification of XML and XML Schema are provided by the W3C Geo-information is represented using the Geographic Markup Language (GML), version ( an open standard recommended by the Open Geospatial Consortium. Important note: The structure of the messages could be slightly different at the time of the implementation of the EU LRIT Data Centre as they are still in the approval process of IMO. The Tenderers should take the version of MSC 84/6/1/Add.4 as a reference for the preparation of the bid, when available on the IMO website. The draft of the XML specifications is attached to this chapter. The definitive version will be provided by EMSA during the project Kick-off meeting The data format of the messages types 101 to 106 and the data format of the ship database will be drafted by the contractor of the EU LRIT DC and will be agreed between the contractor of the ASP (this tender) and the contractor of the EU LRIT DC (tender EMSA/OP/07/08) under the chair of the Agency (see ). IMO LRIT Messages The LRIT messages are used to enable the communication among the various components of the worldwide LRIT system. The information content is mainly represented by alphanumeric strings. In some cases a message is used as an envelope to transport a file as attachment. Common data types (file Types.xsd) Several data types are common in the LRIT messages and are defined separately in the file Types.xsd. <xs:schema xmlns:xs=" xmlns=" targetnamespace=" version="1.0"> <xs:simpletype name="lritidtype"> Page 75 of 92

76 <xs:restriction base="xs:string"> <xs:pattern value="[0-4][0-9]{3}"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="contractinggovernmentlritidtype"> <xs:restriction base="lritidtype"> <xs:pattern value="[1][0-9]{3}"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="sarservicelritidtype"> <xs:restriction base="lritidtype"> <xs:pattern value="[2][0-9]{3}"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="datacentrelritidtype"> <xs:restriction base="lritidtype"> <xs:pattern value="[3][0-9]{3}"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="asplritidtype"> <xs:restriction base="lritidtype"> <xs:pattern value="[4][0-9]{3}"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="ddplritidtype"> <xs:restriction base="lritidtype"> <xs:enumeration value="0001"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="idelritidtype"> <xs:restriction base="lritidtype"> <xs:enumeration value="0002"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="msgidtype"> <xs:restriction base="xs:string"> <xs:pattern value="([0-9]{4})(20[0-2][0-9])(0[1-9] 1[0-2])(0[1-9] [1-2][0-9] 3[0-1])([0-1][0-9] 2[0-3])([0-5][0-9])([0-5][0-9])([0-9]{5})"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="refidtype"> <xs:restriction base="xs:string"> <xs:pattern value="() (([0-9]{4})(20[0-2][0-9])(0[1-9] 1[0-2])(0[1-9] [1-2][0-9] 3[0-1])([0-1][0-9] 2[0-3])([0-5][0-9])([0-5][0-9])([0-9]{5}))"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="imonumtype"> <xs:restriction base="xs:integer"> <xs:mininclusive value="0"/> <xs:maxinclusive value=" "/> </xs:restriction> </xs:simpletype> <xs:simpletype name="shipnametype"> <xs:restriction base="xs:string"> <xs:minlength value="0"/> <xs:maxlength value="50"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="mmsinumtype"> <xs:restriction base="xs:string"> <xs:pattern value="[0-9]{9}"/> </xs:restriction> Page 76 of 92

77 </xs:simpletype> <xs:simpletype name="testtype"> <xs:restriction base="xs:integer"> <xs:enumeration value="0"/> <xs:enumeration value="1"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="ddpupdatetypetype"> <xs:restriction base="xs:integer"> <xs:enumeration value="0"/> <xs:enumeration value="1"/> <xs:enumeration value="2"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="responsetypetype"> <xs:restriction base="xs:integer"> <xs:enumeration value="1"/> <xs:enumeration value="2"/> <xs:enumeration value="3"/> <xs:enumeration value="4"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="latitudetype"> <xs:restriction base="xs:string"> <xs:length value="10"/> <xs:pattern value="([0-8][0-9]\.[0-5][0-9]\.[0-9][0-9]\.[nnss]) (90\.00\.00\.[nNsS])"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="messagetype"> <xs:restriction base="xs:string"> <xs:maxlength value="256"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="ddpversionnumtype"> <xs:restriction base="xs:string"> <xs:pattern value="[0-9]+\.[0-9]+"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="pricingversionnumtype"> <xs:restriction base="xs:positiveinteger"/> </xs:simpletype> <xs:simpletype name="longitudetype"> <xs:restriction base="xs:string"> <xs:length value="11"/> <xs:pattern value="([0-1][0-7][0-9]\.[0-5][0-9]\.[0-9][0-9]\.[eeww]) (180\.00\.00\.[eEwW])"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="locodetype"> <xs:restriction base="xs:string"> <xs:pattern value="[a-z]{2}([a-z0-9]){3}"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="imoportfacilitynumbertype"> <xs:restriction base="xs:string"> <xs:pattern value="[a-z]{2}([a-z0-9]){3}-[0-9]{4}"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="placecodetype"> <xs:restriction base="xs:string"> <xs:pattern value="[a-z]{3}([0-9]){3}"/> </xs:restriction> Page 77 of 92

78 </xs:simpletype> <xs:simpletype name="percentagevaluetype"> <xs:restriction base="xs:float"> <xs:pattern value="[0-9]*(.[0-9]{1,2})?"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="pricevaluetype"> <xs:restriction base="xs:float"> <xs:pattern value="[0-9]*(.[0-9]{1,4})?"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="currencytype"> <xs:restriction base="xs:string"> <xs:pattern value="[a-z]{3}"/> </xs:restriction> </xs:simpletype> </xs:schema> Ship Position Report message (types 1,2,3) This schema represents LRIT messages of type 1, 2, and 3 which contain the LRIT positional information sent by ships. <xs:schema xmlns:xs=" xmlns=" xmlns:lrit=" targetnamespace=" elementformdefault="qualified" version="1.0"> <xs:import namespace=" schemalocation="types.xsd"/> <xs:simpletype name="messagetypetype"> <xs:restriction base="xs:integer"> <xs:enumeration value="1"/> <xs:enumeration value="2"/> <xs:enumeration value="3"/> </xs:restriction> </xs:simpletype> <xs:element name="shippositionreport" type="shippositionreporttype"/> <xs:complextype name="shippositionreporttype"> <xs:sequence> <xs:element name="latitude" type="lrit:latitudetype"/> <xs:element name="longitude" type="lrit:longitudetype"/> <xs:element name="timestamp1" type="xs:datetime"/> <xs:element name="shipborneequipmentid" type="xs:string"/> <xs:element name="aspid" type="lrit:lritidtype"/> <xs:element name="cspid" type="lrit:lritidtype"/> <xs:element name="messagetype" type="messagetypetype"/> <xs:element name="messageid" type="lrit:msgidtype"/> <xs:element name="referenceid" type="lrit:refidtype"/> <xs:element name="imonum" type="lrit:imonumtype"/> <xs:element name="mmsinum" type="lrit:mmsinumtype" minoccurs="0"/> <xs:element name="timestamp2" type="xs:datetime"/> <xs:element name="timestamp3" type="xs:datetime"/> <xs:element name="dcid" type="lrit:lritidtype"/> <xs:element name="timestamp4" type="xs:datetime"/> <xs:element name="timestamp5" type="xs:datetime"/> <xs:element name="responsetype" type="lrit:responsetypetype"/> <xs:element name="datauserrequestor" type="lrit:lritidtype"/> Page 78 of 92

79 <xs:element name="shipname" type="lrit:shipnametype" minoccurs="0"/> <xs:element name="datauserprovider" type="lrit:lritidtype"/> <xs:element name="ddpversionnum" type="lrit:ddpversionnumtype"/> </xs:sequence> <xs:attribute name="test" type="lrit:testtype" use="optional" default="0"/> </xs:complextype> </xs:schema> Ship Position Request message (types 4,5) This schema represents LRIT messages of type 4 and 5 which contain the request parameters for LRIT positional information or SAR polling sent by LRIT Data User. <xs:schema xmlns:xs=" xmlns=" xmlns:lrit=" targetnamespace=" elementformdefault="qualified" version="1.0"> <xs:import namespace=" schemalocation="types.xsd"/> <xs:simpletype name="messagetypetype"> <xs:restriction base="xs:integer"> <xs:enumeration value="4"/> <xs:enumeration value="5"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="accesstypetype"> <xs:restriction base="xs:integer"> <xs:enumeration value="1"/> <xs:enumeration value="2"/> <xs:enumeration value="3"/> <xs:enumeration value="4"/> <xs:enumeration value="5"/> <xs:enumeration value="6"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="requesttypetype"> <xs:restriction base="xs:integer"> <xs:enumeration value="1"/> <xs:enumeration value="2"/> <xs:enumeration value="3"/> <xs:enumeration value="4"/> <xs:enumeration value="5"/> <xs:enumeration value="6"/> <xs:enumeration value="7"/> <xs:enumeration value="8"/> <xs:enumeration value="9"/> </xs:restriction> </xs:simpletype> <xs:complextype name="requestdurationtype"> <xs:attribute name="starttime" type="xs:datetime" use="required"/> <xs:attribute name="stoptime" type="xs:datetime" use="required"/> </xs:complextype> <xs:simpletype name="distancetype"> <xs:restriction base="xs:integer"> <xs:mininclusive value="0"/> <xs:maxinclusive value="9999"/> </xs:restriction> Page 79 of 92

80 </xs:simpletype> <xs:element name="shippositionrequest" type="shippositionrequesttype"/> <xs:complextype name="shippositionrequesttype"> <xs:sequence> <xs:element name="messagetype" type="messagetypetype"/> <xs:element name="messageid" type="lrit:msgidtype"/> <xs:element name="imonum" type="lrit:imonumtype"/> <xs:element name="datauserprovider" type="lrit:lritidtype"/> <xs:element name="accesstype" type="accesstypetype"/> <xs:choice> <xs:element name="port" type="lrit:locodetype"/> <xs:element name="portfacility" type="lrit:imoportfacilitynumbertype"/> <xs:element name="place" type="lrit:placecodetype"/> </xs:choice> <xs:element name="distance" type="distancetype"/> <xs:element name="requesttype" type="requesttypetype"/> <xs:element name="requestduration" type="requestdurationtype"/> <xs:element name="datauserrequestor" type="lrit:lritidtype"/> <xs:element name="timestamp" type="xs:datetime"/> <xs:element name="ddpversionnum" type="lrit:ddpversionnumtype"/> </xs:sequence> <xs:attribute name="test" type="lrit:testtype" use="optional" default="0"/> </xs:complextype> </xs:schema> Receipt message (type 7) This schema represents the LRIT message of type 7 which contains the receipt information in case of non-delivery of requested LRIT information. <xs:schema xmlns:xs=" xmlns=" xmlns:lrit=" targetnamespace=" elementformdefault="qualified" version="1.0"> <xs:import namespace=" schemalocation="types.xsd"/> <xs:simpletype name="messagetypetype"> <xs:restriction base="xs:integer"> <xs:enumeration value="7"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="receiptcodetype"> <xs:restriction base="xs:integer"> <xs:mininclusive value="1"/> <xs:maxinclusive value="256"/> <xs:enumeration value="1"/> <xs:enumeration value="2"/> <xs:enumeration value="3"/> <xs:enumeration value="4"/> <xs:enumeration value="5"/> <xs:enumeration value="6"/> <xs:enumeration value="7"/> <xs:enumeration value="8"/> <xs:enumeration value="9"/> </xs:restriction> </xs:simpletype> <xs:element name="receipt" type="receipttype"/> <xs:complextype name="receipttype"> Page 80 of 92

81 <xs:sequence> <xs:element name="messagetype" type="messagetypetype"/> <xs:element name="messageid" type="lrit:msgidtype"/> <xs:element name="referenceid" type="lrit:msgidtype"/> <xs:element name="receiptcode" type="receiptcodetype"/> <xs:element name="destination" type="lrit:lritidtype"/> <xs:element name="originator" type="lrit:lritidtype"/> <xs:element name="message" type="lrit:messagetype"/> <xs:element name="timestamp" type="xs:datetime"/> <xs:element name="ddpversionnum" type="lrit:ddpversionnumtype"/> </xs:sequence> <xs:attribute name="test" type="lrit:testtype" use="optional" default="0"/> </xs:complextype> </xs:schema> Page 81 of 92

82 Annex A.4. Compliance Matrix - List of Technical Requirements To facilitate the evaluation of the bid, tenderers are requested to complete the following compliance matrix, which is available as an Excel template from the EMSA website (Tender Enclosure IV) and to provide the worksheet in printed and in digital format together with the bid. The compliance matrix will be used by the Agency to evaluate the bids for their level of compliance with the service requirements described in this document. Page 82 of 92

83 Page 83 of 92

84 Page 84 of 92

85 Page 85 of 92

86 Page 86 of 92

87 Page 87 of 92

88 Page 88 of 92

89 Page 89 of 92

90 Page 90 of 92

91 Page 91 of 92

92 Page 92 of 92