ANNEX I - TENDER SPECIFICATIONS ATTACHED TO THE INVITATION TO TENDER

Transcription

1 ANNEX I - TENDER SPECIFICATIONS ATTACHED TO THE INVITATION TO TENDER Invitation to tender N EMSA /OP/07/2008 for the development, implementation and operation of the EU LRIT Data Centre Table of contents 1. BACKGROUND AND LRIT SYSTEM COMPONENTS BACKGROUND IMO REQUIREMENTS INTERNATIONAL LRIT SYSTEM GENERAL PROVISIONS LRIT CO-ORDINATION OBLIGATIONS OF THE CONTRACTING GOVERNMENTS (CG) LRIT DATA DISTRIBUTION PLAN (DDP) THE EU LRIT SYSTEM THE EU LRIT SYSTEM ARCHITECTURE THE SHIPBORNE EQUIPMENT, CSP AND ASP THE EU SHIP DATA BASE INVOICING AND BILLING SYSTEM THE SCOPE OF THE CONTRACT OBJECTIVE OF THE CONTRACT SERVICE MODULES OF THE CONTRACT SETTING-UP THE EU DC (MODULE 1) EU DC OPERATION (MODULE 2) TRANSFER OF EU DC TO EMSA (MODULE 3) TECHNICAL REQUIREMENTS EU DC GENERAL ARCHITECTURE EU LRIT DC USERS FLAG STATE LRIT INFORMATION PORT STATE LRIT INFORMATION COASTAL STATE LRIT INFORMATION SAR LRIT INFORMATION USER ROLES USER ACCESS RIGHTS EU DC FUNCTIONS MESSAGE PROCESSING PROCEDURES SHIP POSITION MESSAGES POSITION REQUEST MESSAGES SAR/SURPIC REQUEST MESSAGES RECEIPT MESSAGE SYSTEM STATUS MESSAGE BILLING AND PRICING MESSAGES...29 Page 1 of 105

2 4.4 EU DC JOURNAL EU DC INTERFACES AND ASSOCIATED OPERATIONAL PROCEDURES IDE INTERFACE DDP INTERFACE DDP UPDATING PROCEDURE DDP ENFORCEMENT PROCEDURE EU MS DATA SHARING PROCEDURE LRIT CO-ORDINATOR INTERFACE ASP INTERFACE ASP EU DC OPERATIONAL PROCEDURE SHIP DATA BASE INTERFACE SHIP DB UPDATING PROCEDURE USER INTERFACE USER LRIT DATA ACCESS PROCEDURE INVOICING AND BILLING INTERFACE STIRES INTERFACE STIRES PROCEDURE MONITORING INTERFACE MONITORING PROCEDURES MONITORING THE QUALITY OF DATA MONITORING THE QUALITY OF SERVICE USER MANAGEMENT PROCEDURES ERROR HANDLING THE STRUCTURE OF LRIT MESSAGES BASIC PRINCIPLES OF DATA FLOW TYPES OF LRIT MESSAGES TECHNICAL SPECIFICATIONS FOR COMMUNICATIONS SYSTEM HOSTING & SECURITY HOSTING OF THE SYSTEM DISASTER RECOVERY PLAN TRANSFER OF EU DC TO EMSA PREMISES DATA STORAGE DATA CAPACITY DATA BASE DESIGN PROCESSING PERFORMANCE REQUIREMENTS NETWORKING AND SECURITY PROJECT DELIVERABLES TESTING AND COMMISSIONING USER TEST CASES INITIAL DEVELOPMENT TESTING COMMISSIONING PROCESS QUALITY ASSURANCE HELP DESK AND TRAINING DELIVERABLES DOCUMENTATION CONTRACT MANAGEMENT RESPONSIBLE BODY PROJECT PLANNING PROJECT TIME TABLE PROJECT MANAGEMENT REPORTS TO BE SUBMITTED ESTIMATED VALUE OF THE CONTRACT TERMS OF PAYMENT TERMS OF CONTRACT GROUPINGS...78 Page 2 of 105

3 14. SUB CONTRACTING REQUIREMENTS AS TO THE TENDER PROCEDURES PRICE FINANCIAL GUARANTEE INFORMATION ON THE PROVIDER LEGAL POSITION MEANS OF PROOF REQUIRED GROUNDS FOR EXCLUSION ECONOMIC AND FINANCIAL CAPACITY TECHNICAL AND PROFESSIONAL CAPACITY OPERATIONAL CAPACITY CRITERIA FOR THE AWARD OF THE CONTRACT TECHNICAL AWARD CRITERIA PRICE AWARD CRITERIA CONTRACTS NOT TO BE AWARDED UNDER SPECIAL CIRCUMSTANCES PRESENTATION OF BIDS TO EMSA PREFIX TO THE BID PART A PART B PART C PART D: FALSE DECLARATION BY TENDERER NO COMMITMENT BY THE AGENCY RETENTION OF TENDERS NO REIMBURSEMENT OF TENDER EXPENSES INFORMATION RESOURCES...88 ANNEX A.1. REFERENCE DOCUMENTS...90 ANNEX A.2. ANNEX A.3. DEFINITIONS AND ABBREVIATIONS...91 DATA FORMAT OF LRIT MESSAGES...92 ANNEX A.4. COMPLIANCE MATRIX WITH TECHNICAL REQUIREMENTS Page 3 of 105

4 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 EU Council Resolution of 2 October 2007, EU Member States (MS) 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 within a range of 1000 nautical miles. The LRIT system will also contribute to the objectives of the Directive 2002/59 (Vessel Traffic monitoring) and Regulation 725/2004 on enhancing ship and port facility security. The possibility of collecting the EU ship data in a unique data-base 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 overseas countries and territories, subject to further discussion on the financial aspects of their participation and invites MS and the Commission to cooperate in order to define the technical, legal and political criteria of a possible participation of other third countries and the relevant modalities of such participation Annex A.1 summarises the various reference documents from the IMO and the EU which describe the relevant requirements and will be referred to throughout this document. 1.1 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). Contracting governments agreed that the system would enter into force on 1 January The objective of the LRIT system is the global identification and tracking of ships. The requirements concerning LRIT have been introduced into the SOLAS, 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) of 12/10/2007. Page 4 of 105

5 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 all LRIT Data Centres and the International LRIT Data Exchange should conform to functional requirements not inferior to those specified in the Annexes of the Resolution. In addition, it states that Contracting Governments to the SOLAS Convention should ensure that shipborne equipment used for LRIT purpose meet the requirements of the 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 84 th MSC meeting 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 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) and MSC (84), Contracting Governments 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 international LRIT system should receive, store and disseminate LRIT information on behalf of all Contracting SOLAS Governments. 1.2 International LRIT system General provisions The LRIT international system and architecture is based on the performance standards stated in IMO Resolution MSC 263(84) [replacing MSC 210(83)] It consists of the following components: a) the shipborne LRIT information transmitting equipment, b) the Communication Service Provider(s) (CSP), c) the Application Service Provider(s) (ASP), d) the LRIT Data Centre(s) (DC), e) the LRIT Data Distribution Plan (LRIT DDP) and DDP server, f) the International LRIT Data Exchange (IDE) These components and how they linked to each other are shown in Figure 1. The shipborne equipment first transmits the relevant LRIT data. The data flows from the vessel 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 LRIT Data Centre to enable the following minimum functionalities: a) remote integration of the shipborne equipment into an LRIT Data Centre; b) automatic configuration of transmission of LRIT information; c) automatic modification of the interval transmission of LRIT information; d) automatic suspension of transmission of LRIT information; e) on demand transmission of LRIT information; and f) automatic recovery and management of transmission of LRIT information. Page 5 of 105

6 The ASP also ensures that the LRIT information is collected and routed in a reliable and secure manner. Furthermore, and most importantly, the ASP and DC should add the following data to each transmission of LRIT information: a) ship identity (IMO ship identification number and the MMSI for the ship); b) the date and time the position report is received by the ASP; c) the date and time the position report is forwarded from the ASP to the appropriate LRIT Data Centre; d) the LRIT Data Centre identifier; e) the date and time the position report is received by the LRIT Data Centre; f) the date and time the position report is forwarded from the LRIT Data Centre to an LRIT Data User; The simplified Figure 1 below provides an overview of the LRIT components and the network connections between them. Satellites CSP IDE Other DC s IMO DDP CSP Data Centre Satellites ASP ASP - Adding MMSI/IMO number to datagram Users FIGURE 1 INTERNATIONAL 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). At present the temporary LRIT International Data Exchange will be established and operated by the United States on an interim basis. The IDE will route LRIT information between LRIT Data Centres The IMO will establish and maintain the LRIT Data Distribution Plan which will store the list of Contracting Governments and Search and Rescue services entitles to receive LRIT information and their contact details. Furthermore, they will also have information on the boundaries of geographic areas within each Contracting Government is entitled to receive LRIT information. These are detailed further in the IMO Resolution MSC 263(84) [replacing MSC 210(83)]. Page 6 of 105

7 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 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 According to the IMO Resolution MSC 263(84) [replacing MSC 210(83)] the LRIT communications using land-line links should provide for data security using methods such as authorization, authentication, confidentiality and integrity LRIT Co-ordination The performance of all LRIT Data Centres should be audited by the LRIT Coordinator acting on behalf of all SOLAS Contracting Governments. Specifically, the performance standards adopted by IMO Resolution MSC 263(84) [replacing MSC 210(83)] states that: The LRIT Co-ordinator should undertake a review of the performance of the LRIT system taking into account the provisions of SOLAS Regulation V/19-1, the present Performance standard and any related decisions of the Committee and should report its findings to the Committee at least annually The LRIT Data Centres should co-operate and make available the required information to the LRIT Co-ordinator such that an audit can be made of their performance MSC 82 appointed International Mobile Satellite Organization (IMSO) to be the LRIT Co-ordinator Obligations of the Contracting Governments (CG) According to MSC 263(84) [replacing MSC 210(83)], 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 to the selected LRIT Data Centre 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 before: 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. Page 7 of 105

8 1.2.4 LRIT Data Distribution Plan (DDP) The International Maritime Organization (IMO) establishes and maintains the LRIT Data Distribution Plan (DDP). According to Resolution MSC 263(84) [replacing MSC 210(83)] the LRIT Data Distribution Plan includes: a) a list of Contracting Governments and Search and Rescue services entitled to receive LRIT information, and their points of contact; b) simplified geographical information on the boundaries of geographic areas within which each CG is entitled to receive LRIT information about ships in the area; c) information on any Custom Coastal standing orders given by a Contracting Government; d) information supplied by Administrations pursuant to the list of Contracting Governments to which the LRIT information should not be provided (Exclusion List); e) a list of ports and port facilities together with the associated geographic coordinates (based on WGS 84 datum) located within the territory of each CG; f) a list of the National, Regional, Co-operative and International LRIT Data Centre(s) and their points of contact; and g) a record indicating which LRIT Data Centre is collecting and archiving LRIT information for each of the Contracting Governments The DDP will be populated by the Contracting Governments. The DDP will be made available by IMO to all Data Centres, the IDE and the LRIT Co-ordinator. Page 8 of 105

9 2 THE EU LRIT SYSTEM 2.1 The EU LRIT system architecture At system level, the main functions of the EU LRIT DC are to: a) Collect, store and archive the LRIT reports provided by the ships instructed by their Contracting Governments (CG) to report to the EU DC; b) Distribute the LRIT messages in accordance with DDP requirements; c) Provide, on request from another Data Centre, a LRIT report through the IDE; d) Request and process LRIT reports received from the IDE; e) Provide on request the LRIT report to the EU end users; f) Process the request received from the EU end users; g) Comply with the communication protocols established by IMO; h) Comply with the system performance requirements established by IMO; i) Comply with the system security requirements established by IMO; j) Support the external interfaces to the DDP server and IDE in compliance with IMO requirements; k) Support the auditing process and maintain journals; The interfaces connected to the EU DC and enabling the performance of its functions are: a) IDE interface; b) DDP interface; c) ASP interface; d) EU Ship Data Base interface; e) EMSA Monitoring interface; f) EU LRIT user interface; g) EMSA billing and costing interface; h) EMSA STIRES interface; The users of the EU LRIT DC shall be able to access the system through a web based user interface accessible via SafeSeaNet framework The Agency will use a web based monitoring interface to supervise the quality of the service and data within the EU Data Centre The general architecture of the EU LRIT system and the links between system s components are shown in Figure 2. Page 9 of 105

10 FIGURE 2 EU LRIT SYSTEM ARCHITECTURE Page 10 of 105

11 2.2 The shipborne equipment, CSP and ASP An LRIT message is transmitted from the ship via its shipborne equipment. The message includes the shipborne equipment identifier, positional data by latitude and longitude and the time stamp of transmission. This is transmitted via a satellite through the Communication Service Provider (CSP) to the Application Service Provider (ASP) The ASP then completes the LRIT information of the vessel by adding: a) ship identity (IMO identification number and the MMSI number for the ship); b) the date and time the position report is received by the ASP; c) the date and time the position report is forwarded from the ASP to the EU LRIT Data Centre; The new extended message generated by the ASP is then passed to the EU LRIT Data Centre that completes the ship identification with the ship name All of these links and data processing are made in automatic mode by using communication protocols in order to ensure the end-to end secure transfer of the LRIT information The Agency plans to outsource the ASP function through another public tender procedure (EMSA/OP/06/08). 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 ship via satellite and to send it 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 ). 2.3 The EU Ship Data Base An EU Ship Database (DB) Register is compiled by EMSA, based upon the information and subsequent updates provided directly by the Contracting Governments (Flag States) using the EU DC. The ship DB information is structured in accordance with IMO Resolution MSC 263 (84) [replacing MSC 210(83)] concerning the performance standards and functional requirements for LRIT The CG using EU DC will have direct access to populate and update their database through a web based interface. Only CG/Flag States can define which ships are obliged to report to the EU LRIT Data Centre. This ship DB register will have to be regularly updated by the competent Flag State Administration operator and will enable the EU DC and ASP to process the LRIT information relevant to the ships belonging to each CG. 2.4 Invoicing and billing system In the EU Council Resolution of 2 October 2007, it was decided that overseas territories and third states may be allowed to make use of the EU LRIT DC, subject to Council decision. If such is the case all costs for overseas territories and third countries shall be covered by each relevant country. Page 11 of 105

12 Furthermore, the cost of any additional LRIT message requested over the mandatory reports, either by an EU MS or a CG using the EU DC services, shall be covered by the requestor The EU LRIT DC therefore has to invoice in the following cases: a) EU MS requesting more than the mandatory messages for EU flagged vessels; b) Overseas territories for using the services of the EU LRIT DC; c) Third countries for using the services of the EU LRIT DC; d) EU MS requesting LRIT messages for non EU flagged vessels; The EU LRIT DC will receive income for messages of EU flagged vessels/eu DC registered vessels requested by other LRIT Data Centres via the IDE To perform the necessary invoicing and billing functions, the EU LRIT DC will be interfaced with an invoicing and billing system provided via EMSA to cover: a) Processing the LRIT journals received from EU DC for billing and invoicing purposes; b) Producing a price message for the EU DC to be forwarded to International Data Exchange (IDE) for dissemination to other DCs over the world; c) Producing financial journals (overviews); d) Provide information/statistics to verify incoming invoices (from the ASP and other Data Centres); e) Provide EMSA basic client information for the purpose of creating invoices; f) Provide information on the status of credits EMSA has with the ASP and the status of credits Member States and other clients have with EMSA. 3. THE SCOPE OF THE CONTRACT 3.1 Objective of the contract With this procurement procedure, EMSA intends to outsource the establishment, implementation, operation and maintenance of the EU LRIT Data Centre. The project aims to ensure the compliance of the EU MS with the SOLAS Convention, Chapter V ( Safety of Navigation ), Regulation 19-1 and respectively with IMO Resolutions MSC 202 (81) and MSC 263 (84) [replacing MSC 210(83)] on the LRIT system The objective of this contract is to establish and operate the EU LRIT DC that collects LRIT information from the ships of EU Member States, Norway and Iceland, and distribute the LRIT information in accordance with DDP rules established by IMO. In addition, the EU DC will ensure LRIT information exchange with other DCs around the world, via IDE Overseas territories may also use the services of the EU LRIT DC The proposed service contract is for a period of three years and is divided in three main modules covering three groups of services. Page 12 of 105

13 3.2 Service modules of the contract Setting-up the EU DC (module 1) The first module should cover the setting-up, installation, testing and commissioning of the EU DC in accordance with IMO requirements. The Contractor is requested to provide a description of the procedures and associated costs of this module, including at least the following aspects: a) Setting-up the core EU DC system (hardware and software); b) Setting-up the EU DC interfaces; c) Full system testing before commissioning, including download of the EU ship DB provided by EMSA and simulation of LRIT communication with ships; d) Training package for EMSA monitoring operators in using monitoring interface facilities; e) Training package for the user interface; f) Commissioning of the system with the LRIT Co-ordinator (IMSO); g) Integration of the EU DC into the international LRIT system; It is estimated that the first module will be developed within a maximum period of 6 months. The Contractor shall consider starting testing and integration of the EU ship DB as soon as possible after commencement of the project. The Contractor s ability to complete module 1 in a shorter timeframe than that requested (6 months) will be considered as an advantage EU DC operation (module 2) Following delivery and commissioning of the EU DC, the contractor shall ensure the daily operation and maintenance of the system in accordance with the IMO availability and performance criteria, including the annual auditing by IMSO The second module should cover the yearly operation and maintenance of the EU DC, at the Contractor s premises for the first two contractual years (the balance of the first contractual year after completion of Module 1 and the second contractual year) and at EMSA premises for the third year of the contract The Contractor is requested to structure his offer considering the following estimated operational timeframe for this module: a) Year the Contractor shall operate the EU DC at his own premises for the remaining period of the year following installation and commissioning of the system. The Contractor shall provide an indication of operational costs for this period. b) Year the Contractor shall operate the EU DC at his own premises for the full year An indication of the operational costs for the year of 2010 shall be provided. c) Year the Contractor shall operate the EU DC at EMSA premises for the full year The Contractor shall provide an indication of operational costs for the year of During the period of the contract, the Contractor shall provide 24/7 help desk for technical and operational purposes. The Contractor is also requested to provide assistance to EMSA in the works carried out within IMO LRIT working groups, LRIT Co-ordinator meetings, EU LRIT work-shops, EU Commission LRIT reporting and other LRIT developments, if any. Page 13 of 105

14 3.2.3 Transfer of EU DC to EMSA (module 3) The third module should cover the transfer of the EU DC site from the Contractor s premises to EMSA s premises at the end of This module shall cover: a) Equipment to be transferred and transfer procedures of the EU DC from Contractor s premises to EMSA s premises without affecting the availability and performance of the running system; b) Installation (hardware and software), configuration, testing and recommissioning, if necessary, of the system at EMSA s premises before starting the operation; c) Training for EMSA operators in order to takeover the operation and maintenance of the system at the end of the contract, including at least 4 months where the EU DC system will be run jointly, both by the Contractor and by EMSA operators. 4. TECHNICAL REQUIREMENTS All requirements given in this chapter will be subject to evaluation. For a better understanding, the main requirements of each section will be highlighted through the document in the form of a Requirements table applicable to the relevant section of the document 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 To achieve the best possible services 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 the requirements stated in this tender as well as the IMO standards EMSA asks the bidding companies to consider the full international 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 should comply with the provisions of SOLAS chapter Regulation V regulation 19-1 specified in MSC 202(81). The LRIT system is technically specified by the IMO Maritime Safety Committee document Resolution MSC 263(84) adopted on May Revised performance Standards and functional requirements for the LRIT of ships [replacing MSC 210(83)] and the MSC 1/Circ Interim revised technical specifications for the LRIT System. See Annex A.1 for full list of references The specifications within this document are developed on the basis of the IMO specifications. The bidder shall always consider the most recent IMO specifications for drafting the bid, even if these specifications are published after the release of this call tender. 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 bidder is asked to highlight this in the bid and to provide a solution according to these new IMO specifications. Page 14 of 105

15 4.1 EU DC general architecture The main objective of the EU LRIT DC is the identification and tracking of EU Flagged ships irrespective of where such ships may be located and the integration of the EU LRIT system into the international LRIT system to exchange LRIT information between all SOLAS Contracting Governments The EU DC shall be able to provide to the users with the following ship tracking services: a) Flag State ship tracking Flag State users shall be able to obtain the position of their vessels irrespective of where such ships may be located; b) Port State ship tracking Port State users shall be able to obtain the position of any vessel, irrespective of the flag, coming to one of its ports; c) Coastal State ship tracking Coastal State users shall be able to obtain the position of any vessel, irrespective of the flag, navigating within a maximum distance of 1000 Nm off its coastline; d) SAR ship tracking SAR Authority shall be able to obtain the position of any vessel, irrespective of the flag The EU DC will be initially located at the Contracting company premises and transferred to EMSA premises in Lisbon, Portugal, after two years. Further details on the transfer request are provided in sections and The EU DC interfaces enabling the performance of its functions and the location of the each interface end user are presented below: a) IDE interface the IDE is located at USCG Operations System Centre in Kerneysville, West Virginia, USA; b) DDP interface the DDP server is located at IMO, London, U.K. c) LRIT Co-ordinator the LRIT Co-ordinator is IMSO, located in London, U.K. d) ASP interface the ASP location will be advised by the Contracting company winning the ASP tender; e) EU Ship Data Base the EU Ship DB is located at EMSA, Lisbon, Portugal; f) EMSA Monitoring the EMSA monitoring operators are based at EMSA, Lisbon, Portugal; g) LRIT user interface the end users are the EU MS, Norway, Iceland and EU Overseas territories; h) Invoicing/Billing the billing is located at EMSA, Lisbon, Portugal; interface i) STIRES interface the STIRES/SSN is located for the time being at DIGIT, Luxembourg; Page 15 of 105

16 The EU DC architecture, including interfaces, is detailed in Figure 3 below: FIGURE 3 EU LRIT DC ARCHITECTURE Page 16 of 105

17 4.2 EU LRIT DC users The users of the EU DC are the Contracting Governments (CG) registered at the EU DC (EU MS, Norway, Iceland, Overseas Territories of the MS and, if positively decided by the EU Council, other Third countries). A CG participating in the EU DC may receive LRIT information pursuant to the provisions of SOLAS regulation V/19-1. Specifically, reference is made to: a) section for Flag State entitlement; b) section for Port State entitlement; c) section for Coastal State entitlements A CG participating in the EU DC, from a SAR perspective, may receive LRIT information pursuant to the provisions of SOLAS regulation V/19-1, section Each CG will nominate a National Competent Authority (NCA) that will access the system through the web interface provided by the EU DC. Several NCAs with different roles can be nominated by the same CG. An EU DC User is anyone designated by its NCA to represent a Flag State, Port State, Coastal State, or SAR service and authorized to request/receive/read LRIT information NCAs shall: a) designate its associated EU DC Users, delivering and maintaining their access rights to the EU LRIT network; b) ensure immediate updating of their fleet register within the EU ship DB whenever a change occurs; b) manage EU DC users in their respective countries through the Web interface provided by the EU DC; c) ensure at a national level the use of communication network compliant and compatible with the EU LRIT standards; d) establish appropriate arrangements with all of the EU DC Users in its national area regarding the management and monitoring of messages requested and received from the EU DC; e) be responsible for the payment of LRIT messages requested by any of its national users, in accordance with the relevant EU DC financial rules applicable to the respective NCA; In addition to the above mentioned users (CG), there are also other EU Institutional users. For the purposes of the EU LRIT system, the European Union Institutional users are: a) The European Commission, Directorate General for Transport and Energy (DG TREN) - On the basis of its legal obligation under Council Resolution 2821 dated 1-2 October 2007; the Commission represented by DG TREN assumes management responsibility for the LRIT system. b) The European Maritime Safety Agency (EMSA) - Established by Regulation 1406/2002 of the European Parliament and Council of 27th June EMSA assumes operational responsibility over the LRIT system, such as the technical management and monitoring of the EU DC. EMSA is also acting as the administrator of the LRIT system and will perform this role through a monitoring Web interface providing dedicated functionalities for performing such a responsibility, operated from EMSA headquarters by its operators. Page 17 of 105

18 4.2.1 Flag State LRIT information In accordance with SOLAS regulation V/19-1 all EU Members States, Norway and Iceland are entitled to receive the mandatory LRIT reports from the vessels flying their flag. In according with the EU Council resolution of 2 nd October 2007 the costs associated to the mandatory messages delivered to the EU MS, Norway and Iceland will be supported by EMSA using a dedicated EU LRIT budget Any other CG using the services of the EU DC, as approved by the EU Council (Overseas territories and/or Third countries) shall support directly all costs associated to EU DC services, including delivery of the mandatory LRIT reports Apart of the mandatory reports, a MS (CG) using the EU DC that wishes to receive additional LRIT information on one of its registered ships can either: a) send a request message to the EU LRIT Data Centre; or b) submit standing orders to the EU LRIT Data Centre regarding the criteria for receiving LRIT information for that particular ship The standing order request should comply with DDP requirements. The CG should use a LRIT request message to start tracking, stop tracking or alter the reporting rate of the LRIT information The reporting rate falling within the Community Budget is set to four daily LRIT reports (at every 6 hours) per EU flagged ship Port State LRIT information A CG participating in the EU DC that wishes to receive LRIT information as a Port State should send to the EU DC a standard request message filled in with applicable parameters as described within MSC 1/Circular 1259 (LRIT position request messages 4 and 5) If the CG wishes to stop receiving requested LRIT Port State information, it must send a request message to the EU Data Centre instructing the Data Centre to stop sending reports Coastal State LRIT information A CG using the EU DC that wishes to receive LRIT information as a Coastal State should provide to the DDP the standing orders regarding the criteria for receiving such information Another type of standing order concerns a given ship and it should include the distance from its coast within which the CG wishes to track the ship, the reporting rate and optionally, the flag of the ship. Thus, the EU DC will be capable of filtering LRIT data reports based upon a ship s distance from the CG coast The EU Data Centre will automatically check the incoming LRIT position reports of its registered ships against the standing orders and geographical boundaries contained in the DDP. Once the Data Centre has discovered a match, it will begin transmitting LRIT information to the entitled CG If the CG wishes to stop receiving LRIT information, it should actively send a request message to the EU Data Centre instructing the Data Centre to stop sending reports for this transit through the coastal state area The EU DC should continue to check the position of a ship that activated a standing order during the entire duration requested by the CG. If the ship exits and then re-enters the monitored area, the standing order should be re-activated by the EU DC without intervention by the requesting CG. Page 18 of 105

19 4.2.4 SAR LRIT information A CG that wishes to receive LRIT information as a SAR service should use either a SAR SURPIC Request Message or a Poll Request Message to obtain information A SAR SURPIC is typically used in the first stage of responding to a SAR incident. The SAR SURPIC will provide the SAR service with the ships within the requested area. The SAR SURPIC message will be sent to the IDE by the EU Data Centre. The IDE will broadcast the message to all Data Centres. Only Data Centres with a ship or ships within the specified SURPIC will respond to the SAR SURPIC message SAR Authorities should use a SAR poll request message to retrieve additional positional data on a particular ship within SAR incident area User roles Every EU LRIT DC user is assigned a role in the EU LRIT system which shall be designed to support a fixed set of attributes, as follows: Role Code LRIT_ADMIN LRIT_NCA LRIT DC user LRIT COM Description Role of the EU LRIT Monitoring interface operators, EMSA staff responsible for the monitoring and administration of the system; this role is equivalent to a system administrator Role of a LRIT National Competent Authority operator, responsible for setting-up and managing its own list of national LRIT users Role assigned to a user of EU DC, such as Flag State, Port State, Coastal State or SAR users, as established by the NCAs Role assigned to EUROPEAN COMMISSION entitled to check the performance and statistics of the EU DC. Table 1 - User Roles As each NCA is allowed to establish its own network of national EU DC users, it is not possible to provide an exact number of the users of the EU DC. It is expected that the total number of EU DC users will be continuously changing during the operation of the system, however, an estimation of the total number is in the range of 5000 users The EU LRIT DC shall provide the users with a communication user interface to help them to communicate with the system: a) A default browser-based web interface, enabling the EU LRIT users to manually send message request and manually receive the position reports which they requested (CG acting as data requester). This web application shall internally use the XML message-based interface to communicate with the EU LRIT DC. b) An XML message-based interface, enabling the EU LRIT end users, through their own applications, to send and receive XML messages fulfilling their needs The web based interface is of first priority and shall be developed by the Contractor as part of the system to be commissioned by the LRIT Co-ordinator, whilst the second interface (XML) shall be developed by the Contractor at a later stage, after commissioning of the EU DC. Page 19 of 105

20 4.2.6 User access rights Setting up the user access rights shall be configurable during the operation of the system, in accordance with the various user needs. The following access rights are to be established as a minimum: Access right Description Consult performance Access to the performance indicators of the EU DC Consult Journal Consult Journal per flag Consult Statistics Consult Statistics per flag Consult system log Request position rep. (one time poll) Request SAR SURPIC Manage users Manage Standing Order Search Vessel Consult ship position (most recent only) Consult ship position history Read-only access to the access logs of the EU DC, including a record of all writes and read operations. Read-only access to the journal of the EU DC, limited to data concerning the user s country; Access to statistical reports and analysis of the EU DC. Access to statistical reports and analysis on the activities of the EU DC for an identified country. Read-only access to the system log. Request a one time poll of a ship position Consult the most recent position of all ships in a given area Add/update/delete user, including grant or revoke access rights Add/update/delete standing orders (excluding Custom Coastal) Read-only access to the ship information, as stored in the EU Ship Database Consult most recent only ship position Consult any past ship position Table 2 - Access Rights The following table gives the set of access rights allowed for the pre-defined EU LRIT roles: Page 20 of 105

21 Role LRIT_ ADMIN LRIT_NCA EU_COM LRIT_USER Request position report N N N Y/N (one time poll) Manage Standing Order N N N Y/N Request SAR SURPIC N N N Y/N Consult ship position Y N N Y/N (most recent only) Consult ship position Y N N Y/N history Manage users Y Y* N N Search users Y Y* Y N Consult Performance Y Y Y Y/N Consult System Log Y N N N Consult Journal Y Y* Y Y/N Consult Statistics Y Y* Y Y/N Search Vessel Y N Y Y/N Note: Y*: -access only to its national users data Table 3 - Access rights of pre-defined Roles The EU LRIT MI Operator has the LRIT_ADMIN role Users with LRIT_NCA role are managed by the EU LRIT MI Operator. An NCA can also additionally assume the LRIT_USER role. Single Sign One procedure shall be implemented for a user assigned with different roles Individual access rights of the national users are managed by each NCA according to the previous table. Each time a national user is created/modified/deleted by the relevant NCA in charge, the EU MI operator will be notified accordingly A national user inherits the Country attribute of the NCA. If the user is a Port/Port Facility, one or more corresponding Locode should be set by the NCA as an attribute REQUIREMENT a) The Contractor shall provide a user structure and user access rights management in accordance with provisions contained within sections and b) The Contractor shall describe the user structure/access rights management procedures within the bid. Page 21 of 105

22 4.3 EU DC FUNCTIONS The functions of the EU DC as defined below, aims to ensure compliance with applicable IMO LRIT requirements and to satisfy the specific operational and financial particularities of the EU DC In particular, when preparing the bid, the tenderer should consider that the costs of the mandatory LRIT reports distributed to the EU MS, Norway and Iceland are paid by EMSA from a dedicated LRIT budget allocated by the European Community, whilst the costs of any additional LRIT messages requested by a MS/UE DC user, although initially paid by EMSA, have to be recovered from the requestor. This particular situation requires implementation of specific functions in the EU DC, above the IMO requirements, as detailed under the billing and invoicing interface section EU DC functionalities The Contractor shall provide an EU LRIT DC capable of performing the following functions: No. Function Requirements 1 The EU DC shall establish and The Contractor shall ensure that: continuously maintain systems which ensure, at all times, that EU LRIT Data a) The EU DC shall be fully compliant with the requirements contained in the IMO Users are provided with the LRIT LRIT documents (Resolution information they are entitled to receive as specified in SOLAS regulation V/19-1; MSC.202(81)/ Resolution MSC.263(84) /Resolution MSC 254 MSC.1/Circ.1259) and as such able to be integrated into the international LRIT system ; b) The EU DC shall be commissioned and audited annually by the LRIT Coordinator; c) DDP rules are properly implemented and the EU DC users receive only the data which they are entitled to under DDP provisions; d) The performance of the EU DC is continuously monitored by EMSA through a web based Monitoring interface which allows verification of the LRIT data distribution process; 2 The EU DC shall collect LRIT information from ships instructed by their Administrations to transmit the LRIT information to the EU DC; The Contractor shall develop the EU DC to be able to: a) Interact with the list of ships instructed to report to the EU DC which is collected and maintained within the EU LRIT Ship Data Base hosted at EMSA; b) Support XML/SOAP message format for downloading the EU ship DB. The operational procedure describing EU ship DB downloading process is described in section ; c) Interact with the ASP(s) to receive the messages send by the ships and to perform schema validation; d) Alert the MI operators when a ship stops transmitting LRIT information as requested; Page 22 of 105

23 3 The EU DC shall be able to obtain, when requested to provide LRIT information transmitted by ships other than those which transmit the information to the centre, LRIT information from other LRIT Data Centres through the International LRIT Data Exchange; 4 The EU DC shall be able to make available, when requested to provide LRIT information transmitted by ships other than those which transmit the information to the centre, LRIT information transmitted to the centre to other LRIT Data Centres through the International LRIT Data Exchange; 5 The EU DC shall execute requests received from EU LRIT Data Users for polling of LRIT information or for change(s) in the interval(s) of transmission of LRIT information by a ship or a group of ships transmitting the information to the centre; 6 The EU DC shall relay, when required, requests received from LRIT Data Users through the International LRIT Data Exchange to the other LRIT Data Centres for polling of LRIT information or for change(s) in the interval(s) of transmission of LRIT information by a ship or a group of ships not transmitting the information to the centre; To fulfil this function, the Contractor shall ensure that the EU DC is: a) Integrated and compatible with the international LRIT system as required in applicable IMO LRIT documents (Resolution MSC.202(81)/ Resolution MSC.263(84) / MSC.1/Circ.1259); b) provided with an IDE interface compliant with IDE operational standards, as detailed in applicable IMO LRIT documents (Resolution MSC.202(81)/ Resolution MSC.263(84) / MSC.1/Circ.1259); c) able to apply the DDP rules when requesting/distributing LRIT data from ships other than those required to transmit the information to the EU DC; The Contractor shall ensure that EU DC: a) is integrated into the international LRIT system as required in applicable IMO LRIT documents (Resolutions MSC.202/ MSC.263 /MSC.1/Circ.1259); b) is compatible with IDE and other DCs operated worldwide; c) applies relevant DDP rules when distributing the LRIT data; d) when connectivity issues occur, attempt redelivery of a message 3 times in 9 minutes to the IDE, before sending a fault message; The Contractor shall: a) observe applicable rights of the requester with respect to LRIT data as stated in DDP/standing orders rules; b) comply with applicable IMO LRIT documents related to ASP / DC interface (Resolutions MSC.202/ MSC.263 / MSC.1/Circ.1259); c) comply with the messages processing procedures described in section 4.3.2; d) ensure that if the requests are not processed on time, as per IMO performance requirements, the EU DC shall alert the user and the EU MI operator accordingly; The Contractor shall ensure that, when answering to a relay request, the EU DC: a) observes the applicable rights of the requester with respect to LRIT data as stated in DDP/standing orders rules; b) cooperates with other DCs via the IDE in accordance with applicable IMO LRIT documents (Resolutions MSC.202/ MSC.263 / MSC.1/Circ.1259); c) complies with messages processing procedures described in section 4.3.2; Page 23 of 105

24 7 The EU DC shall execute requests received through the International LRIT Data Exchange from other LRIT Data Centres for polling of LRIT information or for change(s) in the interval(s) of transmission of LRIT information by a ship or a group of ships transmitting the information to the centre; 8 Upon request, the EU DC shall disseminate to LRIT Data Users the EU LRIT information they are entitled to receive in accordance with the DDP arrangements and shall notify the LRIT Data User / the Administration when a particular ship stops transmitting LRIT information; 9 The EU DC shall archive LRIT information from ships that transmit the information to the centre, for a two years period and save the two years archive on separate dedicated repository support that guarantee the data preservation. The archived LRIT information should provide a complete record of the activities of the EU DC between two consecutive annual audits; 10 For LRIT information archived within the last 4 days, the EU DC shall send the LRIT information to the requestor within 30 minutes of receiving a request; For LRIT information archived between 4 and 30 days previously, send the LRIT information within 1 h of receiving a request; For LRIT information archived more than 30 days previously, send the LRIT information within 5 days of receiving a request; The Contractor shall ensure that, when executing requests received via the IDE from other DCs, the EU DC: a) observes applicable IMO LRIT documents related to DCs / IDE interface (Resolutions MSC.202/ MSC.263 / MSC.1/Circ.1259); b) observes applicable rights of the requester with respect to LRIT data as stated in DDP/standing orders rules; c) complies with messages processing procedures described in section 4.3.2; To fulfil this function the Contractor shall: a) provide a DDP interface able to download the latest DDP version from IMO server, as detailed in section ; b) ensure automatic checking of the DDP requirements / standing orders; c) ensure that the EU DC is always using the latest DDP for checking and performing the distribution of LRIT data; d) implement an automatic alerting system providing the EU MI operator and the relevant user with an alert when a particular ship stops transmitting required LRIT information; The Contractor shall address the following key requirements for archiving: a) redundancy - should include hot swapping and the capability to move to an off-site centre within 1 hour; b) recovery - data can be easily retrieved; c) restore - the data can be restored to its original format for recovery procedure after failure or reprocessing for auditing or internal investigation purposes; d) integrity - the data is preserved in its original state; e) availability the data is available for audit purpose as requested by the LRIT Co-ordinator; To meet this requirement, the Contractor shall provide: a) archiving of all LRIT messages processed by the EU DC; b) a time reference mechanism within the EU DC to ensure compliance with the stipulated time-bar for providing archived LRIT information; c) provide a monitoring and alerting tool able to notify the MI operators each time a non-compliance of response requirements is detected; d) archiving the times of receiving and answering a request; e) enabling auditing of response performance; Page 24 of 105

25 11 The EU DC shall ensure using appropriate hardware and software, that LRIT information is backed-up at regular 24 hours intervals, stored at suitable off-site location(s) and available as soon as possible in the event of disruption to ensure continuity of service; 12 The EU DC shall maintain a record of the ships which transmit LRIT information to the centre including name of ship, IMO Ship identification number, call sign, Maritime Mobile Service Identity (MMSI) and the flag; 13 The EU DC shall use a standard protocol for communications and a standard secure transmission method with the International LRIT Data Exchange; 14 The EU DC shall use a secure authentication method with LRIT Data Users; 18 The EU DC shall use a standard and expandable message format for communicating with the International LRIT Data Exchange; 19 The EU DC shall use reliable connections (e.g. TCP) to ensure that the LRIT information is successfully received by the LRIT Data Centres via IDE; The Contractor shall: a) implement regular 24 hours back-up procedure for all data handled by the EU DC and shall store the back-up data at an off-site location where data can be easily available; b) observe the additional hosting and security requirements as detailed in this document, section 6; c) propose and implement suitable emergency procedures for Business Continuity Plan as part of the Operational Manual of the system; The Contractor shall ensure that EU DC: a) downloads the list of ships instructed to report to the EU DC which is collected and maintained within the EU LRIT Ship Data Base provided by EMSA; b) maintains its own record of ships based on the LRIT reports received via ASP from each ship; c) is able to compare the record of reporting ships with the ship DB record in order to check the ships reporting compliance; The Contractor shall refer to and ensure compliance with: a) the IMO revised technical specifications as provided by MSC.263.(84) [replacing MSC 210(83)]; b) the EU DC IDE interface as detailed in section of this document; c) the data communication security requirements detailed in sections 5.3 and 6.8; The Contractor shall refer to: a) the IMO revised technical specifications for communication within the LRIT system (MSC ); b) the EU DC User interface as detailed in section of this document; The Contractor shall refer to and ensure compliance with: a) the IMO revised technical specifications for communication within the LRIT system (MSC ); b) the EU DC IDE interface as detailed in section of this document; c) the LRIT messages structure and format detailed in section 5; The Contractor shall refer to and ensure compliance with: a) the IMO revised technical specifications for the LRIT system (MSC ); b) the EU DC IDE interface as detailed in section of this document; Page 25 of 105

26 20 The EU DC shall add the appropriate data, as requested by IMO Res. 263(84) (Table 2), to each transmission of LRIT information collected by the centre 21 When providing archived LRIT information to LRIT data Users, EU LRIT DC should utilize the version of the LRIT Data Distribution Plan which was applicable at the time when the LRIT information requested was originally received. 22 The EU DC shall provide to Search and Rescue (SAR) authorities, the LRIT information transmitted by all ships located within the geographic area specified by the SAR service requesting the information so as to permit the rapid identification of ships which may be called upon to provide assistance. 23 The EU DC shall provide functionalities for the fleet simultaneous visualisation of LRIT information by the users and Monitoring interface operators. The Contractor shall refer to and ensure compliance with: a) the EU DC ASP interface as detailed in section of this document; b) the EU DC DB interface as detailed in section of this document; c) the messages processing section 4.3.2; The Contractor shall ensure that the EU DC is able to: a) archive all LRIT messages as required by IMO Res 263(84); b) archive the LRIT Data Distribution Plan covering the time period of the archived LRIT information (2 years); c) link every LRIT message to the DDP version in force at the time of handling the respective message; The Contractor shall ensure that EU DC is able to: a) provide LRIT information irrespective of the location of the geographic area, even if the geographic area is outside the search and rescue region associated with the SAR service requesting the information (refer to Regulation V/ ); In designing this functionality, the Contractor shall: a) provide a web interface able to display graphical information on an electronic map in real time, for one or more vessels at a time, at the user/mi operator actual location; b) include within the visualisation tool the availability of data analysis, such as replay, review of traffic movements both in reverse and forwards mode, traffic numbers, types, areas of navigation; Table 4 EU DC functions REQUIREMENTS a) The Contractor shall develop and deliver an EU DC performing all functions detailed in section (Table 4 EU DC functions). b) The Contractor shall provide a complete set of operational procedures for all functions enumerated in section above. c) Each of the EU DC operational procedures shall be covered by practical trainings for MI Operators and relevant Users. d) Functionality and procedures not covered by section 4.3 but identified during the development phase, as well after final FAT acceptance, shall also be implemented following approval by EMSA. Page 26 of 105

27 4.3.2 Message processing procedures Communication within the EU LRIT system is based upon three types of messages passing between various components of the system: a) LRIT ship position report message = message containing ship position data; b) LRIT request messages = messages requesting specific LRIT information; c) Other system messages = various messages passing through the system (pricing, billing, DDP, system status, etc); The EU DC shall process all LRIT messages received from the ASP, IDE and LRIT Data User interfaces. The full list and structure of the LRIT messages is described in Section 5 The Structure of LRIT messages The EU DC shall fill in all messages according to the Parameter provided By column within the tables in the Technical Specifications for Communications in the LRIT System. The EU DC shall identify the message type parameter of the LRIT message received The EU DC shall be responsible for formatting the LRIT messages as specified in Table 2 of the IMO revised Technical Specifications for Communication in the LRIT system The following, is a description of how the EU DC shall process each type of LRIT message Ship position messages The LRIT ship position messages are intended to provide EU DC users with the positional information pertaining to the ships tracked by the respective user For LRIT Messages Type 1, 2 and 3 (LRIT Ship Position Report Messages):.1 The EU DC shall check the received LRIT ship position report message from the ASP interface against the standing orders established in the DDP or received from EU users. If a match is identified, then the message is processed and delivered to the appropriate user, in addition to relaying the message to the data storage function for archiving..2 The EU DC shall read the LRIT Data User requestor parameter of positional messages it receives from the IDE interface. This information is required in order to determine which LRIT Data User shall receive the message. The IDE Interface shall relay the message to the LRIT Data User interface, which will send the message to the appropriate LRIT Data User Position request messages The LRIT position request messages are intended to provide the EU DC users with the ability to poll a specific position, change the reporting rate of a ship, query archived position messages or stop receiving reports from a given ship. The IMO number shall be used as the primary method for identifying a ship. If the EU DC is receiving multiple request messages from different requestors requiring different transmission intervals, the EU DC shall set the ship s terminal transmitting interval to the fastest requested periodic rate. The EU DC should prioritize requests based upon the time of receiving the request. For further details, refers to IMO revised Technical Specifications for Communication in the LRIT system For LRIT Messages Type 4 and 5 (Request Messages): Page 27 of 105

28 .1 LRIT messages received from the LRIT Data User interface or the IDE interface that have been identified as ship position request messages or SAR poll request messages shall be checked to determine if the ship of interest is reporting to the EU DC..2 Request messages from the LRIT Data User interface associated with ships that are not registered to the EU DC shall be relayed to the IDE..3 Request messages from the IDE interface associated with ships that are not registered to the EU DC shall result in an error. A Receipt Message with the appropriate receipt code shall be sent via the IDE to the Data Centre originating the request..4 Request messages associated with ships reporting to the EU DC shall be processed to determine if the requesting LRIT Data User is eligible to receive the information requested in accordance to the DDP..5 LRIT Data Users that have issued request messages for data they are not entitled to receive shall be notified thereof..6 LRIT request messages received at the LRIT Data User interface and associated with ships not reporting to the EU DC will be sent to the IDE..7 LRIT request messages received at the IDE interface or LRIT Data User interface will; 7.1. if it is a poll, a stop or a change of periodic reporting interval, be sent to the ASP interface if it is a request for archived data, be passed on as a request to Data storage and handling SAR/SURPIC request messages This message provides SAR authorities with the ability to obtain a picture of ships in a given geographical area where a SAR incident has occurred. This message requests the most recently archived data, within last 24 hours, from the EU DC database For LRIT Message Type 6 (SAR SURPIC Request Message):.1 SAR SURPIC Request Messages received at the LRIT Data User interface shall be sent to the IDE for broadcasting to all Data Centres in addition to being processed by the EU DC..2 The EU DC shall respond to SAR SURPIC Request Messages with the requested number of positions for each ship located within the SURPIC, irrespective of the worldwide location of the SURPIC..3 If there are no positional data messages to send, then the EU DC shall send a Receipt Message to the LRIT Data User that sent the SAR SURPIC Request Message Receipt message The receipt message is issued in order to acknowledge the receipt of an LRIT request message that can not be processed for some reason. When EU DC receives a request message it should process the request and either send the requested information or send a receipt message with the appropriate receipt code informing the requestor why the request message could not be fulfilled. For details on this type of message and associated codes refer to Table 5 of the IMO Draft Technical Specifications for Communication in the LRIT system For Message Type 7 (receipt messages) the EU DC shall process receipt messages and store a copy of the messages in its data storage. Page 28 of 105

29 4.3.7 DDP related messages The DDP related messages (type 8, 9 and 10) are used for regular updating of the DDP from the IMO DDP server. For details, refer to IMO Draft Technical Specifications for Communication in the LRIT system For Message Type 8 (DDP Notification Message) the EU DC shall process the DDP Notification Message and ensure that EU DC has the most recent version by sending a DDP Request Message to the DDP server according to the DDP updating operational procedures For Message Type 9 (DDP Request Message): 1. The EU DC shall transmit the DDP Request Message to the DDP server. 2. The EU DC can either request an immediate, a regular or a full DDP update. It is recommended that incremental updates be used whenever possible For Message Type 10 (DDP Update Message): 1. The EU DC shall update the DDP in accordance with the received DDP Update Message. 2. The EU DC shall be capable of processing both a full and incremental update of the DDP The sequences of the DDP updating process are detailed in the operational procedure System status message A system status message is received from IDE every 30 minutes to provide EU DC with health information on the IDE. Similarly, the EU DC shall transmit every 30 minutes a system status message to IDE informing on EU DC s health For Message Type 11 (System Status Messages) the EU DC shall notify the MI operator if it receives a System Status Message that indicates that there is an LRIT system problem or if it has not received a System Status Message during the last 40 min Billing and Pricing messages The billing and pricing messages are designed to support the financial viability of the LRIT system. The EU DC shall transmit to IDE on a regular basis a Billing and Transaction message containing a file with the summary of all message transactions and billing information concerning the messages routed internally by the EU DC. Pricing notification, request and updated messages are circulated between EU DC and IDE for the purpose of updating pricing lists in use for charging the messages For Message Type 12 (Billing and transaction Report) the EU DC shall generate and send a periodic Billing and Transaction message to the IDE Interface in accordance with the Draft LRIT Costing and Billing Standard For Message Type 13 (Pricing Notification) the EU DC shall process the Pricing Notification message received from IDE and ensure that the EU DC has the most recent version by immediately sending a Pricing Request message (Message Type 14) in accordance with the Draft LRIT Costing & Billing Standard For Message Type 14 (Pricing Request) the EU DC shall transmit the Pricing Request Message to the IDE to require an updated copy of the price list of another DC. Page 29 of 105

30 For Message Type 15 (Pricing Update) whenever the EU DC is issuing a new price list for its services, a pricing update message shall be sent to IDE for distribution to other DCs REQUIREMENTS a) The Contractor shall take into account the message processing procedures described above and shall ensure compliance with these operational procedures. b) For further details on messages processing the Contractor shall refer to and shall ensure full compliance with the IMO Draft Technical Specifications for Communication in the LRIT system document. c) The Contractor shall provide an integrated transaction management system for processing and monitoring of all LRIT information throughputs and routing, and shall ensure that the information is collected, stored and routed in a reliable and secure manner. d) The Contractor shall ensure that EU DC is able to process all types of IMO pre-defined messages. e) The Contractor shall ensure that EU DC is able to process any additional message related to the overall operational needs of the EU LRIT system, as long as the message is defined in XML format The diagram below illustrates the message processing flow within the EU DC. Page 30 of 105

31 Figure 5 LRIT messages processed by EU DC Page 31 of 105

32 4.4 EU DC JOURNAL EU DC shall maintain journal(s) for all messages routed through the system. The purpose of the Journal(s) is to enable the EU LRIT Data Centre to trace, record and archive the identification of the LRIT messages to support: a) auditing; b) message handling / distribution; c) the information required for the EMSA billing and invoicing system; d) usage and performance statistics The journal(s) should only contain message header information. The journal of messages internally routed by the EU DC should be transmitted to the IDE at the end of each month in order to be combined with the journal(s) maintained by the IDE Data from the Journal(s) may be requested by: a) the LRIT Co-ordinator for auditing purposes; b) LRIT Data Users for their own traffic; c) the European Court of Auditors, for auditing purposes; d) the EU Commission; e) IDE / LRIT Data Centres; f) Application Service Provider; g) the billing entity The EU LRIT DC have to log all messages relating to the request for LRIT positional data in a manner that facilitates the ready identification of individual transactions and provides an audit trail to identify: a) each Request Message received from individual LRIT Data Users; b) the communications with other LRIT Data Centres; and c) the subsequent delivery of the Response Message to the Requesting LRIT Data User The LRIT Co-ordinator and monitoring interface operators shall be able to query the journal by a web interface. The monitoring interface operators of EMSA shall have access to the full information contained in the journal The content of the journal should include: a) all LRIT messages internally routed within the EU DC, including messages exchanged between two EU DC users, i.e. position requests/reports of EU flagged ships; b) The timestamp of all messages (with the receiving and transmitting timestamps and as Universal Co-ordinated Time (UTC).); c) the content of the messages as defined in the Technical Specifications for Communication within the LRIT System in the original native XML format based upon the defined schema for the enclosed message; d) the identification of the user/requestor that requested the message; REQUIREMENT a) The Contractor shall ensure journaling of all activities and messages within the EU DC. b) The Contractor shall propose a journal structure meeting the above mentioned functions and requirements. c) The Contractor shall ensure full compliance of the journaling function with IMO requirements (Resolution MSC.202/ Resolution MSC.263 / MSC.1/Circ.1259); Page 32 of 105

33 4.5 EU DC INTERFACES AND ASSOCIATED OPERATIONAL PROCEDURES This section of the document describes the EU DC interfaces with other components of the EU and International LRIT systems and the functionalities and operational procedures which have to be developed by the EU DC Contractor to ensure proper interconnection and operation of the EU DC within the whole EU/International LRIT system IDE interface For the integration of the EU DC into the International LRIT system and data exchange with the other DCs around the world, the EU DC shall be provided with an International Data Exchange (IDE) interface fully compliant with the requirements and specifications stipulated in IMO LRIT Performance Standards [MSC 263(84)] The Contractor shall implement an EU DC IDE interface able to: a) Establish a secure Internet connection between the EU DC and the IDE based upon the communication and data security protocols outlined in the Draft Technical Specifications for Communication in the LRIT System ; b) Ensure processing and delivery of relevant EU DC LRIT information to the IDE, including EU DC system status message; c) Ensure that EU DC is always using the correct version of the DDP; d) Respond to all queries from other DCs and ensure that EU DC can obtain, when requested, LRIT information transmitted by ships other than those that transmit information to the EU DC, from other LRIT Data Centres, through the IDE; e) Relay, when required, requests received from EU DC Users through the IDE for polling of LRIT information or for change(s) in the interval(s) of transmission of LRIT information by a ship or a group of ships not transmitting the information to the EU LRIT DC; f) Ensure regular transmission of the EU DC journal to IDE; REQUIREMENTS a) The Contractor shall develop the IDE interface fully compliant with the requirements contained in the IMO LRIT document MSC.1/Circ.1259; b) The communication between EU DC and IDE will be done via XML messages over a secure data link; c) The Contractor shall ensure that the IDE interface is processing all messages circulating between EU DC and IDE (LRIT reports, status message reports, DDP upgrading reports, pricing, reports, journal files, etc); d) The Contractor shall ensure that the interface receives and process the notification of the EU DC by IDE each time an updated DDP version is available for downloading. e) The Contractor shall ensure that the interface allows communication, through an IP based network, with all other DCs and process automatically the requests received from other DCs or send to other DCs, via IDE, ensuring proper and timely answer in accordance with the type of request. See Operational Procedures, section 8.1 for further details The diagram below illustrates the flow of messages between EU DC and IDE. Page 33 of 105

34 Figure 6 messages exchanged between EU DC IDE Page 34 of 105

35 4.5.2 DDP interface In order to ensure distribution of LRIT information in compliance with IMO requirements contained in the Data Distribution Plan (DDP), the EU DC shall be provided with a DDP interface fully compliant with the requirements and specifications stipulated in IMO Resolution MSC 263(84) Revised Performance standards and functional requirements for the long-range identification and tracking of ships, and MSC 1 Circular 1259 Interim Revised Technical specifications for the LRIT system The DDP server is hosted and operated by IMO and will be implemented as a module of GISIS. The DDP will be implemented using a versioning mechanism to identify the current and all previous states of the DDP, so that by the version number alone all data contained in the DDP of that version may be identified To ensure that the users of EU DC are receiving only the LRIT Information which they are entitled to, the EU DC DDP interface shall be able to: a) establish and maintain a secure communication connection to the DDP server based upon the communication and agreed data security protocols as outlined in the IMO Revised Technical Specifications for Communication in the LRIT System; b) ensure DDP regular updating by means of a DDP Update Message downloaded directly from the DDP server and update the DDP within the EU DC upon receipt of the DDP Update Message; c) validate the incoming messages from the DDP Server according the final XML Schema provided by IMO and acknowledge the reception; d) generate the outgoing messages to the DDP Server according the final XML Schema provided by IMO; e) ensure decompression of the DDP file transmitted by the DDP server, if the file is compressed; f) perform the verification of DDP requirements to all incoming requests. LRIT Users will receive the requested information only if the DDP check was successful; REQUIREMENTS a) The Contractor shall develop the DDP interface. b) The Contractor shall ensure that the DDP interface is fully compliant with the requirements contained in the IMO LRIT documents (MSC 263(84) / MSC 1 Circular 1259 / MSC 1 Circular 1256); c) The Contractor shall ensure that the interface facilitates DDP downloading directly from the DDP server, both in incremental or full format. The communication between EU DC and DDP server will be done via XML messages over a secure data link; d) The Contractor shall ensure that the interface is able to decompress the DDP file, if the file is compressed by the DDP server; e) The Contractor shall ensure that DDP rules are applied to all LRIT reports when performing the distribution of data; Page 35 of 105

36 4.5.3 DDP updating procedure The DDP is updated directly by a CG through a web interface provided by IMO. Whenever a new version of the DDP is available on the DDP Server, the IDE will send a notification to the EU DC. The DDP may be downloaded by EU DC in XML format, as either: a) a Regular Update; or b) an Immediate Update; or c) the Full DDP Regular update this is the routine daily incremental update which is available on the DDP Server on a given day D at 00:00 UTC. A CG has to include any new entry before 23:59 UTC ( cut-off time ) of day D-1 to have it published in the day D update The EU DC has a 24-hour period, i.e. until 00:00 UTC of day D+1, to download the new DDP version. The EU DC will implement and use the regular update in its operations before 48 hours after publishing, i.e. 00:00 UTC of day D+2. To avoid an overload of the DDP Server, the DDP Request message (type 9) for a regular update should be submitted by the EU DC at a variable point in time. This instant will be chosen randomly between 00:00 UTC and 24:00 UTC of day D Immediate update this is a special DDP incremental update which refers to: a) A CG makes use of the rights pursuant to the provision of regulation V/ i.e. the list of CGs entitled to receive LRIT data of ships flying its flag; b) A CG activates a Custom Coastal standing order. This is an activation trigger referring to Custom Coastal polygons that have already been received and implemented by the EU DC after a Regular update An immediate update can be submitted by a CG at any time, i.e. there is no cutoff time rule as in the case of a regular update. If the EU DC is notified of an immediate update, the EU DC will immediately send the corresponding DDP Request message (type 9) An immediate DDP update shall be downloaded and implemented by the EU DC in 1-hour time after notification. The size of an immediate update is relatively small and no overload of the DDP Server is expected If a Flag State user of the EU DC decides that a CG is not entitled to reports from its ships irrespective of the position, the EU DC should have the possibility to apply the new DDP rules even before the reception of the Immediate Update from the DDP Server Full DDP upload this is a special situation which refers to the initial loading of the DDP when the EU DC is commissioned and connected to the DDP/IDE or in the event of a disaster recovery, for instance if the local version of the DDP file got corrupted due to hardware failure or breakdown, data recovery procedures, virus attacks, etc The following sequential process is therefore foreseen: a) Contracting Governments may modify their entry in the DDP at any time using the dedicated IMO web-based interface. There will be a daily submission cut-off time, published on the DDP Web site interface, which indicates at what time a Contracting Government must submit its DDP updates in order to have them included in the next regular update. If there is an emergency situation or other exceptional circumstances, the DDP server may release DDP immediate updates as frequently as required. Page 36 of 105

37 b) Whenever a DDP update is available, the DDP server will transmit a DDP notification message to the IDE to inform it that a new version of the DDP is available and it can be downloaded. This new version of the DDP will include all the changes submitted by Contracting Governments prior to the daily cut-off time or an immediate update. c) If the DDP server has received no changes from any Contracting Governments since the previous version of the DDP was released, then the DDP notification message shall indicate, in the Message parameter, that there is no new regular update because there have been no changes to the DDP since the previous update. d) The IDE will turn off its DDP version checking functionality. The IDE will then transmit a DDP request message to the DDP server requesting the latest DDP, in the form of either an regular/immediate update or a full DDP. e) The DDP servers will respond with an update message including the physical DDP as a file attachment (either a regular/immediate update or the full DDP as appropriate). The IDE will upload the DDP and update its internal data accordingly. IDE will then forward the DDP notification message it received from the DDP Server to all the DCs. f) The EU DC will transmit a DDP request message to the DDP server requesting the latest DDP in the form of either a regular/immediate update or a full DDP. g) The DDP server will respond with a DDP update message containing the DDP file. h) The EU DC will download the DDP. If the EU DC is not able to load the new version of the DDP, the EU DC will send a Receipt Message (type 7) with receipt code number 8. i) After a reasonable time interval has passed the IDE will turn on its DDP version checking functionality The diagram below illustrates the EU DC DDP updating data exchange flow. Figure 7 EU DC DDP interface Page 37 of 105

38 4.5.4 DDP enforcement procedure The EU DC will provide an automatic method of checking the DDP rules when distributing the LRIT data in order to ensure that the requestor is entitled or not to access the data The application of the DDP rules is explained in the IMO document MSC 1 Circular 1259 and those guidelines will be followed by the Contractor Following DDP checks must be performed after receiving a position request from an LRIT User. The checks depend on the role of the user and the type of request Port State request: a) DDP Check 1 A Port, or Port facility, requesting the position of a ship must be listed in the DDP, i.e. the LOCODE of the requestor is present in the DDP. b) DDP Check 2 The Port State does not belong to the exclusion list of the CG whose flag the ship is entitled to fly. c) DDP Check 3 The ship is not located in the inland waters behind the baselines of another CG. d) DDP Check 4 The ship is not located in the territorial sea of the CG whose flag the ship is entitled to fly Coastal State request: a) DDP Check 1 The Coastal State requesting the position of a ship must be listed in the DDP, i.e. the Country code of the requestor is present in the DDP. b) DDP Check 2 The Coastal State does not belong to the exclusion list of the CG whose flag the ship is entitled to fly. c) DDP Check 3 The ship is located inside the 1000 nm polygon of the CG of the Coastal State. d) DDP Check 3 The ship is not located in the inland waters behind the baselines of another CG. e) DDP Check 4 The ship is not located in the territorial sea of the CG whose flag the ship is entitled to fly Custom Coastal Standing Order a Coastal State can store in the DDP one or more Custom Coastal polygons ( Monitored Coastal Area ) to define sea areas, included in the 1000 nm, where ship tracking is automatically activated by the EU DC In such a case, whenever an EU ship reports a position which is inside the Custom Coastal polygon and a corresponding standing order is present in the DDP, the position report should be forwarded to the Coastal State. The same DDP checks as in the case of a Coastal State request described above should be performed Any Standing Order submitted by a Coastal or Port State with a given duration Start:Stop (parameter Request Duration ) will be executed and kept active by the EU DC from time Start to time Stop. If for some reason the Requestor is not anymore entitled to the LRIT data of the tracked ship, for instance if the ship enters territorial waters, the Order will be kept in a queue and re-activated as soon as the entitlement rights are valid again. Page 38 of 105

39 4.5.5 EU MS Data sharing procedure Every EU Flag State can decide if the LRIT positional data of ships flying its flag can be shared among EU MS or not The sharing of LRIT data related to EU vessels between EU MS will be performed by providing the LRIT data to the STIRES module of SSN where LRIT data can be combined with AIS data and distributed between EU MS. The LRIT data sharing procedure via STIRES is detailed in section REQUIREMENTS a) The Contractor shall ensure compliance of the DDP interface and processing module with MSC 1 Circular b) The Contractor shall implement the data sharing procedure facility as detailed in sections and The use of the facility will be optional for each MS. c) The Contractor shall provide a detailed description of any additional DDP related operational procedure identified during the development phase LRIT Co-ordinator interface The EU DC is audited annually by the LRIT Co-ordinator based on archived data and pricing structure. In order to allow access of the LRIT Co-ordinator to required data, the EU DC shall be provided with an interface developed for auditing purposes The functions of this interface shall include: a) authentication of the LRIT Co-ordinator based on the Digital Certificates in accordance with the Technical Specifications for Communication in the LRIT System ; b) access of the LRIT Co-ordinator to the information required to enable the satisfactory completion of an audit of its performance; c) access of the LRIT Co-ordinator to the EU DC for monitoring the billing, technical and operational data needed for auditing purposes; d) possibility of providing compiled statistics, error reports, and other required information to the LRIT Co-ordinator REQUIREMENTS a) The Contractor shall develop the LRIT Co-ordinator interface for auditing purposes. b) The Contractor shall ensure that the DDP interface is fully compliant with the requirements contained in the IMO LRIT documents (Resolution MSC.202/ Resolution MSC.263 / MSC.1/Circ.1259); c) The Contractor shall ensure that the interface facilitates the access of the LRIT Co-ordinator to the EU DC archived messages and pricing information; d) The Contractor shall ensure that the interface is able to provide the LRIT Co-ordinator with requested information, reports, statistics; Page 39 of 105

40 4.5.7 ASP interface The ASP Interface is the link between the EU DC and the ASP contracted by EMSA to identify and track EU ships. The ASP will independently communicate with the shipborne equipment of the ships they are responsible for and will use this interface to exchange messages with the EU DC. The link between EU DC and ASP is an essential component of the EU LRIT system and therefore the associated EU DC ASP interface shall be developed in full compliance with the requirements of the IMO LRIT Performance Standards [MSC 263(84)] and those stipulated in this document The ASP function is tendered by EMSA with another tender. The contractor of the ASP (tender EMSA/OP/06/08) and the contractor of the EU LRIT DC (this tender) have to coordinate their interactions and to specify in detail the interface 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 EU DC ASP interface shall enable the following minimum functionalities: a) remote integration of the shipborne equipment into the EU DC; b) automatic configuration of transmission of LRIT information; c) automatic processing of commands sent by EU DC to the shipborne equipment for modification of the interval of transmission and/or suspension of LRIT information; d) automatic processing of the on demand transmission of LRIT data; e) automatic recovery and management of transmission of LRIT data; f) secure communication link between EU DC and the ships requested to report to the EU DC; Through the ASP interface, the EU LRIT DC: a) receives LRIT information from ships instructed by their Administrations to transmit the LRIT information to the EU DC; b) processes LRIT ship position report messages as defined in the revised Technical Specifications for Communication in the LRIT System and adds the appropriate information prescribed in Table 2 of that document; c) sends the LRIT position request message to the ASP after receiving a position request message from a LRIT Data User via either the IDE interface or the LRIT Data User interface; d) processes LRIT position request messages based on the value of the request duration parameter. The message shall be relayed to the ASP if it is a poll, periodic or stop request REQUIREMENTS a) The Contractor shall develop the ASP interface in full compliance with the requirements contained in the IMO LRIT documents (Resolution MSC.202/ Resolution MSC.263 / MSC.1/Circ.1259); b) The Contractor shall cooperate closely with the ASP Contractor (if different) in developing the EU DC-ASP interface; c) The Contractor shall ensure that the interface is able to automatically format the messages sent and received by the EU DC, as outlined in the IMO revised Technical Specifications for Communication in the LRIT System ; d) The Contractor shall ensure that the interface is automatically processing Page 40 of 105

41 the requests received from the EU DC users for change of periodic rate or suspension of LRIT data transmission and on demand reports (polling); e) The Contractor shall provide automatic storage, management and recovery of all LRIT information handled to and from EU DC via ASP; f) The Contractor shall provide a communication link between the EU DC and the ASP that guarantees a fast, reliable and secure transfer of information between the two components. The communication link shall be in compliance with the specifications detailed in MSC 263(84) and particularly in Annex 3 (revised technical specification for communications within the LRIT system network) ASP EU DC operational procedure The communication between EU DC and ASP will be done via XML messages over a secure data link. Messages with a predefined format will be used to transmit position reports and change the periodic transmission rate Several system status messages should also 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 table below provides a summary of all message types needed to ensure specific functions of the interface between the ASP and the EU DC. These messages are not defined in IMO documents. The XML Schema of messages 101, 102, and 103 will be defined by the Contractor and provided to EMSA during the first month of the project. XML Schema of messages 104, 105, and 106 will be provided by EMSA to the Contractor at the beginning of the project. Message Type Message Name Message Description Direction System health data 101 Information/Exception Message to be sent to EU DC ASP -> DC in case of errors or unexpected behaviour of the system; also used in response to message ASP System Status (Ping) Routine 30-minute status message from the ASP to the EU DC, advising that the system is healthy. ASP -> DC 103 Ship Check/Reset Request Ship database handling 104 Ship Database Update Notification 105 Ship Database Update Request 106 Ship Database Update Response Message to be sent by the EU DC requesting a communication status check or reset for a given ship Message to be sent by 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 sent by the EU DC providing a full or incremental update of the LRIT Ship Database Table 5 System messages between EU DC ASP DC -> ASP DC -> ASP ASP -> DC DC -> ASP Page 41 of 105

42 Each of above messages is here below presented in tabular format with the following columns: Column Parameter Description Parameter Indicating the particular LRIT component that provides the Provided By parameter information contained in the LRIT message Parameter Listing the various parameter names contained within the LRIT message Values Listing the possible values of each associated parameter Description Providing brief information pertaining to each of the various parameters in the LRIT message LRIT Segments Indicating which of the LRIT communications segments of Figure 2 contain each parameter Processed Defining the specific format for each parameter Format Note: The definition of the various processed formats listed in the Processed format column is: n represents 1 ASCII decimal digit (0-9). N 1 nn represents 1 to n ASCII decimal digits. C represents 1 ASCII alphabetic character. C 1 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 Seconds=ss (where required) is 2 ASCII decimal digits from TEXT unformatted alpha numeric text string Table 6 Message parameters Information/Exception Message (type 101) this message shall be sent by the ASP to the EU DC in reply of a Ship Check/Reset Request messages (type 103) and in case of errors or unexpected behaviour of the system. The EU DC shall acknowledge the receipt of this message and take the following actions: a) send a standard receipt message type 7 to the user/requestor related to the respective ship to notify him about the error; The EU DC should be notified by a message type 101 in the following situations: a) 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, presently in IMO Circular 2843/Corr.1 and later to be adopted by MSC 84). This exceptional situation will be called under-reporting. b) The time interval between two messages is too short (according IMO Type Approval specifications, presently in IMO Circular 2843/Corr.1 and later to be adopted by MSC 84). This exceptional situation is called over-reporting. c) Communication failure to the Land Earth Station d) System failure of the CSP e) Communication failure to the CSP f) System failure of the ASP g) Others Page 42 of 105

43 Parameter provided by ASP/CSP Parameter Values Description LRIT segments Message type 101 Exception Message Message ID# Unique number Unique message number generated by using: LRIT ASP ID, Date and unique sequence number. Reference ID Time stamp Message ID of a request message Time UTC YYYY:MM:DD: HH:mm:ss The reference ID is the message ID of a request message that has been received. Date and time when this message is transmitted. IMO# IMO# The IMO number of the ship which tracking caused the exception Exception Code 0,1,2,3,4, 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 B B B B Processed format nn nnnnyyyymm DDHHmmss nnnnn nnnnyyyymm DDHHmmss nnnnn YYYY:MM:DD: HH:mm:ss nnnnnnn nnnn Short Description Text Short description of the exception B TEXT (max 300 characters) Destination LRIT network LRIT ID of the EU DC B nnnn component ID ASP ID LRIT network LRIT ID of the ASP B nnnn component ID Test 0,1 Setting indicating if message is test B N message or regular LRIT message. 0- Regular LRIT message 1- Test message Current periodic rate [optional] 2,3,4,5, 6, 8, 10,11 Last processed request type at ASP: 2-15 minutes periodic rate 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 B nn CSP ID# CSP# LTIR ID of the CSP B nnnn Communication B nn Network 1, 2, 3, Vessel Communication Network ID 1 INMARSAT C 2 INMARSAT D+ 3 IRIDIUM Table 7 Exception message type ASP system status message (type 102) this message shall be sent by the ASP to the EU DC with a predefined frequency of 30 minutes in order to show that the communication links and the ASP system are active. Page 43 of 105

44 Parameter provided by Notes: ASP Parameter Values Description LRIT segments Processed format Message type 102 ASP System Status Message B nnn Message ID# Unique number B Unique message number generated by using: ASP ID, Date, unique sequence number. Time Stamp Time Date and time when this message is transmitted. ASP System 0,1,2,3 0 The ASP system status Status is 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/system failure Description Text A short description of the nature of the problem, if status is not 0 (max 300 characters) Destination LRIT network component ID Originator LRIT network component ID Test 0,1 Setting indicating if message is test or regular LRIT message. 0- Regular LRIT message 1- Test message Refer to table 3 in MSC.1/Circ.1259 for explanation Table 8 ASP status message type102 B B B nnnnyyyymm DDHHmmss nnnnn YYYY:MM:DD: HH:mm:ss n TEXT LRIT ID of the EU DC B nnnn LRIT ID of ASP B nnnn Ship status check/reset 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 Information/Exception message (type 101). Parameter provided by Notes: ASP Parameter Values Description LRIT segments Processed format Message type 103 Ship Status Check Request Message B nnn 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. B YYYY:MM:DD: HH:mm:ss IMO# IMO# The IMO number of the ship B nnnnnnn to be checked Action 0,1,2 The action to be performed B nn 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 Destination LRIT network LRIT ID of the ASP B nnnn component ID Originator LRIT network component ID LRIT ID of the EU DC B Nnnn Test 0,1 Setting indicating if B n message is test message or regular LRIT message. 0- Regular LRIT message 1- Test message Refer to table 3 in MSC.1/Circ.1259 for explanation Table 9 Ship Status Check Request message type 103 B n Page 44 of 105

45 Ship Data Base notification message (type 104) this message is sent on a daily base by the EU DC to the ASP to inform whether the ship database has been updated or not. Parameter provided by Notes: EU DC Parameter Values Description LRIT segments Processed format Message type 104 Ship Database Update Notification B nn Message ID# Unique number B Unique message number generated by using: LRIT EU DC ID, Date and unique sequence number. Time Stamp Time Date and time when this message is transmitted. Notification 0,1 0 The LRIT Ship Database Type HAS NOT been updated after the last notification 1 The LRIT Ship Database HAS been updated after the last notification LRIT Ship Database version Destination Originator TEXT The current version of the LRIT Ship Database LRIT network component ID LRIT network component ID Test 0,1 Setting indicating if message is test message or regular LRIT message. 0- Regular LRIT message 1- Test message Refer to table 3 in MSC.1/Circ.1259 for explanation B B B nnnnyyyymm DDHHmmss nnnnn YYYY:MM:DD: HH:mm:ss nnnn cccc.cc LRIT ID of the ASP B nnnn LRIT ID of EU DC B nnnn Table 10 Ship Database Update Notification message type 104 B n Ship Data Base 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 Notes: ASP Parameter Values Description LRIT segments Processed format Message type 105 Ship Database Update Request B nn Message ID# Unique number B Unique message number generated by using: LRIT ASP ID, Date and unique sequence number. Time Stamp Time Date and time when this message is transmitted. Update Type 0,1 0 Incremental 1 Full LRIT Ship TEXT The current version of the Database LRIT Ship Database stored version at the ASP; if type is 0, the requested incremental update is relative to this version number Destination LRIT network component ID Originator LRIT network component ID Test 0,1 Setting indicating if message is test message or regular LRIT message. 0- Regular LRIT message 1- Test message Refer to table 3 in MSC.1/Circ.1259 for explanation B B B nnnnyyyymm DDHHmmss nnnnn YYYY:MM:DD: HH:mm:ss nnnn cccc.cc LRIT ID of the ASP B nnnn LRIT ID of EU DC B nnnn Table 11 Ship Database Update Request message type 105 B n Page 45 of 105

46 Ship Data Base 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 105) previously sent by the ASP The update file attached to message 106 will be in XML format. The corresponding schema will be provided by the Agency to the Contractor at the beginning of the project. Parameter provided by Notes: EU DC Parameter Values Description LRIT segments Processed format Message type 106 Ship Database Update Response B nn Message ID# Unique number B Unique message number generated by using: LRIT EU DC ID, Date and unique sequence number. Time Stamp Time Date and time when this message is transmitted. Update Type 0,1 0 Incremental 1 Full 2 Not available; in case the incremental update is relative to an old database version LRIT Ship TEXT The current version of the Database LRIT Ship Database stored current version at the EU DC LRIT Ship Database previous version TEXT The previous version of the LRIT Ship Database, to which the incremental update must be applied (only in case of incremental update) B B B B nnnnyyyymm DDHHmmss nnnnn YYYY:MM:DD: HH:mm:ss nnnn cccc.cc cccc.cc Update File File The file containing the B File database update (full or incremental) Destination LRIT network LRIT ID of the ASP B nnnn component ID Originator LRIT network component ID LRIT ID of EU DC B nnnn Test 0,1 Setting indicating if B n message is test message or regular LRIT message. 0- Regular LRIT message 1- Test message Refer to table 3 in MSC.1/Circ.1259 for explanation Table 12 Ship Database Update Response messages type 106 Page 46 of 105

47 The diagram below illustrates the EU DC ASP interface data exchange. Figure 8 EU DC ASP interface REQUIREMENTS a) The Contractor shall ensure that the ASP interface is able to support and process the additional messages 101 to 106 as defined within this document; b) The Contractor shall ensure compliance with the ASP EU DC operational procedures described within section c) Additional system messages between ASP and EU DC identified by Contractor, if needed by the EU DC, should be described in detail in the bid. The corresponding XSD files should be provided by the Contractor within the first month of the implementation phase. Page 47 of 105

48 4.5.9 Ship Data Base interface Each MS shall provide the following mandatory information for each of their ships which are instructed to transmit LRIT information to the EU DC: a) name of ship; b) IMO ship identification number; c) call sign; d) Maritime Mobile Service Identity (MMSI) The list of the ships provided by the MS is organised by EMSA using a LRIT Ship Data Base (DB) which shall be connected to the EU DC through the EU DC DB interface Therefore, the EU DC shall contain a Ship Data Base (DB) interface able to perform the following functions: a) Communicate with the EU ship DB using a secure Internet connection; b) Process messages 104, 105, and 106 as defined in the ASP Interface section; c) Ensure that EU DC is always using the most up-to-date version of the list of ships stored in the ship DB Ship DB updating procedure Member States may modify their entry in the EU ship DB at any time using the dedicated SSN Web interface or the automatic XML interface. There will be a daily cut-off time published on the web site interface, which indicates at what time a Member State must submit its ship data updates in order to have them included in the next incremental update. The daily cut-off time shall be synchronized with the DDP submission cut-off time. For that, the LRIT MI operators will adjust the daily cut-off time, if needed. The new version of ship DB after changes performed by a MS shall be transmitted to the EU DC and ASP The following sequential process is foreseen: a) Every day, after the cut-off time the ship DB will transmit a DB notification message (type 104) to the EU DC to inform it that a new version of the DB is operational and available for download. This new version of the ship DB will include all the changes submitted by the MS prior to the daily cut-off time. b) If the EU ship DB has received no change from any MS since the previous version of the LRIT DB was released, then the EU DB notification message shall indicate, in the message parameter, there is no new incremental update. c) Upon receipt of a ship DB Notification message (type 104) informing a new version is operational and available for download, the EU DC shall request the last updated version from the Ship DB server (message type 105) d) The ship DB server will respond with an update message (type 106) including the list of ships as a file attachment (either an incremental update or the full list of ships as requested). The ship data will be provided by the ship DB server in XML-based message, using a secure communication link and the SOAP protocol. e) The EU DC will receive the new list of ships and update the internal data base accordingly. f) After the EU DC completes its ship DB update, a similar updating procedure will be initiated between EU DC and ASP. Page 48 of 105

49 The diagram below illustrates the EU DC DB interface data exchange Figure 9 EU DC ship DB interface REQUIREMENTS d) The Contractor shall develop the ship DB interface in compliance with these requirements; e) The Contractor shall ensure that the ship DB interface processes the messages automatically according the protocol established with the ship DB server and it provides a reliable and secure transfer of the list of ships to the EU DC. f) The Contractor shall implement and comply with the ship DB updating procedure User interface The EU LRIT DC shall provide each User with a Web based Graphical User Interface (GUI) having LRIT functionalities. When designing the interface, the Contractor shall take into account that the communication between EU DC and NCA system shall be done over a secure data link The interface shall be user friendly and shall provide functions for: a) Access of each user to the LRIT data he is entitled to received in accordance with the DDP provisions; b) Handling specific user requests on basis of assigned user rights (polling, on demand transmission, stopping); c) Accede to the relevant journal maintained for an identified LRIT user, d) Provide the users with pricing and billing information, as received from the billing system interface; e) Notifying the LRIT Data User when a ship stops transmitting the LRIT information, f) Fleet simultaneous visualization for each identified LRIT user. The objects, colours and symbols displayed in the interface shall follow, where applicable, the IHO (S-52 standard) and IALA (Recommendation V-128); g) Monitoring and managing the Users Identification at national level. Each NCA shall be able to create its own internal LRIT users. Page 49 of 105

50 The GUI functionality of the interface shall work at least on the following Web browsers: Microsoft Internet Explorer (version 6 or above), Mozilla, Firefox (version 2 or above). No installation of additional software on the user side shall be required. Contractor shall ensure full compliance with latest W3C recommendations An XML interface shall be provided in addition of the Web based user interface after the first year of operation User LRIT data access procedure To access any functionality of the EU DC the users shall login in the system. The authentication shall follow the applicable security requirements described in section 5.3. User Single Sign On procedure for all EU DC applications shall be implemented After the authentication the user can access the GUI interface providing all functionalities listed in section above. The GUI menu shall have all the basic GIS commands to navigate on a world map (zooming, panning, full extend, previous extend, measurement, etc.). For each function described in the user interface the contractor shall design and propose a right click contextual menu to improve the access to the information EU MS shall be provided with the possibility to access the LRIT data they are entitled to receive in accordance with DDP rules and only for the ships flying their own flags, by using the following minimum data search functionalities: a) Specific ship selected by IMO number and/or ship s name; b) Type of ship; c) Area of search of a specific ship or for all fleet; d) Period of time for a specific ship or for all fleet; e) Last position available; The users shall also have the possibility to create their own internal LRIT distribution network by allocating their own internal/national users access rights. If exercising this option, the MI operators shall be notified on any new internal user created by the NCA REQUIREMENTS a) The Contractor shall develop the web based user friendly interface in compliance with these requirements; b) The Contractor shall ensure that the user interface is providing easy access of the user to the EU DC LRIT data which each user is entitled to access in accordance with the DDP rules. c) The Contractor shall ensure that the user interface provide the necessary tools for users to access, request, poll, stop LRIT data. d) The Contractor shall provide a GUI interface compliant with the functionalities described in section e) Functionalities and procedures not covered by section but identified during development phase, or even after initial acceptance, shall be implemented as well. f) The Contractor shall ensure that the user interface is installed at each user location and provides all users with the same set of functionalities. g) The Contractor shall implement the Single Sign On procedure for users with different roles or using different EU DC applications. h) The Contractor shall also provide an XML based user interface after the first year of EU DC operation, with the same functionalities as the web based interface. Page 50 of 105

51 Invoicing and billing interface EU DC shall be provided with an invoicing and billing interface able to: a) provide the billing system with information on incoming and outgoing LRIT messages; b) label/tag the mandatory and SAR SURPIC messages to be easily recognised by the billing and invoicing system; c) label/tag the position reports with the type of satellite network used to transmit the report; d) maintains and provides journals on files send to the billing system; e) provides the EMSA billing system with price lists of other Data Centres; f) receive the price list of EU Data Centre; The communication between the EMSA LRIT invoicing and billing system and EU DC should be done via XML messages over a secure data link. EMSA will provide more details on the message format during the first month of the project based on the characteristics of the EMSA Billing system to be acquired. REQUIREMENTS a) The Contractor shall develop a web based interface for connecting the EU DC with EMSA billing and invoicing system; b) The Contractor shall ensure that the billing interface is able to process the pricing messages (messages 12, 13, 14, 15); c) The Contractor shall ensure that the billing interface can label the positional report with type of satellite network used in the communication before forwarding them to the billing system. d) The Contractor shall ensure that the billing interface can create files in XML and CSV format with LRIT messages. Only one type of file will be necessary to implement and EMSA will provide this information during the first month after the project Kick-off meeting. e) The Contractor shall ensure that the LRIT messages are transmitted to EMSA billing and invoicing system on a daily basis, but the MI operator could change this frequency based on the number of messages f) The Contractor shall ensure that the billing interface can label the mandatory, SAR SURPIC messages and the type of satellite network within the journal provided to the billing system. g) The Contractor shall develop and maintain a journal for all files exchanged with the billing system The diagram below illustrates the data flow between EU DC I&B interface. Figure 10 EU DC invoicing and billing interface Page 51 of 105