• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
2.4.1.3.doc
 

2.4.1.3.doc

on

  • 2,863 views

 

Statistics

Views

Total Views
2,863
Views on SlideShare
2,863
Embed Views
0

Actions

Likes
0
Downloads
14
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    2.4.1.3.doc 2.4.1.3.doc Document Transcript

    • COMMAN Communication Manager System for Data Exchange for Ship Operations Telematics Application Programme Transport Sector Project No TR4006 User Requirements & State of the Art Survey report Version 1.0 Final 22/03/99
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report COMMAN Communication Manager System for Data Exchange for Ship Operations D3.1/User requirements & State of the Art Copy No: 0 Deliverable: User requirements & state of the Art Work Package: WP 03 Dissemination Level : Public Nature: Report Agreed delivery date : 30/1/99 Actual delivery date : 22/03/99 Technical Abstract: This report is intended to summarise information gathered within the COMMAN project related to a state of the art survey and to user requirements for the proposed single data node system which will be studied and demonstrated, as far its basic functionality is concerned, within the project. It begins with an overview of the project original ideas and general aims, followed by an outline of requirements already identified at the planning phase. The second chapter contains the state of the art survey, covering existing and emerging maritime communication systems, terrestrial and satellite developments and discusses third generation (IMT2000--UMTS) concepts. The third chapter reports on the detailed requirements analysis carried out by project partners. The fourth chapter presents a refined system concept, in line with the results of user requirements survey and summarises conclusions from user requirements capture and the state of the art survey. A series of appendices is also included (Definitions and abbreviations, standards to be considered in the design process, 1st User Forum summary, ideas on user interface and a list of requirements relevant to the design of a system interoperable with on board Integrated ship control network, based in an open architecture). Keywords: User requirements capture, State of the Art Survey TR4006/D3.1/MARAC/NP/220399/1.0 -2-
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report COMMAN Communication Manager System for Data Exchange for Ship Operations D3.1/User requirements & State of the Art Project Co-ordinator: Prof. Jens Froese ISSUS Rainvilleterrasse 4 22765 HAMBURG, Germany Phone:+49 (0)40 3807 2991; Fax:+49 (0)40 3807 2668; E-mail: froese@issus.fh- hamburg.de Produced by: Responsible Organisation Principal Authors Marac Electronics S.A N. Panagiotarakis Contributing Organisations Contributing Authors ISSUS Sylvia Ullmer DERA Peter Knight – Andrea Lewigton BAeSEMA Eddie Shaw – Brian Huston EUTELIS Rapfael Haik – Yann Depoys SINTEF Bjorn Willoch Bjanger – Anders Solhaug Authorised by: Project Co-ordinator ISSUS Prof. J. Froese Document History: Version Status/Revised Paragraph (s) Date 0.3 First draft in the final document format 18/12/98 0.4 Consolidation of partners contributions 14/1/99 0.5 Complete draft for internal project review 19/1/99 0.6 Final draft for external peer review 31/1/99 0.7 Spelling corrections according to peer reviewers 18/3/99 suggestions 1.0 First Final version 22/3/99 No. PAGES 101 FIGURES 14 TABLES 9 APPENDICES 5 Issued by Marac Electronics S.A N. Panagiotarakis TR4006/D3.1/MARAC/NP/220399/1.0 -3-
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report Distribution List: Copy No Recipient Status Location 0 Generated locally S4.1 Uncontrolled Copy 1 Sylvia Ullmer C1 ISSUS 2 Alexandra Kalapoutis A1.1 TRUTh 3 Kersten Gevers S1.1 Seven Cs 4 Malcolm Plumbley C2 DERA 5 Peter Knight C2 DERA 6 Andrea Lewingdon C2 DERA 7 Brian Houston A2.1 BAeSEMA 8 Prof. Malek Pourzanjani S2.1 SI-MRC 9 Jean-Manuel Canet C3 Expertel 10 Antony Kantidakis C4 MARAC 11 Nick Panagiotarakis S4.1 HORAMA 12 Bjorn Willoch Bjanger C5 SINTEF 13 Kim Fisher X1 MSA 14 Commander John Sexton X2 CGA 15 Paul Flament DG XIII CEC 16 Christos Pipitsoulis DG XIII CEC TR4006/D3.1/MARAC/NP/220399/1.0 -4-
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report Table of Contents 0. INTRODUCTION & SUMMARY...........................................................................................................................9 1. BACKGROUND INFORMATION - PROJECT CONTEXT.............................................................................11 1.1. KEY OBJECTIVES & VISION.......................................................................................................................................11 1.1.1. Strategy, services to be provided by the system and requirements identified into the planning phase of the project...................................................................................................................................................................12 1.2. VALIDATION SITES...................................................................................................................................................14 2. STATE OF THE ART IN COMMUNICATION TECHNOLOGIES ...............................................................15 2.1. TERRESTRIAL SYSTEMS: GSM, DECT AND TETRA.................................................................................................15 2.1.1. GSM...........................................................................................................................................................15 2.1.2. DECT..........................................................................................................................................................16 2.1.3. TETRA.........................................................................................................................................................17 2.2. SATELLITE SYSTEMS / SATELLITE SYSTEM PROPOSALS & SERVICES...............................................................................18 2.2.1. Little LEOs..................................................................................................................................................19 2.2.2. Narrowband LEOs and MEOs and GEO systems......................................................................................21 2.2.3. Broadband Satellite constellations.............................................................................................................23 2.2.4. A note on Multimedia transmission over TV GEO satellites.....................................................................25 2.3. THIRD GENERATION DEVELOPMENTS (IMT2000 – UMTS).........................................................................................26 2.4. MARITIME COMMUNICATIONS...................................................................................................................................28 2.4.1. : GMDSS – The Global maritime distress & safety system........................................................................28 2.4.1.1. The COSPAS-SARSAT System..........................................................................................................................29 2.4.1.2. NAVTEX.............................................................................................................................................................29 2.4.1.3. Inmarsat...............................................................................................................................................................29 2.4.1.4. HF Radiotelephone...............................................................................................................................................30 2.4.1.5. Search and Rescue Radar Transponders (SARTs)................................................................................................30 2.4.1.6. DSC :Digital Selective Calling.............................................................................................................................30 2.4.1.7. GMDSS Areas......................................................................................................................................................30 2.4.2. Transponders/ AIS devices..........................................................................................................................31 2.5. COMMUNICATION TECHNOLOGY PROPOSALS WITH POTENTIAL IMPACT ON MARITIME COMMUNICATIONS .................................33 2.5.1. Maritime Enhanced Mobile Radio..............................................................................................................33 2.5.2. DSRR, E-DSRR...........................................................................................................................................33 2.5.3. TOMAS project proposal for an S-UMTS terminal and services...............................................................35 2.5.4. Proposals on data Integration afloat..........................................................................................................36 2.5.4.1. PISCES/ DISC/ COMMAN.................................................................................................................................37 2.5.4.2. ISIT.....................................................................................................................................................................40 3. PRESENTATION OF RESULTS FROM THE USER REQUIREMENTS CAPTURE & ANALYSIS PROCESS ....................................................................................................................................................................42 3.1. METHODOLOGY AND INTRODUCTION TO THE CHAPTER...................................................................................................42 3.2. COMMAN USERS AND STAKEHOLDERS & SYSTEM NON-FUNCTIONAL REQUIREMENTS...................................................48 3.2.1. User Classification & Main goals..............................................................................................................48 3.2.2. Non-functional requirements......................................................................................................................51 3.3. TECHNICAL ENVIRONMENT & RELEVANT REQUIREMENTS................................................................................................53 3.3.1. General requirements.................................................................................................................................54 3.3.1.1. Bearers and basic services....................................................................................................................................54 3.3.1.2. Requirements specific to system design & architecture:.......................................................................................55 3.3.2. COMMAN User Workstation......................................................................................................................57 3.3.2.1. User Preference for Hardware .............................................................................................................................57 3.3.2.2. User preferences for Software environment ........................................................................................................58 3.3.2.3. Reference materials required either to perform tasks with system or to learn about or operate system.................59 3.3.2.4. Other requirements in relation to user station.......................................................................................................59 3.3.3. COMMAN server........................................................................................................................................59 3.3.3.1. User preferences for the Software & hardware environment in which system will run........................................59 3.3.3.2. Other technical (stake-holders) requirements relevant to server..........................................................................59 3.3.4. COMMAN Configuration Workstation.......................................................................................................60 3.3.5. COMMAN on board gateways....................................................................................................................61 3.3.6. Considerations and constraints in relation to the context of this section ..................................................61 3.4. PHYSICAL ENVIRONMENT & RELEVANT REQUIREMENTS..................................................................................................63 3.4.1. User Workstations.......................................................................................................................................63 TR4006/D3.1/MARAC/NP/220399/1.0 -5-
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 3.4.1.1. Location, place of installation Thermal and atmospheric environment.................................................................63 3.4.1.2. Auditory Environment..........................................................................................................................................63 3.4.1.3. Vibration or instability.........................................................................................................................................63 3.4.1.4. Visual Environment.............................................................................................................................................64 3.4.1.5. Space....................................................................................................................................................................64 3.4.1.6. User posture.........................................................................................................................................................64 3.4.1.7. Health and Safety hazards related to system use..................................................................................................64 3.4.1.8. Protective clothing and equipment.......................................................................................................................64 3.4.1.9. Potential Standards or international/ local regulations relevant to the above........................................................64 3.4.2. COMMAN server, configuration station & gateways.................................................................................65 3.4.2.1. Usually “Indoor” Units.........................................................................................................................................65 3.4.2.1.1. Location, place of installation.......................................................................................................................65 3.4.2.1.2. Thermal and atmospheric environment.........................................................................................................65 3.4.2.1.3. Auditory Environment..................................................................................................................................65 3.4.2.1.4. Vibration or instability..................................................................................................................................65 3.4.2.1.5. Visual Environment......................................................................................................................................65 3.4.2.1.6. Space............................................................................................................................................................65 3.4.2.1.7. User posture..................................................................................................................................................66 3.4.2.1.8. Health and Safety hazards related to system use...........................................................................................66 3.4.2.1.9. Potential Standards or international/ local regulations relevant to the above................................................66 3.4.2.2. Outdoor equipment...............................................................................................................................................66 3.4.2.2.1. Thermal and atmospheric environment.........................................................................................................66 3.4.2.2.2. Auditory Environment..................................................................................................................................66 3.4.2.2.3. Vibration or instability..................................................................................................................................66 3.4.2.2.4. Visual Environment......................................................................................................................................66 3.4.2.2.5. Space............................................................................................................................................................66 3.4.2.2.6. User posture..................................................................................................................................................66 3.4.2.2.7. Health and Safety hazards related to system use...........................................................................................67 3.4.2.2.8. Potential Standards or international/ local regulations relevant to the above................................................68 3.4.3. Constraints identified relevant to the content of this section......................................................................68 3.5. SOCIAL AND ORGANISATIONAL ENVIRONMENT & PRELIMINARY ORGANISATIONAL APPROACH............................................69 3.5.1. Staff management structure and IT policy relevant requirements..............................................................69 3.5.2. Requirements relevant to assistance...........................................................................................................71 3.5.3. Requirements relevant to interruptions and stressful conditions...............................................................71 3.5.4. Requirements arising by examination of current communications structure.............................................72 3.5.5. Requirements relevant to safety, security and privacy...............................................................................72 3.5.6. Legal issues/standards................................................................................................................................72 3.5.7. Information Flows & COMMAN preliminary organisational approach...................................................73 3.5.7.1. DISC suggested information model......................................................................................................................73 3.5.7.2. Typical on board information flows (FMS guide)................................................................................................74 3.5.7.3. COMMAN preliminary organisational approach.................................................................................................74 3.6. KEY COMMUNICATION TASKS & RELEVANT REQUIREMENTS............................................................................................77 3.6.1. Passage.......................................................................................................................................................77 3.6.1.1. Pilotage, Docking.................................................................................................................................................77 3.6.1.2. Navigation............................................................................................................................................................77 3.6.1.3. Safety/Emergencies..............................................................................................................................................79 3.6.1.4. Reference data......................................................................................................................................................79 3.6.2. Shipping husbandry and operations...........................................................................................................79 3.6.2.1. Engineering..........................................................................................................................................................79 3.6.2.2. Planning...............................................................................................................................................................79 3.6.2.3. Operations............................................................................................................................................................79 3.6.2.4. Administration.....................................................................................................................................................80 3.6.3. Other miscellaneous application areas......................................................................................................80 3.6.3.1. Personal communications & distant learning........................................................................................................80 3.6.3.2. Tele-medicine services.........................................................................................................................................81 3.6.3.3. Passenger services................................................................................................................................................81 3.6.4. Requirements of a generic nature...............................................................................................................81 3.6.5. Identified technical Constraints relevant to requirements presented in this section..................................82 3.7. OTHER DESIGN IDEAS AND CONCEPTS ......................................................................................................................83 3.7.1. Requirements resulted from review of terrestrial mobile systems/ system proposals................................83 3.7.2. Requirements relevant to review of IMT2000, UMTS................................................................................83 3.7.3. Requirements relevant to review of forth-coming satellite systems/ system proposals..............................84 3.7.4. Requirements relevant of maritime communication systems & services....................................................85 3.7.5. Requirements extracted from projects dealing with on-board data integration and decision support......85 3.7.6. Requirements relevant to review of transponder/AIS equipment, systems & system proposals.................86 3.7.7. Requirements relevant to tele-medicine projects review............................................................................86 TR4006/D3.1/MARAC/NP/220399/1.0 -6-
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 3.7.8. Requirements relevant to review of TCP/IP communications over satellite..............................................86 3.7.9. Requirements relevant to review of VSATs.................................................................................................87 3.7.10. Other “Nice to have” features .................................................................................................................87 3.7.11. Identified technical constraints relevant to requirements presented in this section.................................88 4. REFINED SYSTEM CONCEPT & CONCLUSIONS.........................................................................................89 4.1. REFINED SYSTEM CONCEPT........................................................................................................................................89 4.1.1. Vision statement..........................................................................................................................................89 4.1.2. Target market planned................................................................................................................................89 4.1.3. Main users and stakeholders......................................................................................................................89 4.1.4. Mission statement, development concept....................................................................................................90 4.1.5. System overview..........................................................................................................................................90 4.1.6. System boundary.........................................................................................................................................91 4.1.7. System boundary (COMMAN demonstrator)..............................................................................................92 4.1.8. Generic functions........................................................................................................................................93 4.1.9. Basic applications ......................................................................................................................................93 4.1.10. Future basic applications.........................................................................................................................93 4.1.11. Communication channels..........................................................................................................................94 4.1.12. Maintainability..........................................................................................................................................94 4.1.13. Existing system or new development.........................................................................................................94 4.1.14. Single user or multi-user...........................................................................................................................94 4.1.15. Physical environment................................................................................................................................94 4.1.16. Basic characteristics of the COMMAN system user interface..................................................................95 4.1.17. Organisational/institutional/social aspects..............................................................................................95 4.1.18. Safety/security/privacy aspects.................................................................................................................96 4.1.19. Standards to consider...............................................................................................................................96 4.1.20. Data and information................................................................................................................................96 4.1.21. Degraded modes of operation...................................................................................................................96 4.1.22. Future expansion......................................................................................................................................96 4.1.23. Financial (system development)...............................................................................................................96 4.1.24. Financial (payment of services)................................................................................................................97 4.1.25. Technical constraints................................................................................................................................97 4.1.26. Risk............................................................................................................................................................97 4.2. OTHER GENERAL CONCLUSIONS FROM STATE OF THE ART AND USER NEEDS SURVEY. PROJECT OPINION ON THE HIGH LEVEL ARCHITECTURE OF FUTURE MARITIME COMMUNICATION SYSTEMS............................................................................................98 5. REFERENCES.......................................................................................................................................................100 APPENDICES...........................................................................................................................................................102 A1 Glossary & Abbreviations A2 Standards to consider (Informative) A3 Ideas for COMMAN graphical user interface (Informative) A4 1st User Forum Report Summary A5 Requirements to the system architecture (Informative) List of Tables TABLE 1 SATELLITE SYSTEMS OVERVIEW....................................................................................................19 TABLE 2 LITTLE LEO SERVICES PORTFOLIO................................................................................................20 TABLE 3 – LITTLE LEO SERVICES (VERSUS INMARSAT C)........................................................................21 TABLE 4 – PERSONAL COMMUNICATIONS SYSTEMS (EXAMPLES VERSUS INMARSAT)................23 TABLE 5 BROADBAND SATELLITE SYSTEMS (EXAMPLES).......................................................................24 TR4006/D3.1/MARAC/NP/220399/1.0 -7-
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report TABLE 6 TOMAS SERVICES..................................................................................................................................35 TABLE 7 – ISIT DESIGN GOALS............................................................................................................................40 TABLE 8 SOURCES CONSULTED.........................................................................................................................47 TABLE 9 COMMAN USERS, STAKE-HOLDERS & AFFECTED USERS........................................................48 List of Figures FIGURE 1: COMMAN PROJECT VISION ON THE SHIP-BORNE MARITIME COMMUNICATION SYSTEM OF YEAR 2000+.........................................................................................................................................12 FIGURE 2 TURBO INTERNET USES SPARE SATELLITE TRANSPONDERS AND PSTN "RETURN CHANNELS" TO DELIVER HIGH SPEED TCP/IP DATA – (SOURCE: THE OFFICIAL WEB SITE OF THE DVB PROJECT..................................................................................................................................................25 FIGURE 3 GSM/ UMTS NETWORK ARCHITECTURE, SOURCE [7].............................................................27 FIGURE 4 HIGH LEVEL 3G ARCHITECTURE – SOURCE [21].......................................................................27 FIGURE 5 EIES PROJECT DUAL MODE WIRELESS PLATFORM................................................................34 FIGURE 6 ISC NETWORK OVERVIEW – SOURCE: PISCES BROCHURE..................................................37 FIGURE 7 PISCES/ COMMAN/ DISC II INTERRELATIONSHIP – SOURCE: PISCES WWW SITE........39 FIGURE 8 KEY USER-CENTRED DESIGN ACTIVITIES (FROM ISO 13407, RESPECT)...........................42 FIGURE 9 WP03- USER REQUIREMENTS CAPTURE & ANALYSIS METHODOLOGY...........................44 FIGURE 10 TYPICAL ORGANISATIONAL STRUCTURE ON BOARD A VESSEL.....................................70 FIGURE 11 DISC INFORMATION FLOW MODEL - SOURCE [41].................................................................73 FIGURE 12 SITP DATA FLOW (TYPICAL)..........................................................................................................74 FIGURE 13 COMMAN WORKING ENVIRONMENT AND SURROUNDINGS – PRELIMINARY APPROACH.................................................................................................................................................................75 FIGURE 14 VISION ON 3G HIGH LEVEL ARCHITECTURE – TERMINALS & ACCESS NETWORKS FOR MARITIME USERS...........................................................................................................................................99 TR4006/D3.1/MARAC/NP/220399/1.0 -8-
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 0. Introduction & Summary This report is intended to summarise information gathered within the COMMAN project related to a state of the art survey and to user requirements for the proposed single data node system which will be studied and demonstrated (as far its basic functionality is concerned) within the project. It has been written by authors with a variety of experience of technological and user needs. Requirements, presented in this report are extracted from the work of previous telematics projects, an extensive literature survey and world-wide web search, interviews with user representatives and domain experts and last, but not least, the 1st European User Forum. The report is written to draw together information for use within the system design and building phases of the project, and its primary objective is to act as a reference point for project partners involved in relevant future workpackages. It is anticipated that it will also be of interest to a wider audience. The report begins with an overview of the COMMAN project context i.e. key objectives, project vision, strategy and services envisages, requirements identified in project planning phase and a brief paragraph introducing project’s validation context, which will involve end-user target groups such as:  Crew on board, especially the watch at the bridge, the captain and ship’s engineers.  Secondary users ashore are e.g. ship owners, the shipping agent, the harbour masters and VTS centres. The second chapter contains a summary of the state of the art survey, covering existing and emerging maritime communication systems, terrestrial and satellite developments and discusses third generation (IMT2000--UMTS) concepts. This developmental overview is used as a context for introducing the particular niche role of COMMAN as a single data/ communication node acting as an “off-ship gateway” to and from the ship ISC and administrative networks. The third chapter reports on a detailed requirements’ analysis carried out by project partners. The project adopted an iterative methodology for user requirements’ capture and analysis, which will result in a “user centred” approach for system design. COMMAN methodological approach was based on the CODE project guidelines for user needs analysis [37],the framework for user requirements’ capture and analysis developed by the Telematics Engineering project RESPECT [36] as well as the provisions in the Technical annex of COMMAN project. It provided a systematic tool for identifying requirements based on:  User groups characteristics and goals  The technical, physical and organisational environment(s), tasks, processes and information flows  Features of applications and systems that will be using services provided by the single data node and existing/emerging bearers that should be possibly interfaced to the COMMAN system. The chapter summarises a great deal of information (at first recorded in a series of forms and an electronic database) which is presented as a series of detailed lists in a format designed to aid reference within the design and implementation phases of the COMMAN project. It should be noted that, from the COMMAN viewpoint and the methodology it follows, the system “users” are not only the “end-users” (on board user groups, visiting technicians, pilots, etc) or “affected” users (ashore personnel of the shipping companies, crew family members, VTS personnel, etc). Users can be other system “stake-holders” as well, such as application developers, communication system manufacturers, network operators and service providers. Their needs have also been captured, primarily with the aid of an extensive literature survey and worldwide web search, and recorded in this document with the form of technical requirements, technical limitations/ shortcomings, desirable and “nice-to-have” features and standards to be considered. Both end-user and stake-holders requirements have been pre- assessed, by the project team, in the light of what is feasible and possible by making use of today and emerging technologies. As a result a summary of design constraints and project opinions on how the system designers should deal/ cope/ overcome identified limitations has been included. TR4006/D3.1/MARAC/NP/220399/1.0 -9-
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report Obviously the requirements’ evaluation process will continue, during the functional specification and system architecture definition phases of the project. Project’s final design choices will be recorded in the “System Architecture” deliverable D5.1. However, the adopted methodology will assist the design team to identify all the key issues relevant to COMMAN design that need to be considered during the next phases of the project. Further it has facilitated the refinement of the system concept (with respect to the original ideas recorded within the project’s technical annex). This refined concept is a major focus of the fourth and final chapter of the report, which also highlights conclusions about the potential role of COMMAN in the context of future maritime communications as well as the evolution of mobile/ satellite communication systems. The report also contains five appendices: Glossary & Abbreviations, Standards to consider (informative), ideas for the graphic user interface (informative), 1st User Forum Report Summary and, finally, requirements to the system architecture (informative) Note for the reader: Kindly note that for the presentation of the requirements (in chapter (3) of the document) bulleted lists have been used. These are identified (in order to differentiate from other bulleted lists used in the document) by a “bullet” symbol representing a “finger” indicating towards the requirement statement, as indicated below:  User requirement’s text TR4006/D3.1/MARAC/NP/220399/1.0 - 10 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 1. Background Information - Project Context Information recorded in this chapter is primarily based on the Technical Annex (Project programme) included in COMMAN project contract TR4006. It outlines the project context i.e. key objectives, project vision, strategy and services envisages, requirements identified in project planning phase and a brief paragraph introducing project’s validation site. 1.1. Key objectives & vision COMMAN is an R&D project co-funded by the Telematics Application programme of the European Commission. Its primary objective is the development and validation of an on board communication manager system which shall integrate existing or emerging communication bearers and enable on board users to access them seamlessly, via a common user interface incorporated into the application. Thus, it will provide on board navigators with a “single point access” to existing or future communication services and ashore users a single entry for remote login at ship’s internal network. Communication on land, and particularly data exchange in the form of the Internet, has over the last ten years, seen a very rapid pace of technological development. In the mobile domain however, radio communication at sea has evolved less quickly and precluded the communications flexibility that derives from the use of a common user network. Maritime communications still comprise disparate VHF, MF and satellite networks. Data communication is still rare and voice communication relies heavily on pre-digital technology. This is extravagant in its use of spectrum and inefficient in protecting the transmission from corruption by interference. The COMMAN project addresses the implementation of a “single data node” on board ships, functioning as a hub through which all of the ships’ external communications flow. This will centralise the communications management and give information services access to all available communication bearers. It is thus expected that the administrative load of on-board personnel will be reduced, communications management will be improved and error rates, congestion and delay problems imposed by current communications will be kept to a minimum. It is also expected that the system will provide the ship operator with a powerful tool to meet efficiency and cost drivers which will result from the expected drastic increase of maritime data communication. The demands will be driven from a range of services that will include: radio transponders, DGPS correction service, ECDIS data base access and updating, remote login into ship-borne automated systems for diagnosis, maintenance and multi-media applications. It is anticipated that the system would be installed in all types of vessels of 500 GRT or more displacement. Main customers for this type of equipment will be commercial shipping operators. The system will support ship-ship and ship-shore communication within all functional areas of the ship operation process, such as:  Passage execution, e. g. navigation support and data communication between VTS’s and vessels  Management and cargo handling  Engineering & planning operations  Safety, e. g. support of standard reporting procedures according to ISM code Additionally, the system will support personal communications, health monitoring (tele-medicine) and training applications. The single data node concept is illustrated in figure (1). TR4006/D3.1/MARAC/NP/220399/1.0 - 11 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report GMDSS HF LEAST COST ROUTING F VH s ce vi De A IS M COMPRESSION GS / UMTS E-DSRR COMMAN SERVER OTHER?? S-PC N (IC O/IR ID IUM , etc) Multiband Multimode S- Maritime UM TS Communication Server IN M AR SA T- IN C MA R Data, Video, Messages, Audio SA T- B Voice Switch Decision Support Systems Gateway ISM Navigation, ship control Other ship Engine Control management Systems Cargo , Machinery Ballast, Fire, etc Figure 1: COMMAN project vision on the ship-borne maritime communication system of year 2000+ COMMAN will be integrated seamlessly into the on board ISC network and it will act as a gateway between all ship-borne networks and the external world. All available communication bearers (satellite, radio, etc) shall be directly accessible by the system or by safety critical services (i.e. for GMDSS use). In this context, the communication manager shall make optimum use of existing maritime bearers (such as Inmarsat) or existing mobile bearers (such as GSM) and project shall exploit the potential that arises by integrating it with emerging/ forthcoming satellite & radio/mobile systems. COMMAN will be a multi- user system that will be accessible to all clients connected to the on board networks (ISC network and administrative networks). With respect to the operation of the COMMAN server itself (e.g. for configuration of the server) there will be one single operator console 1.1.1. Strategy, services to be provided by the system and requirements identified into the planning phase of the project To support successful exploitation, in the short term after project completion, the end product must be capable of becoming an add-on to the available range of commercial systems that are in use today on board ship and not to require the replacement of such equipment. That is why the project strategy is to TR4006/D3.1/MARAC/NP/220399/1.0 - 12 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report base the communication manager system design, as far as possible, on available or emerging standards and Commercial Off The Shelf (COTS) products and to minimise any additional hardware and software development. However, in line with the process, in Europe, for developing a third generation Universal Mobile Telecommunication System (UMTS), the project is also intending to take into account new developments within the field of mobile communications like emerging satellite systems or other cordless systems. Therefore the project is evaluating and validating proposed candidate technologies and system concepts, which are in line with the COMMAN basic objective (seamless integration of functions and seamless access of bearers, through application interface via a single communication node). It should be noted that a development concept exists and it is based on current commercial developments, in house R&D projects of the participant companies as well as research currently undergone within projects such as (list is not exclusive): POSEIDON, EIES, VTMIS-NET, GEONET-4D, TOMAS & PISCES. With respect to COMMAN system functions, one has to distinguish between generic functions of the communication manager itself and applications to be supported by the system. Generic functions are independent of specific applications forming the basic functionality of the communication manager system. Supported applications are in general not part of the communication manager system. However, it is important to study carefully the applications in order to identify functional requirements of the system. In relation to “generic” functions of COMMAN, following requirements have been already identified during the planning phase of the project:  Integration of communication bearers used today or expected in the near future  “Seamless roaming” among available carriers  System should apply effective and efficient information management techniques  System should provide operational and support information  System should include network management: resources and diagnostic tools  System should comprise network security: authorisation and protection mechanisms for validation of messages  System should be easily configurable and adaptable to the specific operation environment of a given ship  Communications routing should be based on Quality of Service criteria  System shall provide means and tools for Internet / Intranet access  Access to on board/ on shore databases with / without multimedia content should be enabled  Wireless access to terrestrial ISDN should be enabled  Wireless access of terrestrial or satellite high speed communication networks should be enabled  System should act as a gateway between the ISC network and the external world Supported applications can be divided into basic applications and specific applications. Basic applications (e.g. e-mail or Internet browser capabilities) cannot be allocated to a specific task or function. These applications are used as “tools” to execute several tasks. Specific applications (e.g. remote maintenance) are used to perform one specific task. The following paragraphs include a list of “basic” applications and “specific” applications, which should be supported by the COMMAN system. It must be noted that this list is not exhaustive or complete, it just reflects the original ideas, on the COMMAN concept, of project participants as recorded in the contract’s technical annex1: 1 One of the primary goals of the User requirements' analysis phase of the COMMAN project was to verify the validity of the list and record the user expectations on the basic and specific services which should be supported by the communication manager. However, the final selections of the basic and specific services that will be included in the demonstrator depend on the demonstrator configuration, which will be decided at a later stage. TR4006/D3.1/MARAC/NP/220399/1.0 - 13 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report Basic applications:  E-mail with attachments  Internet / Intranet browser capabilities  Voice communications via the available (depending on system configuration) narrow band communication channels  Fax  Short messaging service via on board transponder equipment  Internet Relay Chat (IRC)  Video conference via the available (depending on system configuration) high speed communication channels  White-boarding Specific Applications: Existing today:  Delivery (Import/ Export) of ISM code relevant messages or forms  Weather, Hydrographic and Ship Movement Information Access  ECDIS on line updates  Tele-medicine  Remote Damage Survey, Remote Inspection and Fault Diagnosis - Integration of the on board component of decision support systems with their on shore component  Remote Surveillance of Safety Critical Operations or Ship Conditions  Delivery of Remote Expertise and Co-operative Work (such as tele-maintenance, distant learning)  Transmission of radar picture extracts from VT(MI)S to ships  On board logistic /management systems  Access to Value Added Port Services and port intranets  Access to passenger/ traveller information systems  Port Entry Guide (PEG)  Virtual Round Tables and Forums (if possible) Future applications/ services  Wireless access to on shore networks/ databases via UMTS, S-UMTS  Communication aids to vessel automatic berthing operations  Support to language independent communication and bridge information exchange tasks by integrating suitable language independent communicators & speech processing tools 1.2. Validation sites The system, which will be developed during the course of the project, will be validated in a real operational environment to prove its usability and to convince potential users and owners of the benefits that could accrue. The demonstration planned for COMMAN project will consist of a series of practical field trials and tests, aboard and ashore, involving professional users. The verification process is not site dependent. If the trials are successful in one area it can be assumed that this will also be the case in other areas. Only one demonstration site is planned2. This is located in the southern approaches of the UK and it covers an area from Dover to Lymington. It will consist of a series of communication nodes at control and user locations. On shore a node will be used at the DERA Fraser site and it is planned to install a COMMAN system on vessels owned by Brittany Ferries, P&O Ned Lloyd and (optionally) Red Funnel Ferries. 2 If during the course of the project other sites (or vessels) want to participate this may be possible but only on their own costs. TR4006/D3.1/MARAC/NP/220399/1.0 - 14 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 2. State of the Art in Communication Technologies This chapter3 is the result of an extensive literature and internet survey and sets out to provide the reader with an overview of the current state of the art in the mobile and satellite systems arena, in terms of both the technology and markets. It includes background information on technologies (existing or emerging) as well as on specific systems, system proposals and system concepts, including PISCES, ISIT and TOMAS project proposals which are of direct relevance to maritime communication users. The primary objectives of the survey were:  to identify the main technological factors which influence specific systems evolution and identify trends and commonalities in the design of mobile and satellite communication systems and terminals;  to identify targets and the “gaps” which proposed systems or technologies intend to cover;  to identify potential advantages and disadvantages of proposed systems or technologies;  to provide information on the key services and core markets addressed by each individual system or proposal and, if available, information on the marketing strategy that system developers or operators intend to follow. It should be emphasised that this investigation was made from the perspective of an industrial company developing and/or integrating communications systems for maritime and land mobile applications, wishing to obtain a clear view on current trends and developments. These may impact/affect, directly or indirectly, the future maritime communication market. Therefore, there is no reference herein to mobile technologies or concepts (such as MBS – Mobile Broadband systems or PHS) developed only or primarily for use within (or around) metropolitan areas. 2.1. Terrestrial systems: GSM, DECT and TETRA 2.1.1. GSM At the end of 1997, the GSM standard accounted for 66 million customers - 31 per cent of the world’s total market for wireless services[1]. It is the world’s leading digital platform for terrestrial mobile communications. The majority of GSM networks operate at the 900Mhz band and are based on phase I specifications, which were published by ETSI in 1990. Currently, there are 237 GSM networks, worldwide (including DCS1800 and PCS1900, which are GSM variations operating at 1.8 GHz (DCS1800) or 1.9 GHz - GSM1900 or PCS1900). The basic service supported by GSM is telephony. In addition, a variety of circuit switched narrow- band data services is offered, supporting Group 3 facsimile and data transmission at up to 9600bps. GSM may provide gateways to PSTN, ISDN, Packet Switched Public Data Networks, and Circuit Switched Public Data Networks using a variety of access methods and protocols, such as X.25 or X.32. A very useful service introduced with GSM, (not found in older analogue systems) is the Short Message Service (SMS). This is a bi-directional service for short alphanumeric (up to 160 bytes) messages. Messages are transported in a store-and-forward fashion, or are stored in the SIM card incorporated in GSM handsets for later retrieval. The Short Messaging Service (SMS) is increasingly being used for advanced features such as Internet driven e-mail delivery, while wider support for mobile-originated SMS is bound to attract many users. It is expected that single-channel rates over GSM will very soon be extended from 9.6 kbps to 14.4 Kbps, and there are manufacturers who claim that, by applying compression techniques, they will achieve data throughput of up to 36.000 bps. 3 based on a full Horama report [39], prepared on behalf of project partner Marac Electronics S.A and including valuable contributions from all the COMMAN partners TR4006/D3.1/MARAC/NP/220399/1.0 - 15 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report The most recent developments in GSM relate to provision of higher speed data services such as HSCSD and GPRS. HSCSD is an enhancement of the current circuit-switched operation of GSM, which will soon be available to provide circuit switched data at speeds up to 76Kbit/s. GPRS is based on data packet transmission (used for the first time on GSM) and will operate at rates ranging from 14Kbit/s to 115Kbit/s. GPRS is to be introduced late in 1999. Because GPRS transmits packets, it will be more suited for bursty data applications, such as e-mail and database access services and connectivity with TCP/IP networks. However, it should be noted (as Ovum & Dataquest conclude in their recent reports [3][4]) that implementation of both HSCSD and GPRS require serious investments, and modifications to current networks (as well as to the mobile terminals). It is therefore probable that they will be restricted to certain specific metropolitan areas. GSM networks have, of course, been developed around cities, their surrounding areas and principal highways. Financial considerations preclude wider coverage and there are no firm signs that GSM networks will be expanded in order to cover extensive coastlines. GSM service is usually provided at much lower rates than Inmarsat’s. In “closed” waters (for instance the Baltic), wherever access to GSM is possible, seafarers are increasingly using it, although it is not officially accepted as a maritime communication platform. Service rates to pay for GSM are based on individual provider pricing policy. However they are usually set at a fraction of $1 per minute. 2.1.2. DECT DECT and its North American sibling (PWT) is a cordless system intended for very short range communications (typically 200 metres), operating in the 1880 to 1900 MHz band using GFSK (BT=0.5) modulation. It is mainly intended for use in indoor environments and private networks, which may involve multiple handsets and base stations. Roaming between base stations is possible. Use of a handset on different DECT private networks (e.g. business and residential) is also facilitated. DECT has a very flexible radio interface which, besides voice, will allow standard DECT equipment to handle data at 24 kbps. The air interface design permits, in theory, much higher data rates (n x 24kbps, 552 kbps data is theoretically possible) but equipment operating at this speed or with such features is not yet readily available. DECT has been designed to provide access to any type of telecommunication network, thus supporting numerous different applications and services. The range of DECT applications may include residential, PSTN and ISDN access, wireless PABX, GSM access, Wireless Local Loop, Cordless Terminal Mobility CTM, Local Area Network access supporting voice telephony, fax, modem, e-mail, Internet and X.254 Since DECT is an access technology and network-wide mobility is outside the scope of the standard, the DECT/GSM interworking profile (GIP) is a powerful addition providing mobility in DECT infrastructures distributed over multiple sites through GSM mobility functions. GIP allows a DECT terminal to be directly connected to the GSM switching centres, by passing the GSM standard access mechanism. Interworking is done in such a way that the GSM network does not know that it is being accessed through DECT. ETSI working groups have also developed specifications for the DSSI+ protocol that allows inter-working between GSM mobility functions and DECT through the ISDN. The DSSI+ protocol (DE/ SPS-05121) is based on DSSI with enhancements to support mobility functions. Another interesting enhancement for DECT will be provided by the (WRS) Wireless Relay Station, which is a cost effective infrastructure building block providing improved or extended coverage in low traffic 4 However as a representative of ERO stated in a recent paper [32], the total bandwidth requirement for DECT has been related to a voice communication scenario only and, as LAN data traffic had to share the spectrum with DECT telephony, traffic congestion soon may become a problem. That’s why “it is recommended that the licensing of wireless LAN equipment using DECT frequencies should be viewed critically by administrations, because the resulting additional traffic could cause bottlenecks in an office environment” TR4006/D3.1/MARAC/NP/220399/1.0 - 16 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report density applications (both indoor and outdoor). Under line of sight conditions and equipped with the maximum 12 dBi gain antennas, radio ranges up to 5 km are feasible but with application of a WRS – in the same constellation – the radio range can be extended by another 5 km. The majority of DECT product sales are currently for residential and business applications. DECT has proven to be cost effective for the low-end consumer market, showing potential for further cost reductions. Most of the applications in this market segment concern single base station and single handset configurations. However, it should be noted that there are a large number of DECT radio local loop installations, supporting voice applications, used by several hundreds of thousands of subscribers and in operation all over the world (according to DECT forum data [34]). Line of sight ranges beyond 5 km with perfect speech are consistently reported. Orders had exceeded half a million lines at the end of 1996, and growth rates indicate that local loop may become a dominant DECT application. Due to its low cost and primarily the (theoretical today) possibility of enabling services on higher data rates it is thought that DECT could be used in short range maritime applications (within harbour areas). ACTS project EIES [11] intended to organise a series of such trials, based on an enhanced DECT handset which was going to be developed from ACTS COBUCO project. However such an enhanced unit was not developed from COBUCO and thus, today, there is no practical evidence about the possible use of DECT in a maritime communications scenario. 2.1.3. TETRA TETRA is the European standard, recently developed by ETSI, for digital trunked radio systems. TETRA systems focusing on the needs of Professional Mobile Radio users operating in market segments such as:  public safety & public security (police, fire & rescue, customs, ambulance, etc.);  transport (airline, port, airport, airfreight, special transport, river transport, taxi, bus, railway, etc.);  utility (gas, electricity, water, oil, etc.), Industry (manufacturing, plant, distribution, construction, small manufacturing, etc.);  non-emergency authority (government department, public health, environment protection, PTT, etc.),  support services (private telecom operator, user services, maintenance, etc.). TETRA is a fully digital system providing consistent voice quality and low bit error rate for data. There are three basic system variants of TETRA standard (Voice and Data, Packet Data Optimised, Direct Mode Operation). The basic difference between the variations is the multiple access scheme and relevant channel structure on the air interface. TETRA V+D uses a TDMA methodology which permits the use of one 25 kHz carrier by (4) users simultaneously for voice (mainly) or data applications (at a bit rate of up to 7.2 kbps, normally; up to 28.8 kbps if all four channels are reserved for the same user connection). TETRA PDO uses a statistical multiplexing/multiple access scheme (STM/STMA) which is more suitable for bursty data applications at a gross bit rate up to 36kbps while DMO uses a 4 TDMA slot/2 communication channel scheme per 25 kHz carrier. Both TETRA V+D and PDO support a wide range voice teleservices (individual call, group call, acknowledged group call, broadcast call) as well as circuit switched data and packet switched data services with a wide selection of data transmission rates and error protection levels. The frequency band of 380-400 MHz is allocated for TETRA systems by NATO for the exclusive use of Public Safety forces. There are currently no bands allocated permanently to TETRA for commercial applications. However, following the adoption of standards by ETSI, it is quite possible that national authorities will allocate frequencies for commercial TETRA applications in bands such as 450-460 / 460-470 MHz or 870-876 / 915-921 MHz. Obviously, the first users which may implement TETRA are the European land based public safety and emergency services, e.g. police, fire brigades, border control officials. These constitute about 45% of the overall market projected for TETRA for 2001, by a survey of major TETRA manufacturers, according to data included in a report of the European Commission published in 1996 [5]. The existing public safety TR4006/D3.1/MARAC/NP/220399/1.0 - 17 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report networks, currently based on analogue technologies, are coming to the end of their economic lifetime. TETRA provides the key features like encryption, direct mode, fast call set-up time, group calls, which such users need and, on the other hand cannot be provided by other mobile nets developed in the area (such as GSM, for instance, which has a totally different service orientation, philosophy and technical platform). Other land mobile market sectors, addressed by TETRA, such as the Transport sector for instance (which according to TETRA makers projections, is about 18% of the 2001 TETRA overall market) will be much harder to penetrate. European railways for instance, decided to develop their own system, based on an enhanced GSM variation. The success or failure of TETRA, in the railways market, will primarily relate to the speed at which TETRA will develop, versus development costs and R&D speed for the railway communication system. Further, the transport sector is highly cost sensitive and shows “low-medium” interest on TETRA specific functionality (as the report of the European Commission in [5] indicates). As other mobile systems or satellite systems may serve its needs quite well, the future of TETRA will be influenced by cost efficiency and coverage considerations. It should also be noted that maritime user groups, such as the Coast Guard, with similar needs to the police forces, are not currently considered as a focus group for TETRA. There are no references in the literatur about European TETRA pilot projects which involve the coastguard or port users. Further there are no European R&D projects, known to us, conducting trials involving TETRA in maritime applications. Of course TETRA may offer a very high quality of service to coastguard users – especially for voice services. However, due to the very limited number of users, on one hand, and the costs involved in deploying a complex network such as TETRA, on the other, we conclude that there are very few chances for a coastguard to deploy such a network. Coastguard decisions would be, logically, influenced/dependent on other user group decisions (such as police or national PTTs or private operators) to deploy TETRA on wide areas covering extensive coastlines. 2.2. Satellite Systems / Satellite System Proposals & Services According to analysts, conducting research for Motorola, the total telecommunications market in 1997 was about $650 billion. They predict that this market is going to double in 10 years time, and data communications via satellites will play a major role in this growth. Satellite based communication has played a key role in telecommunications for many years. Although still a very risky business for the potential investor (20 multimillion dollar satellites lost in space or at launch since 1990), Merrill Lynch predictions, made in April 1997, suggest that satellite communication business annual revenues will grow at a rate of 500% after the year 2000 [12]. It is not surprising, therefore, that satellite developments attract companies such as Motorola, Alcatel, Lockheed Martin, Loral, Hughes, and successful entrepreneurs like Bill Gates, who intend to invest billions of hard currency in projects like Teledesic, SkyBridge, Iridium, Globalstar, and Spaceway, Astrolink, Cyberstar, etc. We shall soon, therefore, find ourselves under the “umbrella” of a number of systems, which are going to provide a huge variety of services. From narrowband voice (Iridium, Globalstar, ICO, Ellipso,….), paging and short messages (Orbcomm, LEO One, FAISAT,..) to interactive multimedia (Spaceway, SkyBridge, Teledesic) at rates of 20-155Mbps and maybe more. However, there is a unanimous view in the satellite industry that satellite communication will not compete with the land-based fixed or mobile systems. Instead, they will complement land-based systems; offering services where it is impossible, or not economically feasible, for the terrestrial networks to establish provision. All the systems reviewed in this survey which plan, for example, to provide voice services, intend to offer, from day one, dual mode handsets (satellite/cellular) and are establishing partnerships with terrestrial network operators to distribute their services to the end users. Table (1), in the following page, provides a classification of satellite systems in terms of orbits, frequency bands used and basic service orientation. There are then subsections describing developments related to TR4006/D3.1/MARAC/NP/220399/1.0 - 18 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report different bandwidth groupings, including a note on TV GEO satellites multimedia services 5. Tables given in these subsections include a comparison with the existing maritime Inmarsat options where relevant. More details of Inmarsat are included in subsection 2.4.1.3. System type Frequency Applications Terminal Critical Issues Examples bands type/size (usually) Fixed satellite C and Ku TV/Video delivery, 0,6m and larger Latency/ Noise Eutelsat HotBird, service (GEO) VSAT, news fixed earth PanamSat, Intelsat gathering, telephony terminals Most suitable for “broadcasting” applications Direct broadcast Ku Direct-to-home 0.3-0.6-meter Latency/ Noise DirecTV, satellite (GEO) video/audio fixed earth Echostar, USSB, terminals Astra Broadband GEO Ka and Ku Internet access, 20-cm, or more Latency/ Noise/ Spaceway, voice, video, data fixed type of Antenna Cyberstar, Most suitable for terminal usually Astrolink “broadcasting”, “push-pull” multimedia applications Narrowband L and S Voice and low-speed Fixed or mobile Latency/ Noise Inmarsat3, AMSC/ GEO data to mobile terminals (laptop TMI terminals size usually) MEOs L, S, C, X Personal Usually dual mode Space/ Ground ICO, Ellipso Communications Cellular/ Satellite segments (Cellular telephony, phones, ; fixed configuration, data, paging, etc.) phone booths, orbits portable terminals, etc. Broadband LEO Ka and Ku Internet access, Dual 20-cm Space/ Ground Teledesic, voice, video, data, tracking antennas, segments SkyBridge videoconferencing fixed configuration, More suitable for orbits, elevation interactive angle, antenna multimedia services technology Big LEO L and S Personal Usually dual mode Space/ Ground Iridium, Communications Cellular/ Satellite segments GlobalStar, (Cellular telephony, phones and pagers; configuration, data, paging, etc.) fixed phone booth, orbits, etc. Little LEO Usually VHF Position location, "As small as a Line of sight, OrbComm, LEO tracking, messaging packet of power One, E-SAT cigarettes" and omnidirectional Table 1 Satellite Systems Overview 2.2.1. Little LEOs Little LEO systems aim to complement terrestrial data services and public, private mobile radio services. Their satellites usually operate in the VHF band and orbit around earth at heights around 1000km. Target market segments usually include transportation and shipping (messaging & location), business travellers (paging – short medium length e-mail), telemetry and SCADA applications support (for industry, utilities, environment, agriculture), commercial and residential security, and personal safety. Tailor made terminals (fixed, vehicular, pocket-sized handsets) are to be offered depending on the type of application to be served. 5 As it could be, in theory used, at least on ferries or cruise liners carrying satellite TV systems with satellite autotracking facilities. Further the technical concept, implemented in such systems, is quite interesting TR4006/D3.1/MARAC/NP/220399/1.0 - 19 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report There are at least three systems which will provide global (or near global) coverage: The Orbcomm constellation consists of 36 LEO satellites orbiting at 825km. Twenty-eight of the satellites are planned to be put in service by the third quarter of 1998, with the remaining eight planned to be launched during 1999. Twelve satellites are already in orbit. The data rate supported currently is up to 2.4 kbit/s (typically 0.3 kbit/s), though the FCC currently authorised Orbcomm to increase the number of its satellites to 48, and granted further spectrum. The increase in spectrum will allow more efficient and higher downlink data rates. The system is planned for worldwide coverage, and service in Europe is about to start. Service rates are not clear, as yet, but could start out at something like 1 (US) cent per byte or less. Transceivers are expected to cost between $500-1000. The LEO One satellite system will provide store-and-forward coverage of all points between the Arctic and Antarctic Circles. (650 North 650 South) and near real-time service to the most populated regions of the Earth, including ocean regions. Service launch is expected at year 2000. Transceivers will cost $100 to $500. Operators claim that service costs will be competitive with terrestrial-based data communication systems. The Faisat constellation will include thirty-eight (38) small satellites. Commercial operation is likely to start during the year 2000. Full operation is expected no later than 2002. The system will broadly provide worldwide coverage, but a lot of ocean areas will be under-served or excluded. (The constellation provides continuous coverage in areas from 20 to 60 degrees north and south latitude, and near continuous coverage over the other portions of the earth). Phased deployment will start with non time-critical services and will evolve to time-critical markets and value-added services. Terminal costs will vary from $100 to $500 depending on options packaging, and quantity. Service rates, according to the operator, can be as low as $0.25 per message. Table (2) summarises services offered by Little LEO systems File Asset Asset Monitor Alert Wireless Messaging Transfers Tracking & Control Notification E-mail Transportation X X X X X Utility X X X X Oil & Gas X X X X Automotive X X X X X Agribusiness X X X Environmental X X X X X X Security X X X X Emergency X X X Health X X X X X Education X X X X X Retail X X X X X X Business X X X X X X Government X X X X X X Consumers X X X X X Source : FAISAT Table 2 Little LEO services portfolio TR4006/D3.1/MARAC/NP/220399/1.0 - 20 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report Table (3) below summarises data of systems with potential to offer messaging services on a world- wide basis. Inmarsat 3 Orbocomm LEO ONE FAISAT (Inmarsat C) Main Applications Messaging & Messaging & Messaging & Messaging & tracking tracking monitoring monitoring Type Nar GEO Little Leo Little Leo Little Leo Spectrum request L VHF VHF VHF Area World- wide World wide World-wide Near World. Ocean areas not fully covered Service launch Operational 1995 2000 2000 Full coverage Available 1999 ?? 2002 Number of satellites 5 36 to 48 48 38 Data throughput 600 baud 0.3- 2.4 kbps 2.4 – 9.6kbps Data not available (currently) uplink, 24kbps downlink Fixed terminal cost Not applicable ?? ?? $500 (est.) Portable/ vehicle $6000 ?? $500 $100-500 terminal cost (est.) Mobile terminal Not Applicable $500 - $1000 $100 $100 cost (est.) Airtime cost $0,33 per 256bits ?? Terrestrial radio $0.25 per message message compatible System cost 0,69 0.33 0.25 0.25 (billions USD) Table 3 – Little LEO services (versus Inmarsat C) 2.2.2. Narrowband LEOs and MEOs and GEO systems The narrow-band satellite constellations SPCN (Satellite Personal Communication Systems), which are currently planned, focus on the provision of a “GSM-like” portfolio of services (i.e. primarily voice services as well as data services at narrow-band rates) and are intending to “complement” terrestrial cellular systems. Operators will offer, from the very beginning, dualmode handsets which will be able to select either satellite or terrestrial modes of operation, subject to the availability of the satellite and terrestrial systems in the area where the user roams and the user's preferred service arrangements. Services will normally be offered to end–users via their local cellular operators. The most significant systems are:- Iridium: a space segment consisting of 67 operational satellites orbiting at 780km (circular), interconnected via inter-satellite links (5 of the 72 satellites launched are not functional). Each satellite carries 48 spot beams. Construction of 10 out of 12 terrestrial gateways is already complete. Iridium supports digital voice, fax and data at 2.4 kbit/s. Service launch is expected within the third quarter of 1998. Iridium will operate worldwide, including ocean regions. The core customer for Iridium will be the business traveller. Tariffs are expected to be in the range $3 to $6 per minute. A dual mode (Iridium/ GSM) subscriber terminal is expected to cost around $3000. Due to system architecture choices it is highly unlikely that Iridium will be able to offer services to maritime or mobile users at rates better than today’s Inmarsat rates. Globalstar: a constellation which will consist of 48 LEO satellites plus eight in-orbit spares. Eight satellites are already in orbit. A further 36 will be launched during 1998 and the remaining 12 in early 1999. Initial commercial operations should start by the end of the first quarter of 1999. Four gateways TR4006/D3.1/MARAC/NP/220399/1.0 - 21 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report have already been completed, with an additional 34 under construction. The system can cover up to 70 degrees N and S latitudes, provided that gateway coverage is available. Each gateway is expected to provide mobile coverage for an area almost as large as Western Europe. The user segment will comprise fixed, mobile and personal (dual mode Globalstar/ cellular) terminals. The data rates supported are for voice, typically 2.4 kbit/s and for data: 9.6 kbit/s (maximum). Each dual mode handheld terminal is expected to cost about $750. Services prices are expected to be in the range $1.25 to $1.50 per minute. ICO: a system made up of 10 operational medium earth orbiting (MEO) satellites. The constellation has been designed to provide global coverage. Satellite launches are due to begin late in 1998. Full operation is scheduled for the year 2000. ICO will offer digital voice, data, fax and a suite of messaging services (short text-messaging service, voice mail, fax messaging). The voice rate will be 4.8 kbit/s while data rates may reach up to 38.4 kbit/s. The system is designed for global coverage. Target customers are domestic and international travellers, business and government organisations, commercial vehicles, maritime and aeronautical vessels, and residents of rural and remote areas. Service rates are expected to be $1 to $1.70 per minute, with a hand-held terminal costing around $700. Ellipso: a space segment which will consists of 17 LEO satellites in total (including spares), in two distinct constellations (one in elliptical orbit, orbiting between 520 km and 7846 km, and one circular orbiting at 8040 km). Ellipso is expected to start operational service by 2000 offering voice and data services at rates up to 9.6 kbps. Target markets include primarily the northern hemisphere. The southern hemisphere will also be served, but only as far south as 47 degrees latitude (55 degrees with reduced capacity). Ellipso is proposing a tariff of $0.12 to $0.50 per minute (retail) for mobile and fixed telephony, and claims that terminal cost will not normally exceed $1000. Thuraya: is a proposal for a regional system which will consist of one (possibly two) GEO satellites in orbit over the Indian Ocean with coverage area over the Middle East, Turkey, Iran, the Indian Sub- continent, central Asian republics, northern and central Africa, and Eastern Europe. System design is based on GSM technology with adaptations for efficient operation in the satellite environment. First launch is planned for May 2000 with commercial operation beginning in September 2000. Thuraya is planning a maritime terminal and is aiming for an average price of $0.50 per minute. Table (4), which follows, summarises data from systems which will provide personal communication services on a world wide basis, (including near world-wide) or in major parts of Europe. TR4006/D3.1/MARAC/NP/220399/1.0 - 22 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report Inmarsat 3 ICO Iridium Globalstar Thuraya Ellipso Investors Inmarsat Inmarsat, Motorola Loral, Etisalat, Westinghous TRW and Qualcomm Arabsat, e, Harris, many other , Alcatel, Hughes and Israeli France, many other Aircraft and many Industries others Main Voice, data, Voice, data, Voice, Voice, Voice, data, fax Voice, fax, Applications fax fax paging, data, data, and data fax fax Type Nar. GEO MEO LEO LEO Nar. GEO MEO + LEO Area World-wide World-wide World-wide World- Middle east, North wide North Africa, Hemisphere Eastern Europe, and as low as Mediterranean –55 degrees South Service Operational 2000 3Q 1998 1Q 1999 3Q 2000 2001 launch Full coverage Available 2000 1999 2000 2000 ?? Number of 5 12 72 48 1 17 satellites (67 operational) Data Up to 64kbps 4.8 Kbps 2.4 Kbps Up to 9.6 Up to 9.6 Kbps Up to 9.6 throughput voice, 38.4 Kbps Kbps kbps data Access FDMA/ FDMA/ FDMA/ CDMA FDMA/ TDMA W-CDMA method TDMA TDMA TDMA Fixed $20000 ?? Not available Not ?? ?? terminal cost (Inmarsat B) available (est.) HSD +3000 Portable/ $6000 ?? ?? Not ?? ?? vehicle (Inmarsat C) available terminal cost (est.) Dual/ mode Not available $700 $3000 $750 ?? $1000 handset cost (est.) Sat only $3000 ?? $2500 Not ?? ?? handset cost (Mini M) available (est.) Airtime cost $3/min $1-$1,7 / min $3-$6 / min $1,25-1.5/ $0,5/min $0,12-$0.5 min per min System cost 0,69 4.5 4.4 2.6 1+ 0,75 (billions USD) Table 4 – Personal Communications Systems (Examples versus Inmarsat) 2.2.3. Broadband Satellite constellations During the period 1999-2004 it is expected that several satellite systems, able to support data rates between 144Kbps up to 155Mps and interactive multimedia services (data multicasting, high speed internet access, Telemedicine, etc.), will be gradually brought into service. System proposals include SkyBridge (16 Kbps - 2 Mbps in the uplink to satellite direction, 16 Kbps - 20 Mbps for downlink - to the user - direction), Cyberstar (400 Kbps up to 30 Mbps), Teledesic (up to 2.048 Mbps uplink and 16 Kbps-64 Mbps downlink,), Astrolink (384kbps up to 9.2 Mbps) and others. However most of these systems are intended to offer services to fixed users and there are no indications that transportable terminals are under development. TR4006/D3.1/MARAC/NP/220399/1.0 - 23 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report The only exception is Horizons, a system proposal from Inmarsat, which is intended to offer services to mobile as well as fixed users. Horizons constellation will consist of 4 GEO satellites, which will provide global coverage. The system will support multimedia applications at data rates up to 432Kbps. Service launch is expected around 2002. Table (5) below summarises data from broadband systems which will be deployed on a world-wide or near world-wide basis. Horizons SkyBridge Teledesic Cyberstar Spaceway Astrolink Main Investor Inmarsat Alcatel with Bill Gates, Craig Loral Hughes Lockheed Loral McCaw, Boeing Main Voice data Voice, data, Voice, data, Multicasting, Multicasting, Multicasting, applications multimedia interactive interactive broadcasting, broadcasting, broadcasting, multimedia multimedia data streaming data streaming data streaming, rural telephony Type GEO Br. LEO Br. LEO Br. GEO Br. GEO Br. GEO Spectrum ?? Ku Ka Ku (initial) and Ka Ka Ka Areas Major continents World-wide World-wide Major continents World-wide World-wide + Pasific (+680 N, - -680 S) Service launch 2002 2001 2003 Operational in N. 2001 2001 America Full coverage End 2002 2002 ?? 2000 2004 Undefined Number of 4 80 288 For Ku leases 4 initially 9 satellites segment from fixed services satellites; 3 likely for Ka Intersatellite No No Yes Unclear Yes Yes links Access method TDMA CDMA, TDMA, MF-TDMA up, FDMA, TDMA FDMA, TDMA FDMA, TDMA FDMA FDMA, WDMA ATDM down Antenna size A5 to A3 size 0,45+ cm 10 inches 16 inches (initial 66+ cm 90cm – 1.8m (est.) depending on Ku) terminal type Data throughput 64kbit/s – 16 Kbps-2 Mbps 16 Kbps-64 Mbps 400 Kbps (initial 16Kbit/s – up to 6 384kbps up to 432kbits/s uplink; 16 (downlink), up to Ku); up to 30 Mbps uplink, 108 9.2 Mbps Kbps-20 Mbps 2.048 Mbps Mbps (Ka) Mbps downlink downlink uplink Fixed ?? $700 $1000 $1100 Under $1000 Under $1000 terminal cost (SOHO) (est.) Portable Palmtop (64kbits) Not foreseen Not foreseen ?? Not foreseen Not foreseen terminal cost - $500 (est.) Laptop (144kbits) - $750 Transportable (432 kbits) - $1500 Mobile terminal Not foreseen Not foreseen Not foreseen ?? Not foreseen Not foreseen cost (est.) Service cost (est) Voice 0,6 per Access $30-$40 Below $1000 per Access $50 per No data available 0.20$ – 0.25$ minute per month, No month for a 2Mb month, No data per minute for $2,5/ min for data for price per line for price per 64kbps 64kbits/s megabyte or (cost comparable megabyte or connections. $3.3/ min for 432 minute to T1/ E links) minute (cost kbits/s comparable to terrestrial ISDN) System cost $2 $3.5 $9 $1.05 $3.5 $4 (billions) Table 5 Broadband Satellite Systems (Examples) TR4006/D3.1/MARAC/NP/220399/1.0 - 24 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 2.2.4. A note on Multimedia transmission over TV GEO satellites In 1997, the DVB Project released its long awaited data broadcasting specification. This specification paves the way for high-speed data transfer via satellite, cable and terrestrial television channels. Examples of data broadcasting applications include data-casting, downloading software, providing internet services over broadcast channels, and interactive TV. The figure below shows how, with a DVB receiver plug-in PC Card, it is possible to use internet services via satellite, in an application becoming known as "Turbo-Internet"6. Satellite transmission of data is much faster than traditional telecommunications methods. For example, a file containing 10 Mb of information normally takes almost 100 minutes to be downloaded over a typical standard telephone modem operating at 14,4 kb/s. The same file, via satellite, to a high-end server, will take just 2.2 seconds to download at a bit-rate of 38 Mbit/s. Into a high performance Pentium® PC, it will take 14 seconds, at a speed of 6 Mbit/s. Figure 2 Turbo Internet uses spare satellite transponders and PSTN "Return Channels" to deliver high speed TCP/IP data – (Source: The official web site of the DVB project Various European satellite operators including Astra, Eutelsat, and Hispasat have implemented satellite DBNs. With more than 16 million PCs bought in Europe in 1996, and more than 30 million households having direct access to satellite transmissions, there is already wide acceptance of the standardised technologies involved. Data-casting or Internet services would typically use a broadcasters’ extra satellite transponder space to broadcast content into the home via the consumer’s normal satellite dish. The received content is then directed to the consumer’s PC via a coaxial cable interfaced with a DVB compliant plug-in PC card. Once decoded, it may be viewed on a browser, or saved on the PCs hard disk for later use. Where there is a need to have two-way communications, the user connects via the public network to a specific host computer, or to a specific site on the World Wide Web, for example. At the user/subscriber 6 Now-days such a concept is implemented by Hughes in its DirecPC service, with a throughput of 400kbps in the downlink side TR4006/D3.1/MARAC/NP/220399/1.0 - 25 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report end, ‘Conditional Access’ components built into the PC card integrate with the subscriber management system, allowing the broadcaster to track and charge for the data that each subscriber receives. The wide area coverage offered by a single satellite footprint ensures that millions of subscribers can receive data in seconds from just one transmission. Since much of the infrastructure is already in place, very little additional investment is needed from either broadcasters or subscribers to take advantage of data broadcasts over satellite. With possible bit rates of more than 30 Mbit/sec per transponder, a typical CD-ROM could be transmitted to a whole continent in under three minutes. In the future this will be possible over all the DVB delivery media, including cable and digital terrestrial, allowing the data to arrive alongside normal television services. 2.3. Third generation developments (IMT2000 – UMTS) International Mobile Communications 2000 (IMT2000), previously known as, and sometimes still referred to as, Future Personal Land Mobile Telecommunications Service (FPLMTS), is an initiative of the ITU which refers to studies and development of recommendations for third generation (3G) mobile communication systems. Third generation systems aim to unify the diverse systems we see today into a wireless infrastructure capable of offering a wide range of narrow-band and broadband services. The World Administrative Radio Conference in 1992 identified the bands 1 885 - 2 025 and 2 110 - 2 200 MHz as being intended for use on a worldwide basis by administrations wishing to implement IMT-2000. The bands 1 980 - 2010 MHz and 2 170 - 2 200 MHz were identified for the satellite component of IMT-2000. IMT2000 will support a wide range of services based on those of the fixed telecommunication network and those specific to mobile users. Services range from basic wide area paging, through voice telephony (probably the prime requirement of the personal terminal), digital data services, to audio and visual communications. The actual services obtained by a user depend on his terminal capabilities, his subscribed set of services, and the service set provided by the relevant network operator. Services requiring high transmission rates are most likely to be found in high-density areas, such as business centres. UMTS (Universal Mobile Telecommunications System) is the generic acronym used widely in Europe, when referring to IMT2000. The European view is that UMTS systems should be capable, from the very beginning, of much higher data transmission speeds than currently available systems (in the range of 144kbps up to 2 megabytes per second) and should enable wireless multimedia applications such as video conferencing. Various technological initiatives, related to UMTS development, are currently under investigation within the ACTS R&D programme of the European Commission. It is expected that the regulatory framework for UMTS will be clarified within the period 1998-2001 and the first commercially available terrestrial systems will appear about 2002 (satellite based UMTS systems may become available earlier). Due to the enormous investments foreseen to develop the system, and in order to achieve economies of scale, an effort has been made to agree on a third generation unified standard for third generation (3G) systems. In this respect, on January 28, 1998, the ETSI (European Telecommunications Standards Institute) SMG members agreed to a proposal concerning the terrestrial radio general access interface (GRAN interface) to be used for UMTS. It should be noted that, due to spectrum allocations [16] which seriously constrains the coverage area of individual UMTS cells, it is highly unlikely that UMTS networks will be deployed in areas with scarce populations and users. Therefore it cannot be expected that UMTS networks will cover extensive coastlines, archipelago areas, or isolated areas with a very low population density. However it is clear that the UMTS operators wish to “reach” such users and they seek cost effective ways to achieve this. According to the views of the 3GIG group of the GSM MoU organisation [7], the GSM/ UMTS core networks should be designed in such a way as to be accessible to users connected either to TR4006/D3.1/MARAC/NP/220399/1.0 - 26 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report evolving second generation systems, or satellite systems, or cordless systems, etc. Further, they support the development of standard protocols and techniques which will enable the development of “technology platform” independent applications which will be able to make use, seamlessly, of a variety of bearer services and networks. According to GSM MoU, the evolving GSM/UMTS network architecture could be illustrated as follows: Access to people Access to info/people (Voice, Video) (Data, Multimedia) UMTS Core Network PSTN / ISDN + INTERNET / /ATM MAP INTRANET + EVOLUTION ISUP+ TCP-IP+ GSM / UMTS Access (or Access-Core) Network A Narrowband and GRAN Wideband evolution <=384 Kbit/s <=64/115 Kbit/s GSM Other UMTS wide area wide area <=384 Kbit/s Radio Radio Radio <= 2Mbit/s local area Access Accesses Access local area GSM GSM / UMTS /Other UMTS Multimode Access to people and info Figure 3 GSM/ UMTS network architecture, source [7] The third generation core network will provide the opportunity to exploit the enhanced capabilities offered by the associated access network. Figure (4), below, is a high level representation of the overall representation of third generation architecture. Management Systems wireless access 3G Radio Access 3G Core Network(s) UMTS Multimedia GSM BSS GSM Access Appliucations/Services using Multimode a mix of traditional Mobility using SIM(s) Cordless Cordless Systems telecommunications e.g. MAP , Terminal S-PCN S-PCN technologies e.g. MAP, CAP, INAP, (B/N)-ISUP and LAN ISDN B-ISDN B-ISDN ISDN LAN Information Technology technologies e.g. CORBA and Java like techniques. fixed access Transport with support for circuit switched services and packet-swicthed services using (e.g. ATM, FrameRelay, IP, et c). Figure 4 High level 3G architecture – Source [21] It can be seen that the expectation is for a proliferation of a wide variety of terminals with different levels of functionality. This includes a mix of multimedia single-mode/band and multi-mode/band terminals. Some of the terminals will have the capability to use radio and/or fixed wire access networks. TR4006/D3.1/MARAC/NP/220399/1.0 - 27 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report There are also a wide variety of current and proposed access networks with the capability to inter-operate with the 3G core network. The objective is to reduce the dependencies between the services and the terminals/access network. The core network is divided into transport, mobility and intelligence functionality. The transport functionality has the ability to support services suited to either circuit switched or packet switched transport technology. The intelligence sub-network supports all services and mobility management functionality. 2.4. Maritime Communications Having focused on general trends and developments it is now important to consider the current specific maritime situation. In this respect the following paragraphs give a short overview of existing maritime communication framework (GMDSS) with reference to systems comprising it. Further we present emerging/forth-coming systems (such as the automatic ship identification devices) and a series of concepts/system proposals, currently under study in European or international R&D projects, with potential impact on the future of maritime communications. 2.4.1. : GMDSS – The Global maritime distress & safety system Over fifteen years ago the International Maritime Organisation (IMO), began looking at ways of improving maritime distress and safety communications. In 1979, a group of experts drafted the International Convention on Maritime Search and Rescue (SAR), which called for development of a global search and rescue plan. This group also passed a resolution calling for development by IMO of a Global Maritime Distress and Safety System (GMDSS) to provide the communication support needed to implement the search and rescue plan. The system is intended to reliably perform the following functions:  alerting (including position determination of the unit in distress),  search and rescue co-ordination,  locating (homing),  maritime safety information broadcasts,  general communications,  bridge-to-bridge communications. This “new” system, which the world's maritime nations, including the EU, US and other countries, are currently implementing, is based upon a combination of satellite and terrestrial radio services, and has changed international distress communications from being primarily ship-to-ship based to ship-to-shore based (introducing the Rescue Co-ordination Centres). It spelled the end of Morse code communications for all but a few users, such as Amateur Radio. The GMDSS provides for automatic distress alerting and locating in cases where a radio operator does not have time to send an SOS or MAYDAY call, and, for the first time, requires ships to receive broadcasts of maritime safety information which could prevent a distress situation from happening in the first place. In 1988, IMO amended the Safety of Life at Sea (SOLAS) Convention, requiring ships subject to it, to fit GMDSS equipment. Such ships were required to carry NAVTEX and satellite EPIRB’s by 1 August 1993, and fit all other GMDSS equipment by 1 February 1999. In the US, ships were brought under this requirement by the Telecommunications Act of 1996. Small commercial vessels including cargo ships and fishing vessels of less than 300 gross tons are not required to carry radio equipment necessary to comply with the GMDSS. Such vessels may be required by other regulations or laws to carry radio equipment and may operate in the same port areas or coastal waters as GMDSS equipped vessels. TR4006/D3.1/MARAC/NP/220399/1.0 - 28 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report After full implementation of the GMDSS on February 1, 1999, non GMDSS equipped vessels may experience difficulty in establishing communications with vessels complying with the GMDSS. These difficulties are associated with the differences between the automated equipment required in the GMDSS and the non-automated equipment typically carried on small commercial vessels. The GMDSS consists of several systems, some of which are new, but many of which have been in operation for many years. Specific radio carriage requirements depend upon the ship's area of operation, rather than its tonnage. Some of these systems are discussed below: 2.4.1.1. The COSPAS-SARSAT System COSPAS-SARSAT is an international satellite-based search and rescue system, established by Canada, France, the USA., and Russia. These four countries jointly helped develop a 406 MHz satellite emergency position-indicating radio-beacon (EPIRB), an element of the GMDSS designed to operate with COSPAS- SARSAT system. These automatic-activating EPIRB’s, now required on SOLAS ships, commercial fishing vessels, and other ships, are designed to transmit to a rescue co-ordination centre vessel identification and an accurate location of the vessel from anywhere in the world. 2.4.1.2. NAVTEX NAVTEX is an international, automated system for instantly distributing maritime navigational warnings, weather forecasts and warnings, search and rescue notices and similar information to ships. A small, low- cost and self-contained "smart" printing radio receiver installed on the bridge of a ship checks each incoming message to see if it has been received during an earlier transmission, or if it is of a category of no interest to the ship's master. If it is a new and wanted message, it is printed on a roll of adding-machine sized paper; if not, the message is ignored. A new ship coming into the area will receive many previously broadcast messages for the first time; ships already in the area which had already received the message will not receive it again. No person needs to be present during a broadcast to receive vital information. 2.4.1.3. Inmarsat Satellite systems operated by the International Maritime Satellite Organisation (Inmarsat), are also important elements of the GMDSS. Three types of Inmarsat ship earth station terminals are “type approved” for use by the GMDSS. These are the Inmarsat A, B & C. The Inmarsat A and B, provide ship/ship, ship/shore and shore/ship telephone, telex and data services, including a distress priority telephone and telex service to and from rescue co-ordination centres. Data rates supported are usually in the area of 2.5 kbps – 9.6 kbps. However “high speed” versions of both terminals exists which supports up to 64kbps. The Inmarsat C provides ship/shore, shore/ship and ship/ship store-and-forward data (at rates up to 600baud) and telex messaging, the capability for sending preformatted distress messages to a rescue co- ordination centre, and the SafetyNET service. The Inmarsat C-SafetyNET service is a satellite-based worldwide maritime safety information broadcast service of high seas weather warnings, NAVAREA navigational warnings, radio-navigation warnings, ice reports and warnings generated by the USCG- conducted International Ice Patrol, and other similar information not provided by NAVTEX. SafetyNET works similarly to NAVTEX in areas outside NAVTEX coverage. Inmarsat C equipment is relatively small and lightweight, and costs much less than an Inmarsat A or B. Inmarsat A and B ship earth stations require relatively large gyro-stabilised antennae; the antenna size of the Inmarsat C is much smaller. Inmarsat also operates an EPIRB system, the Inmarsat L, which is similar to that operated by COSPAS-SARSAT. The Inmarsat C equipment should have an integral satellite navigation receiver, or be externally connected to a satellite navigation receiver. That connection will ensure accurate location information to be sent to a RCC (Rescue co-ordination centre) if a distress alert is ever transmitted. The Inmarsat network provides good quality voice and data communications. Ship operators are increasingly using E-mail and DNID message possibilities for fleet and logistics management (cargo, passengers, crewing, equipment, provisions, maintenance and repair). However the users complain that the TR4006/D3.1/MARAC/NP/220399/1.0 - 29 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report price they pay is very high (currently above $3 per minute for voice calls and something in the area of $0,3 per 256 byte message, if Inmarsat C is used). Indicative market prices for Inmarsat terminals are: Inmarsat B: $20.000, Inmarsat B/HSD $23.000 and Inmarsat C: $6000. 2.4.1.4. HF Radiotelephone The GMDSS includes HF (high frequency) radiotelephone and radio-telex (narrow-band direct printing) equipment, with calls initiated by DSC (digital selective calling). Worldwide broadcasts of maritime safety information are also made on HF narrow-band direct printing channels. To meet these GMDSS requirements, the different maritime administrations have begun to improve high frequency (HF) ship- shore radio safety services from the communication stations to the maritime community, as well as narrow-band direct printing broadcasts. 2.4.1.5. Search and Rescue Radar Transponders (SARTs). The GMDSS installation on ships include one or more search and rescue radar transponders, devices which are used to locate survival craft or distressed vessels by creating a series of dots on a rescuing ship's 3 cm radar display. The detection range between these devices and ships, dependent upon the height of the ship's radar mast and the height of the SART, is normally less than about ten miles. (19 kms) 2.4.1.6. DSC :Digital Selective Calling The IMO introduced DSC on VHF, MF and HF maritime radios as part of the GMDSS system. DSC is primarily intended to initiate ship/ship, ship/shore, and shore/ship radiotelephone and MF/HF radio-telex calls. DSC calls can also be made to individual ships or groups of ships. DSC distress alerts, which consist of a preformatted distress message, are used to initiate emergency communications with ships and rescue co-ordination centres. When fully implemented, DSC will eliminate the need for persons on a ship's bridge or on shore to continuously monitor radio receivers on voice radio channels, including VHF channel 16 (156.8 MHz) and 2182 kHz now used for distress, safety and calling. A listening watch aboard GMDSS- equipped ships is scheduled to end on 2182 kHz on 1 February 1999, and on VHF channel 16 sometime after that date. The DSC-equipped VHF and MF/HF radios should be externally connected to a satellite navigation receiver. This connection will ensure that accurate location information is sent to a rescue co-ordination centre if a distress alert is ever transmitted. In the USA, the FCC regulations actually require that a ship's position be manually entered into the radio every four hours on ships required to carry GMDSS equipment, while that ship is underway (47 CFR 80.1073). Once SOLAS ships are allowed to disband watchkeeping on VHF and MF radiotelephone channels, other ships are going to need DSC-equipped radios to contact them, particularly in a passing situation. The VHF, MF and HF radiotelephone equipment carried on ships should include a DSC capability as a matter of safety. It should be noted here that VHF DSC or HF DSC can establish a communication link for data, but not transmit any data because of low baudrate (100 bd). 2.4.1.7. GMDSS Areas The definition of SAR areas for GMDSS serves two purposes. It describes the sea regions, relevant to distance from coast, where GMDSS services are available, and also defines what type of GMDSS equipment ships must carry in order to sail in a given area. Governments define the GMDSS sea areas. Sea Area A1 is an area within the radiotelephone coverage of at least one VHF coast station in which continuous digital selective calling (ch70) alerting and radiotelephony services are available, as defined by the International Maritime Organisation. Ships classified for GMDSS-area A1 must carry a satellite EPIRB, a NAVTEX receiver (if they travel in any areas served by NAVTEX), an Inmarsat-C SafetyNET TR4006/D3.1/MARAC/NP/220399/1.0 - 30 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report receiver (if they travel in any areas not served by NAVTEX), a DSC-equipped VHF radiotelephone, two or more VHF handhelds, and a search and rescue radar transponder (SART). Sea Area A2 is an area within the radiotelephone coverage of at least one MF coast station in which continuous DSC (2187.5 kHz) alerting and radiotelephony services are available, as defined by the IMO. GMDSS-classified ships travelling this area must carry a DSC-equipped MF radiotelephone plus equipment required for Sea Area A1. Sea Area A3 is an area within the coverage of an INMARSAT geostationary satellite in which continuous alerting is available. Ships travelling this area must carry either an Inmarsat A, B or C ship earth station, or a DSC-equipped HF radiotelephone/telex, in addition to equipment required for A1 and A2 Area. Deep sea vessels usually fall in this category Sea Area A4 is what is left out of the rest three areas (i.e the polar regions which are out of Inmarsat’s coverage. Ships travelling in A4 must carry a DSC-equipped HF radiotelephone/telex, in addition to equipment required for areas A1 and A2. 2.4.2. Transponders/ AIS devices In the next few years the majority of European Union countries will have spent millions of ECUs to develop their Vessel Traffic Services (VTS) infrastructure. This is due to the fact that today’s VTS make extensive use of very expensive radar sensors, each covering a limited geographical area. One of the most interesting issues, on which a series of European R&D projects are currently focusing, is how “Transponders” i.e. shipborne Automatic Identification System (AIS), if installed on board vessels, could be used in the context of VTS to improve navigation safety, efficiency, cost effectiveness and geographical coverage of the VTS area and beyond. Although about to be overtaken by an IMO carriage requirement for a universal AIS, according to the existing regulatory framework for GMDSS, two components can be used today for “realising” aspects of AIS.  Polling an Inmarsat C satellite communication terminal  The VHF / DSC As previously mentioned, DSC [29] has been adopted by IMO primarily for distress and safety calling in the GMDSS (using maritime VHF band’s channel “70”). It is able to support a number of other facilities, such as automatic shore-to-ship telephone calls in the maritime VHF band and automatic identification. The system performs best when linked directly with an on-board electronic position-fixing device, which can provide accurate information automatically (typically this will be a GPS receiver). On interrogation by a suitably equipped base station, typically a coast station, the on board equipment responds initially with its identification, which is given by its Maritime Mobile Service Identity (MMSI), type, draught, length, position, time, course and speed over the ground, navigation status, cargo hazard category, next port and destination. It should be noted that some of this information is manually entered to the system and so is only as accurate as its last update. The Inmarsat-C system, when used as a “transponder”, in some ways has a similar functional behaviour to that of VHF/DSC, although the accuracy of position is not as good as that afforded by VHF/DSC as it is a store-and-forward system. A ship terminal can be polled to obtain a limited navigation message (typically identity, position, course and speed over the ground) and benefits from being linked directly to an electronic position-fixing system. However, the shipboard system can also be programmed to report ship identification data at pre-ordained intervals. Unlike the use of VHF/DSC, the use of this system incurs costs to the user, in this case the owner of the associated Data Network Identification (DNID), and the permission of the on-board system’s owner is required before this can be installed on his system. TR4006/D3.1/MARAC/NP/220399/1.0 - 31 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report However the efficiency of both systems, having been designed to serve other tasks, is not optimised for the automatic identification process. In the case of VHF/DSC it can be unsatisfactory in high traffic density areas. (To avoid congestion on channel 70, the traffic associated with the AIS function is limited to 15% of channel capacity.) In the case of Inmarsat C besides the technical limitations imposed by its store and forward operation, as previously mentioned, there is also a question of charges, which could result in significant operational costs if used at frequent intervals over a large number of ships. Thus Inmarsat C is best used only for long range tracking of specific vessels. Pursuit of a universally acceptable AIS has followed a tortuous path at IMO. However, after a debate over several years, a series of actions has taken place which will eventually “amend” the current regulatory framework, resulting in the use of a new type of AIS. As part of this process, in 1997, IMO requested ITU to allocate two frequencies in the Maritime VHF band for worldwide use by AIS. Further, the IMO’s safety of navigation sub-committee, (May 1998) decided to adopt a series of AIS performance standards [30]. ITU, responding to the IMO request, in November 1997, assigned a pair of simplex frequencies and has prepared (March 1998) a draft technical recommendation which sets out the technical characteristics of a Universal Shipborne Automatic Identification System (now to be known as AIS). The system described in the ITU draft recommendation [31] is a broadcast transponder based on a radio access method known as Self-Organised Time Division Multiple Access (SOTDMA) [28]. It seems clear that a worldwide standard will emerge shortly, in relation to AIS devices. Although not finalised, first reactions to the draft ITU recommendations are expected during 1999. Looking a little further into the future (unmanned vessels, automatic berthing, etc.), maritime users have expressed very strict requirements relating to navigation, which will affect the performance of the communication devices supporting navigation tasks. The draft European Radionavigation Plan and relevant German plan (both under discussion but not as yet adopted), specify that a ship, if navigating in restricted waters or in the vicinity of a port, should report its position every 1 to 2 seconds. The typical requirement for navigation accuracy, in confined waters, is 10 metres. It is therefore quite obvious why in Europe today both industry and the scientific community have been keen to devise new concepts and develop new types of more efficient AIS. This has stimulated several broadcast radio transponder developments based on the use of SOTDMA, the manufacturers of which are now working to comply with the emerging performance standards and technical specifications for Type Approval. Another interesting concept for AIS operation is currently under study in the ArchiPELAGO project. This is briefly introduced in paragraph 2.5.1. One of the most interesting possibilities of systems designed to meet the requirements of AIS is that they will have a capability to be used for a series of data services such as for instance, a short message service. This feature could be used for the exchange of a set of standardised messages between the vessel and the vessel traffic or search and rescue authorities. In theory, emerging AIS equipments will be able to transfer data from any other system connected to them. However, caution is required to ensure that the ability of these systems to provide additional functions is not to the detriment of the prime AIS functions identified by IMO. TR4006/D3.1/MARAC/NP/220399/1.0 - 32 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 2.5. Communication Technology proposals with potential impact on maritime communications 2.5.1. Maritime Enhanced Mobile Radio MESMR is a system proposal [35] concerning a VHF radio network, which can be deployed regionally in the vicinity of a port or of a Vessel Traffic Service. The system uses multiple narrow-band channels for the communication of packet data at rates up to 19,2 kbps. The service portfolio is similar to that of little LEOs presented previously, but the air interfaces will support automatic identification & reporting operations, as specified in the recently adopted standards by IMO [30] (using SOTDMA access [28] specified in a draft currently available from the ITU [31]. Further, it can use an «on demand» access scheme proposed by the MESMR system developers. ArchiPELAGO standard terminals will initially support narrow-band data applications (voice is to be implemented at a later stage) and will provide point- to-point and/or point-to-multipoint connections, ship-ship and ship-shore. Service rates can be set at a fraction of today’s GSM rates. 2.5.2. DSRR, E-DSRR DSRR (Digital Short-Range Radio) was intended to be a family of short-range wireless systems for private land mobile radio services to provide low rate voice and data channels with a speed of 16 kbps. The system concept was originally designed for point-to-point communications between base stations and portable or mobile stations in simplex or semi-duplex mode. An interim ETSI standard existed (I-ETS 300 168) (now withdrawn) describing system operation in the 900 MHz frequency range with maximum transmitter power of 4W. This seems to be one of the advantages of DSRR systems, as it enables operation with extended coverage within hostile propagation environments, such as ships, industrial plants and harbours. The allocation of two frequency ranges around 889 and 934 MHz, with bandwidth 2 MHz each, was originally recommended by CEPT for the operation of DSRR systems (a more recent decision re-allocated these frequencies for GSM use). DSRR commercial systems, based on original ideas included in ETSI I- ETS were never developed. The main reason was the bandwidth limitation defined in the standard, which made the system unsuitable for the emerging broadband applications, such as real time video and high- speed data transmission. The restriction to half-duplex operation was also critical for interpersonal/interactive applications, like video conferencing and CSCW. The concept of an Enhanced Digital Short-Range Radio System (E-DSRR) was originally introduced under the RACE MoEBIUS (Mobile Experimental Broadband Interconnection using Satellites) project. It is based on DSRR frequencies but introduces a series of basic enhancements related mainly to bandwidth, data rate (nx64kbps) and transmission modes (full duplex synchronous). A first prototype system has been developed in MoEBIUS, primarily serving as a shipboard wireless extension of Inmarsat satellite services to support Tele-medicine and Tele-working applications. Extensive tests during that project proved the technical feasibility of the concept. [8,9,10] This concept has been refined further, based on user surveys and trials carried out under the ACTS EIES project [11]. E-DSRR radio technology was used to set up the EIES wireless multimedia demonstrators. EIES developed a prototype dual mode wireless platform (the radio mode based on E-DSRR and the satellite mode based on Immarsat HSD) in order to demonstrate early (i.e. during 1997, 1998) the potential advantages of applying third generation systems principles (e.g. UMTS principles) to maritime communication systems, and of course to provide means for ships to access the advanced EIES land-based services. A series of trials was conducted successfully in the ports of Bordeaux, Brest and Bremen TR4006/D3.1/MARAC/NP/220399/1.0 - 33 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report Inmarsat Fixed WEB Server Client LAN Port A IP Router Communications Server Stabilized Antenna ISDN ATM DSRR Base Station HSD Unit DSRR Interworking Communications Unit Server IP Router Mobile Access LAN Port B Global: Inmarsat HSD Mobile Client Port Entry: DSRR Fixed Client WEB Server Figure 5 EIES project dual mode wireless platform The current E-DSRR prototype system is intended to provide short range as well as long distance cordless links for video, audio and data communications, including multimedia. The system can provide cordless links between user terminal equipment and cordless access to wide area networks. The maximum net bearer rate (currently) is 134.4 Kbps. Lower speeds, i.e. 64 Kbps, can also be selected by the user according to the actual Quality-of-Service (Q-o-S) or network access requirements. It should be noted that applications using high bearer rates typically do not require terminal mobility. The system has therefore been designed for stationary operation. Omnidirectional antennae achieve short-range coverage. The use of directional antennae will enable coverage up to some 50 km without need of repeaters. There are attractions providing short, medium and long distance links for fast and cost effective deployment of fixed, quasi-fixed and mobile services in areas with low traffic volume and high terrestrial infrastructure costs. TR4006/D3.1/MARAC/NP/220399/1.0 - 34 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 2.5.3. TOMAS project proposal for an S-UMTS terminal and services Satellite-UMTS as part of the third generation mobile network, will be a valuable complement to terrestrial telecoms. It is interesting to note that S-UMTS services can be achieved using operational satellite constellations which are available today (Inmarsat for example). The ACTS TOMAS project is currently developing a terminal prototype based on the Inmarsat B/HSD terminal, which enables the following services over Inmarsat (Low & Medium speed) or ESA EMS constellation (high speed): Tables below, quoted from [19], summarise the basic specification of the services: Table 6 TOMAS services TOMAS bearer services specification Low Speed Medium Speed High Speed Sync. Async. Sync. ISDN Sync. ATM Layer 1 Unrestricted data (transparent bitstream) Layer 2 ff user/application defined Bearer Rates N x 8 Kbit/s 1.2-33.6 K N x 8 Kbit/s 64 K, 128 K N x 8 Kbit/s N x 8 Kbit/s (Forward) 64 K max. 384 K max. 2048 K max 2048 K max 1.2-33.6 K Bearer Rates N x 8 Kbit/s 1.2-33.6 K N x 8 Kbit/s 64 K, 128 K N x 8 Kbit/s N x 8 Kbit/s (Return) 64 K max. 384 K max. 2048 K max 2048 K max 1.2-33.6 K Modes full duplex full duplex full duplex full duplex full duplex Duplex simplex simplex simplex simplex simplex asymm. asymm. asymm asymm. asymm. Network Access ISDN, PSTN PSTN ISDN ISDN ISDN ATM Call Control T-GUI T-GUI T-GUI D channel T-GUI PVC (SCV) T-MAC T-MAC T-MAC T-MAC T-MAC T-MAC UMTS Adaptation User Channel Routing and Bearer Control through UAL QoS BER < 1E-5 Delay and higher order performance statistics subject to trials Terminal Type modified Inmarsat-M or B modified Inmarsat-B Interfaces USI, USB, RS-232 USI, USB, RS-232 USI, USB BRI USI, USB G.703 TOMAS Tele-services specification Video/Audio Multimedia IP Connectivity Layer 1 N/A N/A Ethernet Layer 2 N/A N/A 802.2 MAC Layer 3 N/A N/A IP Layer 4 H.223 H.223 / T.120 TCP/UDP (user def.) Layer 5 ff H.324M H.324M/MPEG-4 user defined Bearer Rates (Forward) N x 8 Kbit/s N x 8 Kbit/s N x 8 Kbit/s up to 384 Kbit/s up to 384 Kbit/s up to 2048 Kbit/s Bearer Rates (Return) N x 8 Kbit/s N x 8 Kbit/s N x 8 Kbit/s up to 384 Kbit/s up to 384 Kbit/s up to 2048 Kbit/s Modes full duplex full duplex full duplex asymmetric asymmetric asymmetric Network Access ISDN ISDN ATM Call Control ACI ACI ACI Dial on Demand UMTS Adaptation User Channel Routing and Bearer Control through UAL QoS BER, delay and higher order performance statistics subject to trials Terminal Type modified Inmarsat-M or B modified Inmarsat-B Interfaces/Displays Video overlay Tx/Rx Video overlay Tx/Rx AUI, BNC PCMCIA camera input PCMCIA camera input Headset in-/output Headset in-/output T.120 internal data Explanation: T-GUI: TOMAS Graphical User Interface on user terminal or MST (Mobile satellite terminal) T-MAC: TOMAS Media Access Control Protocol USI: Universal Serial Interface . The USI is a universal interface defined by TOMAS for low, medium and high rate bearer services. It includes the data and signalling circuits of standard V.11, X.21, V.36 and RS-449 interfaces and is therefore compatible with most of the existing data terminal equipment. In order to implement S-UMTS signalling between the user and satellite terminals, the USI furthermore includes circuits for call control and bearer monitoring. As such the USI adds S-UMTS signalling capabilities to existing serial interfaces USB: Universal Serial Bus (for future implementation) N/A: No external interfaces provided ACI: Graphical Applications Control Interface TR4006/D3.1/MARAC/NP/220399/1.0 - 35 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 2.5.4. Proposals on data Integration afloat Modern ships have become increasingly complex to operate. Ship crew sizes are continually dropping (in the range of 60-70% compared to the levels 10-20 years ago) reducing the availability of on-board skills, while ship sizes are growing and on board systems are becoming more sophisticated and technology dependent. To a certain extent the problems caused by ship crew reduction could be compensated by introducing on board decision support tools but it is generally acknowledged that shore-based personnel should be more involved in ship operation to achieve efficient ship management. This will require reliable and cost effective communications (as the day-to-day ship-shore communication will continually increase). Further, it requires the means to integrate and “fuse” data, on board, in order that key information related to “safety” or “cost” critical on-board systems (machinery, propulsion, cargo, navigation etc) becomes available in a variety of on-board locations and accessible from the shore. It also requires integration of on-board networks with an on-board communication system, in order that information available on shore can be, for instance, downloaded directly to the on-board sub-system when such information is required (such as in case of ECDIS updates). Finally it also requires access to communication bearers (satellite and/or radio) which may support communication at much higher data rates, as otherwise it is impossible to establish and execute computer supported co-operative work scenarios which, for instance, are required in the case of remotely (shore) assisted damage surveys. The regulatory environment of ship operations also undergoes significant changes due to new resolutions or directives which come into force (SOLAS, MARPOL, HAZMAT, ISM, etc), imposing additional administrative “overload” to on board personnel. The most obvious changes are related to the introduction of ISM code, which imposes process certification, and much stricter document control. Further, it mandates a regular reporting procedure to be followed. It will be impossible to apply ISM, efficiently and accurately, without the introduction of specialised, computer based applications on board (and ashore) and without enabling access to the available communication bearer services directly from in-side the applications. On the shore side now the effort for improvement of the VTS services efficiency, as trials executed under TAP POSEIDON project indicated, will soon result in the introduction, on board vessels, of new communication technologies (such as the AIS) and will add a whole range of new data communication tasks, mostly related to transmission of coded messages (but also requiring free text exchange). Finally, a series of “bandwidth hungry” applications (such as Tele-medicine applications, on line access to passenger or port information multimedia databases and geographical information systems, remotely assisted berthing operations, etc.) also require bearers with capacity to operate at high data rates and establishment of means on board ship which can enable access to the communication services whenever it is needed from the location where it is really required. To cope with such changes, requiring more and more ship-borne and shore side data integration a few things can be done:  First, local area networks should be established on board permitting the high level coupling of on board subsystems, data exchange among subsystems and data fusion. Such networks, obviously, should be based on widely accepted standards and an open architecture. In this respect an intensive research effort is undertaken in Europe during the recent years (MiTS, ATOMOS, DISCI projects and most recently PISCES and DISCII projects)  Second, a “single” communication node via which the on board information systems will be coupled with their on shore components needs to be established.  Third, a “single” (common) user interface which shall enable seamless access of available communication bearers and protocols based on quality of service and cost effectiveness considerations needs to be established. The development of an on-board Communication server which integrates existing or emerging communication bearers and enable on-board users to access them seamlessly, via a common user interface, is the primary objective of the COMMAN project, as stated in the very beginning of this report. TR4006/D3.1/MARAC/NP/220399/1.0 - 36 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report The following paragraphs summarise the projects which are considered most relevant, from the COMMAN perspective, to the research currently being undertaken on our project, namely PISCES and DISC/ DISCII in Europe and ISIT in USA. 2.5.4.1. PISCES/ DISC/ COMMAN The PISCES project will develop and establish a common ISC data-bus standard to enable the development of safety and efficiency enhancing applications for ship supervision and control. PISCES work is based on the existing MiTS standard (Maritime Information Technology Standard).7. Off-ship networks On-ship non safety-critical Off-ship Gateway applications Consistent information-models giving access to high quality ship state data. Gateway/Firewall Safety critical applications Protocols and standards for interoperability and off-the-shelf technology. Figure 6 ISC network overview – Source: PISCES brochure MiTS, in its current incarnation was developed in about 1992. It is still well suited for todays integrated system with loosely coupled and relatively autonomous modules. Through the use of MiTS in several ship and shore-based installations and through a number of research projects, several potential improvements have been identified: PISCES main technical contributions are expected to be:  A thorough analysis of user, technical and safety requirements for the next generation ISC protocol, based on compatibility with the existing MiTS protocol. The requirements established through the PISCES project are directed to what can be called “the glue” that binds a multi-manufacturer integrated ship control system together. This will lead to the implementation of new functionality as indicated in the following:  Support for higher bandwidths and multimedia applications, e.g., by transporting ECDIS and RADAR images on the system network. This type of traffic must be integrated with fast and time critical low volume control information with sufficient consideration for system safety. There is also a need to consider new developments in the telematics domain, e.g., WWW and internet technology.  Support for more integrated ISC systems with tighter coupling between modules. A trend is that more of today’s process level integration must be performed at the system level in future installations. This requires more attention to safety and reliability, e.g., by supporting redundant networks.  Generally increased functionality for the application programmer through inclusion of WWW type technology (Java), object oriented technology (e.g., based on CORBA) and by supplying better design and validation tools.  Better support for applications related to high-level information integration e.g., fleet management, VTS, voyage recorders and on-line analysis and decision support. This must be achieved by 7 Several proprietary solutions have been developed for ISC system integration, but the MiTS protocol is the only open protocol in general use today. MiTS has also been accepted by IEC TC80/WG6 as a basis for the future IEC 1162-4 standard. MiTS is based on Ethernet and Internet protocols. MiTS is supported by MiTS Forum, an independent maintenance organisation with about 25 member companies from the whole world. MiTS Forum also maintains informal liaisons with European, Japanese and US manufacturer and standards associations. Furthermore, the MiTS protocol is complementary to the standard initiatives that are the most viable today (e.g., Fieldbus, wire-less ship-to-shore and ships’ administrative networks). TR4006/D3.1/MARAC/NP/220399/1.0 - 37 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report improving the quality of the information that can be retrieved from the control system by establishing common information models and companion standards.  Support for better validation of the protocol and the applications and systems using the protocol. The next generations of systems will be increasingly more complex and the evaluation of safety and reliability will become more critical. This requires in-project verification of results and the development of validation procedures and tools for application of these procedures.  Better support for yards, system integrators and system operators. The commercial success of ISC systems requires that errors or problems can be identified, isolated and preferably corrected during normal operation. This requires support for run-time support tools as well as for remote shore-based diagnostics and modification.  A contribution to the definition of a global maritime telematics infrastructure where the ship with all its sensors and its automation and navigation systems is made an integral part of the larger network . PISCES project will produce protocol and companion standards that can be used by COMMAN. This comprises of the physical network and its topology, the network protocols, the services provided by the network, tools to develop and maintain integrated systems and applications necessary to operate and maintain the system. The requirements relevant for COMMAN are the information type requirements and some service related requirements. These specify the types of data and information which are being transferred and services required for system maintenance, error and maintenance reporting, documentation and testing, etc. The liaison between the two projects is handled by the project co-ordinator as well as other contractors which each participate in both projects. All PISCES results will be made available to COMMAN and requirements from COMMAN will be put forward to PISCES. DISC is a study funded by TRANSPORT programme which provided recommendations on an ISC standard [41]. The main purpose of the DISC standard is to ensure full integration of shipboard systems in a standardised fashion, with enhanced maritime efficiency, competitiveness and safety. Many of the non- functional requirements relevant to COMMAN have already been defined by the DISC project. DISC proposes a four-layer reference model as a skeleton for a future European/International ISC standard. The layers are used to structure the requirements for ISC systems; they do not regulate the control flow within the ISC system. Thus, the most relevant requirements for COMMAN are the requirements to the HMI, to the application layer and the architecture layer. DISC II is an ISC demonstration project funded by TRANSPORT programme of DGVII which will build on the results of DISC and ATOMOS projects and MiTS. This project will demonstrate many aspects of ISC systems in a setting with more than 20 contributors from all over Europe. PISCES will be a part of this demonstration (through the joint participation of most of the manufacturers in PISCES and DISC). The intention is that DISC II will be used as a secondary demonstration event for the PISCES project. With respect to COMMAN, DISC will develop a prototype for the internal gateway/firewall that could be used to interconnect COMMAN server to the PISCES bus. TR4006/D3.1/MARAC/NP/220399/1.0 - 38 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report Figure 7 PISCES/ COMMAN/ DISC II interrelationship – Source: PISCES www site TR4006/D3.1/MARAC/NP/220399/1.0 - 39 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 2.5.4.2. ISIT The ISIT project was a $4 million 18 month development project funded by the USA government’s ARPA/MARITECH programmes, undertaken by a team of eight firms (Marine Management Systems Inc, Ultimateast Data Communications Ltd., Radix Systems Inc,. M. Rosenblatt & Son Inc., Sperry Marine Inc, General Electric Marine Systems, ABS Marine Services Inc., SINTEF Automatic Control - MiTS). The project (executed in 1995-1997) objective was to design an industrial platform to provide all shipboard computer applications with a common operating environment, which would integrate data from control systems, including machinery, cargo and bridge control. In this sense ISIT goals are comparable to PISCES & COMMAN goals. The main ISIT design goals, as listed in [40] were: IT Function Industry Requirements Today's Systems ISIT Platform Capabilities Directly access data in all control No common interface to control Direct access to all control systems data systems and convert to common Data Collection system data. Most data entered with conversion to a standard protocol format, store in database for manually. (MiTS) and standard database storage. access by applications. Store all shipboard applications data in common database shared Each software application maintains Common client/server database for all Database by all applications using its own custom data-base. shipboard applications. Structured Query Language (SQL). A robust industrial-strength Built on Industrial strength Windows Most systems use MSDOS or Software operating system platform NT operating system with layer of Windows as platform with minimum Platform supporting all shipboard software standard services for compliant level of security and stability. applications. applications. Common local and remote Common system administration Configuration management and System configuration management and manager (executive) for all applications application security dependent on Administration security for platform and giving reliable remote management custom applications. shipboard applications. capability. A common user interface to all Non standard custom Common shipboard communications communications services for any communications interface for Communications interface used by all software shipboard application including applications for limited services - applications. IT system support Inmarsat A, cellular, etc. Common interface between Common interface to shore public office and maritime Earth stations may have non-standard networks and office networks and Shore Interface communication services interface to public networks & office services through a Virtual Earth Station including public distribution requiring custom software. (VES). networks. Table 7 – ISIT design goals ISIT shipboard-based components include:  ISIT Network Backplane: a shipboard data network, utilising a pre-emptive, multi-tasking operating system that connects sub-systems to the three ISIT network servers and the shipboard administrative network.  Client/Server Database Engine: a commercial database management system offering full transaction processing and security features. This component serves as the repository for all critical ship operating and configuration information. The database server may also be used by any application developer for database activities such as historical trending.  Process Server: responsible for receiving, processing and storing information from the sub-systems, housing all the software application components, such as the configuration manager, network matching interface software, data replicator, e-mail system, document management system and graphical display. TR4006/D3.1/MARAC/NP/220399/1.0 - 40 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report  Communications Server: a workstation responsible for all communication functions between the vessel and the shore-based satellite earth station. This server receives its outgoing traffic from the process server and transfers the data it receives from ashore to the process server for storage and shipboard distribution.  ISIT shore based components include:  Virtual Earth Station Communications Hub (optional): a computer system that provides uniform access to multiple maritime satellite services as well as access to public telephone networks and the Internet.  Shore office Data Replicator/Message Processor: a software module that resides at a shore office and is responsible for receiving, decoding and storing communications and transmissions received from ships. This module also prepares data for transmission to a ship through the virtual earth station. The ISIT Platform is based on the Microsoft BackOffice Suite (including Windows NT, SQL Server, and SMS). It is a modern, object oriented design, developed in C++, using CORBA object broker to distribute resources across the network. The first ISIT related standard, "The Standard Guide for the Implementation of a Fleet Management System Network" (ASTM F1756) was approved by the standards organisation ASTM (American Society for Testing and Materials) in the last quarter of 1996. It has now been entered into the ISO International Standards Organisation process, under the TC8 Ships and Marine Technology committee [50]. It has received the country member support necessary for it to be entered as a work item for ISO standard development. Norway, USA, Russia, Japan and Portugal will form the standards committee. TR4006/D3.1/MARAC/NP/220399/1.0 - 41 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 3. Presentation of results from the user requirements capture & analysis process This section presents the results of the user needs survey conducted by COMMAN project. 3.1. Methodology and introduction to the chapter The project adopted an iterative methodology for user requirements’ capture and analysis, which will result in a “user centred” approach for system design. COMMAN methodological approach, briefly outlined in this paragraph, is based on the following:  the CODE project guidelines for user needs analysis [37];  the framework for user requirements’ capture and analysis developed by the Telematics Engineering project RESPECT [36];  the provisions in the Technical annex of COMMAN projects in relation to tasks to be executed under work-package WP038. It should be also noted that, in order to select an appropriate user needs analysis methodology for our project, we had also considered using CONVERGE methodology [41] and RATIONALE ROSE Case tool, for developing COMMAN system architecture. Thus, relevant requirements of both Converge and Rationale Rose had to be taken into account. The COMMAN user needs methodology is based upon the design cycle presented in the user-centred design draft standard ISO 13407 (1997b) shown below (the relevance to the COMMAN planned activities is also shown): Relevant to WP03 activities (User requirements) Most Relevant to WP05 activities planning the human- (System architecture) centred process understand and specify the context of use specify the user and evaluate designs against organisational user requirements requirements produce design solutions meets requirements Most Relevant to WP04 activities (Functional specification) Figure 8 Key user-centred design activities (from ISO 13407, RESPECT) More specifically the process followed during WP03 aimed in defining the following: 8 The description included in the TA foresaw the following tasks under WP03: Development of User Survey methodology, Capture of basic user requirements, Survey of State of the art and shortcomings in maritime / mobile – satellite communications, Investigation of legal / pre-normative / Regulatory aspects, Execution of 1st User Forum, Consolidation of results – Conclusions – Production of the User survey report. TR4006/D3.1/MARAC/NP/220399/1.0 - 42 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report . • CONTEXT: Background information was gathered about the project, the applications to be supported by the system as well as the original ideas of the project partners concerning the system concept 9. A user and stakeholder analysis was then performed to identify the range of different users, stakeholders and their goals (why they will primarily use the system), and to identify user group characteristics which potentially impose requirements and constraints upon system design. There was also an examination of the environment in which the users are working. The process was primarily intended to help identify general system requirements, and led on to a more detailed examination of specific task and functional requirements during WP0410. • Specific Requirements: The next step was to identify the main tasks and critical processes/activities to be executed by the potential users of the system. Relevant current processes for communication were reviewed, problems and constraints were identified and ideas for overcoming the problems/constraints listed. Any relevant system, products & technologies on the market were considered, and functions or features they contain which could be included or excluded from the new system were identified and recorded11. A list summarising the sources investigated or consulted is provided in table 8 at the end of this introduction. It should also be noted that a core activity during this step was the organisation of COMMAN 1st User forum12. • Early DESIGN: Using the information gathered thus far, a list of design ideas and a refined system concept was produced. It will be used as a basis for the system design (during WP05)13. The sub-stages of the process 14, can be listed as follows (please refer to figure 9):- Summarise the COMMAN project and original concept Reports details on the initial project design context based on COMMAN partners views and the content of the proposal submitted to the EU (c.f. Section 1.1 of this report). Identify users and stakeholders Here the future users and stakeholders of the system are identified, grouped and sub-grouped and their roles in relation to the system are recorded. The main goals of the various user groups are also collated. Describe user characteristics User characteristics such as skills, physical attributes and personal/group-subgroup details are recorded, and any associated requirements are listed. Describe technical environment An initial effort was made to identify the technical characteristics of the COMMAN system modules and record existing technical constraints as well as possible future requirements. Describe physical environment The characteristics of the physical environment (e.g. sound and thermal and environmental conditions in general) and possible relevant future requirements were recorded. 9 Relevant data presented in section 1.1, previously 10 The work-package producing the functional specification for COMMAN system 11 A summary of the extensive survey conducted by the project on communication technologies provided in 1.2, previously. More detailed information can be found in [39]. The requirements extracted by reviewing the state of the art are listed throughout the following sections 12 A summary is included in appendix A4 of this deliverable, more details are included in [43]. 13 The work-package in COMMAN developing system architecture 14 This used a series of forms and prompt sheets (‘1.1’, ‘1.2’,… ‘1.12’). It is based on the RESPECT recommendations amended to meet the specific needs of COMMAN. It provided a comprehensive checklist and tool for planning, and was supported by other aids and suggestions (See reference [36] for full details). TR4006/D3.1/MARAC/NP/220399/1.0 - 43 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report WP03 Start Define Methodological Approach Summarise the COMMAN project and original concept Identify users and stakeholders Describe user characteristics Context Describe technical environment Describe physical environment Review similar systems and products Describe social and organisational environment Identify relevant standards and current Identify user tasks relevant to goals & current regulatory/ technical constraints critical processes (Review tasks & processes) 1st User Forum Specific Requirements Yes Preliminary organisational approach Perform expert review of system concept Early Design D3.1 Deliverable Draft Peer Review Yes D3.1 Deliverable Final Figure 9 WP03- User requirements capture & analysis methodology TR4006/D3.1/MARAC/NP/220399/1.0 - 44 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report Describe social and organisational environment The characteristics of the social environment (e.g. organisational aims, staff and management structure, performance monitoring, legal normative parameters and constraints, etc.) and possible future requirements were recorded. Identify user tasks relevant to goals & review current critical processes Communication tasks performed by the users, relevant to their main performance aims, were identified and a first analysis, to capture key requirements relevant to task execution, was made. The most critical activities to be performed with the aid of the new system were identified and analysed. One of the main tools used to capture requirements relevant to user tasks was a series of round table discussions organised during the 1st COMMAN user forum. Review similar systems and products Features of existing or forthcoming systems/technologies which could be incorporated into the system were examined. Applications which may need to be supported at a later date, thus imposing further requirements were also considered. Existing and potential requirements were listed accordingly. Nice-to-have functions and features were also listed (in order to be reviewed – at later stages, to decide if they are to be included or excluded from system design) Identify relevant standards and current regulatory/ technical constraints A comprehensive list of standards relevant to COMMAN design have been produced to be used as reference for the project design team in order to facilitate decisions, if necessary after consultation with user group representatives, on their possible adoption/implementation. Technical constraints have also been identified and recorded. Preliminary organisational approach Based on available data on information flows data from interviews, the user forum reviewed applications as well as architectural requirements extracted from projects (such as DISC/PISCES) or standard recommendations (PISCES, ASTM standard produced by ISIT project, etc.). The objective of this activity was to clarify the organisational basis for the system. The aim was to acquiré full understanding of how the users will interact with the system and communicate with other people as part of the work process or their operating environment. A further aim was to analyse on a preliminary level how information will flow through the system15. In the context of this stage a mock–up of system interface was also produced to be used to help users visualise the possible system and to clarify further user requirements (or capture additional requirements) in a series of “walk-through” exercises and interviews planned under WP04 activities16 Perform expert review of system concept. At this final stage of the WP03 activities, based on the information gathered so far, the original ideas on system concept were reviewed by experts within the project team17. Based on the results of the review the original ideas on system design have been refined and formalised in a way that reflects the expectations expressed by the users. An assessment was also made to estabish whether the design ideas and concepts form a sufficiently good basis for the development of a prototype. A revised system concept (presented in chapter 4) was developed. A final draft of this deliverable was produced from the above process. It was the subject of an extensive review process, by the consortium, those who attended the User Forum and a formal peer review. The final deliverable (i.e. this report) reflects the comments received during that process. 15 This preliminary organisational approach will be the subject of a more detailed analysis during WP04 and the basis of development of the high level architecture during WP05 16 Please refer to appendix A3, where a description of the user interface mock-up is included 17 The review meeting took place at Trondheim / Norway on 15/1/1999 TR4006/D3.1/MARAC/NP/220399/1.0 - 45 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report The remainder of this chapter is a summary of information gathered from all sub-stages mentioned above, except for the results on identified standards which are included as Appendix A2 and the user interface mock-up description included in A3. The refined COMMAN system concept is then discussed in the final chapter. It should be noted that each section summarises requirements, and most finish with a brief note about any relevant constraints related to these requirements. Some user requirements were reported under more than one heading. Repetition has been avoided wherever possible, although it has sometimes proved necessary to ensure adequate future reference. The format of the remainder of this chapter involves a series of listings, together with figures to illustrate information flows. TR4006/D3.1/MARAC/NP/220399/1.0 - 46 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report Table 8 Sources consulted18 Sources relevant to 3rd ITU, generation system UMTS forum, development 3GIG of GSM MoU organisation Satellite systems/ Satellite Little LEO: E-Sat, FAISAT, Leo One, Orbocomm, System proposals VitaSat Narrow-band LEO & MEO: ECCO, Ellipso,Globalstar, ICO, Iridium Narrowband GEO: ACES, ACTEL, Africom, AMSC, APMT, ASC, EAST, Inmarsat 3, Movisat, Msat, Optus, SatPhone, Thuraya Broadband GEO: Astrolink, Cyberstar, Horizons, GE Star, Ka Star, M2 A, Millennium, Spaceway Broadband LEO: M-Star, SkyBridge, Teledesic, West Projects TOMAS, MOEBIUS, EIES, ISIT, IDES, SHIDESS, DISC & DISCII, VTMIS-NET, ECHO, SAFECO I or II, MERMAID, NIVEMES, ArchiPELAGO, GEONET, PISCES, POSEIDON, ATOMOS Service providers BT, RYDEX Mobile Technologies & GSM, DECT, TETRA relevant systems Maritime Communication STN ATLAS, ECI, DASA, GP&C, NERA, SAIT-RADIO HOLLAND, manufacturers THRANE & THRANE Maritime Communication Fleetlink (MMS), MARSTAR (Nevterk), ISM /SPEX (ISM), ASTRA Applications mail (SAIT), ISM Solutions Integrated Navigation Kelvin Hughes, Litton, Sperry Bridges/ ECDIS manufacturers End-users & Domain User Forum Attendees – see appendix A4 and [43] for more details. Experts Interviews with:  Mr. Ehrke, STN Atlas  Mr. Vollert, German association of ship’s captains and officers  Mr. Schmidt, radio instructor, ISSUS  Brittany Ferries  SNCM  CMA  Port Autonome du Havre  CESMA  Dolphin Hellas S.A Wireless Midlle-ware Rational Rose, Popkin System Architect, MS NetMeeting, TCP Over providers, Development Satellite IETF, TCP Performance Enhancing Proxies IETF, P_Mul Tools, Video-conferencing Internet Draft, End-to-End QoS combining RSVP/Intserv and tools, Sources for wireless Differentiated Services IETF, PPP Multilink Protocol RFC 1990, Long standards Thin Networks IETF Cordless technologies MESMR, E-DSRR proposals 18 Besides interviews/ personal contact and the User forum consultation of the sources mentioned above access was made via published documents or WWW search. TR4006/D3.1/MARAC/NP/220399/1.0 - 47 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 3.2. COMMAN Users and Stakeholders & System Non-functional requirements 3.2.1. User Classification & Main goals This section summarises, in table format the results of COMMAN stake-holder analysis in terms of user group classification. Main goals for system use (for each individual group) are also listed. Table 9 COMMAN users, stake-holders & affected users Index Main task goals number ONBA On board users of the HMI ONBA-1 COMMAN system System configuration maintenance officer Trouble shooting ONBA-2 Other ONBB On board users of connected applications ONBB-1 Operations Staff ONBB-1.1 Captain Standard reporting according to ISM-code Update of ECDIS-charts Controlling/ Monitoring external communications traffic Dialogue with company ashore Routine email ONBB-1.2 Operations Officers Recept of current environmental data (weather, tidal information) Loading calculations ONBB-1.3 Crew members Voice Communication ONBB-1.4 other ONBB-2 Ship’s Husbandry Staff ONBB-2.1 Ship engineers Remote inspection Fault diagnosis Maintenance ONBB-2.2 Administration officer Review of communication costs Routine company email ONBB-2.3 Other ONBB-3 Medical Staff ONBB-3.1 Medical officer Audio-visual contact with distant medical experts for remote guidance on patient examination or treatment ONBC On board secondary users of the HMI ONBC-1 Visiting technicians Remote inspection Fault diagnosis Maintenance ONBC-2 Visiting communications Remote inspection engineers Fault diagnosis Maintenance ONBC-3 Inspectors Remote inspection Status information ONBC-4 Other TR4006/D3.1/MARAC/NP/220399/1.0 - 48 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report Index Main task goals number ONBD On board secondary users of applications ONBD-1 Visiting technicians Maintenance and installation of updates of applications ONBD-2 Pilots Receive current environment data ONBD-3 Passengers Access to passenger-travel information Video conferencing ONBD-4 On board trainee Distant learning and discussions with tutors ONBD-5 Other ASU Ashore stakeholders Main task goals ASUA-1 Primary Users ASUA-1.1 Shipping Company Transmission of voyage schedules Transmission of cargo data General company administrative E-mail Remote login to ship subsystem for maintenance/ monitoring purposes ASUA-1.2 Ferry Company Transmission of voyage schedules Transmission of cargo data Remote login to ship subsystem for maintenance/ monitoring purposes ASUA-1.3 Naval Shipping Transmission of voyage schedules Transmission of cargo data Remote login to ship subsystem for maintenance/ monitoring purposes ASUA-1.4 Leisure Craft Transmission of voyage schedules Transmission of cargo data Remote login to ship subsystem for maintenance/ monitoring purposes ASUA-1.5 Director of the list of View of the company expenditure on bearer access interviewees ASUA-1.6 Shipping line operations View of the company expenditure on bearer access manager ASUA-1.7 Mariner families Voice and fax communication and Internet email ASUA-1.8 Other ASUA-2 Manufacturers ASUA-2.1 COMMAN system Remote maintenance, updating, failure diagnosis support engineer ASUA-2.2 Communications Interfacing/ integrating communication terminal equipment into the ship’s single equipment provider data node ASUA-2.3 Applications Smooth and reliable operation/ performance, through the single data node, of the manufacturer communication relevant tasks of their individual applications ASUA-2.4 Service provider Transmission of updates Transmission of drivers ASUA-2.6 Other ASUA-2.7 ISC/ IBS equipment Access & Remote login primarily for maintenance purposes manufacturers ASUA-3 Safety Staff ASUA-3.1 Coast guard Communication with the ship staff ASUA-3.2 Search and rescue Communication with the ship staff services ASUA-3.3 Other ASUA-4 Traffic control and monitoring ASUA-4.1 VTS-operator Control and monitoring of traffic ASUA-4.2 Pilot services Co-ordination of pilots Remote pilotage ASUA-4.3 Other ASUA-5 Medical staff ASUA-5.1 Medical service Medical Tele-consulting Voice communication ASUA-5.2 Other TR4006/D3.1/MARAC/NP/220399/1.0 - 49 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report Index Main task goals number ASUB-1 Port Services ASUB-1.1 Port authorities Voice and fax communication ASUB-1.2 Tug companies Co-ordination of tugs ASUB-1.3 Customs Exchange of cargo data ASUB-1.4 Lock Operator Voice and fax communication ASUB-1.5 Bridge operator Voice and fax communication ASUB-1.6 Towing companies Voice communication ASUB-1.7 Chandlers Voice communication ASUB-1.8 Other ASUB-2 Information providers ASUB-2.1 Hydrographic office Transmission of tidal information Transmission of ECDIS-updates ASUB-2.2 Meteorological service Transmission of meteorological data ASUB-2.3 Other ASUB-3 Regulatory Bodies ASUB-3.1 Standardisation bodies Definition of requirements ASUB-3.2 Classification societies Definition of requirements Consulting/ Transmission of ship data, drawings ASUB-3.3 Licensing authority for Definition of requirements communication staff ASUB-3.4 Other ASUB-4 Instructors ASUB-4.1 Radio instructor Definition of requirements Distant training ASUB-5 Insurance staff ASUB-5.1 Insurance agency Remote login for inspection, monitoring ASUB-6 other TR4006/D3.1/MARAC/NP/220399/1.0 - 50 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 3.2.2. Non-functional requirements Non-functional requirements specify the performance and/or quality attributes of a workable system. Most of the non-functional requirements are already defined by the COMMAN technical annex (TA), ISO13407, DISC [41], PISCES [47, 48] and ATOMOS [44, 45, 46]. The requirements presented here are the key non-functional requirements identified during COMMAN literature survey19. Investigation of the user groups characteristics have also identified a number of requirements relevant to the language used in application interfaces, needs for training, cost, etc which are more logically recorded in subsequent sections as they were often repeated as responses to more specific prompts within the relevant sub-stages of the user requirements capture process. Requirements relevant to system design and system architecture:  System hard- and software storage media shall be reliable. The system design should be robust and capable of evolution. Problems with external communication are one of the main reasons for vessel accidents. By offering a more reliable and easy to access communication system, there should be fewer accidents.  Good ergonomics are essential because easy to use equipment results in fewer human failures.  A modular design will facilitate a variety of sub-systems to be integrated in the most appropriate manner for supporting a variety of applications. Further, it will enable the system to be adapted to a variety of environments and, to evolve in size and complexity.  The system shall support a future increase in communication needs and traffic (scalability)  The design should allow the verification that requirements are met in a physical realisation of the system  The system shall not interrupt any current safety procedures that use communication devices that are also integrated/ interfaced to the system  Finally, design should require less time consuming procedures for performing communication’s tasks. Requirements to the HMI:  Staff on board ships are often unfamiliar with computers, and so require a user friendly human machine interface (HMI).  The HMI should be designed according to relevant standards, e.g. ISO11064  The system should assist the user in navigating through the interface, thus making the system structure clear.  The system should keep user workload within acceptable limits.  The system should minimise the amount of information re-coding by the user  The system should minimise the difference in dialogue both within and across various user interfaces  Design should enable individual user tailoring of the HMI interface  Design of HMI should foster user acceptance  Design of HMI should reduce cognitive tunnel vision (i.e. focusing only on a single part of a problem, error, etc.). Requirements to applications:  System services (to support applications),where practical shall be available to a variety of applications using the system.  Information exchange from one application to another should be standardised to enable platform independent operation.  Applications should be distributable on several machines  Applications should be modularised  The structure of the application should support the function block concept. Maintenance requirements: 19 Some of the requirements reported are comprising “functional” and “non-.functional” elements. These are presented in subsequent-sections. TR4006/D3.1/MARAC/NP/220399/1.0 - 51 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report  (Modularity, Flexibility) It is desirable, subject to further investigation of the impact on system reliability, that system hardware designs will allow the easy diagnosis, location and exchange of a defective part, without a restart of the whole system.  The system design should allow for enhancement, extension or adaptation by the addition, upgrading or replacement of individual items of equipment. Other non- functional requirements:  Availability: The system shall be designed to provide graceful degradation.  Evaluability: The system shall support the evaluation of the effects of the working system upon its environment.  Security: The system shall provide system protection by the implementation of access controls.  Robustness: The system design shall enable implementation that will ensure continued operation within the specified environmental performance limits and environmental and infrastructure failures.  Flexibility: The system design shall not prohibit modification of components necessary to satisfy changing user requirements. The system design should not prohibit the use of information already in the system by the introduction of new functions or by the later introduction into the system of new function. TR4006/D3.1/MARAC/NP/220399/1.0 - 52 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 3.3. Technical environment & relevant requirements The final architecture and configuration of the system will be developed after considering and further evaluating the requirements identified from users and stakeholders which are presented in this report. However, the physical elements which will be incorporated into the system were already identified from the planning phase of the project. Based on these, apart from the additional modules which each individual application may require (databases, specific purpose server machines, etc.). The COMMAN single data node platform on board a vessel will comprise, at minimum, the following physical modules:  a provider of “services” (database, communications, etc), a “server” which will include units such as databases, routers, etc. and a module to enable switching between the available communication carriers and the various carriers’ terminals (satellite, radio, etc);  a configuration station (or a console directly connected to the server) for network management and system configuration20;  gateways/firewalls to the on-board Integrated Ship control network. Depending on the final design choices, additional software and/or hardware modules may required/included/installed or interfaced to the user workstations (“system clients”) which will be properly equipped (for running data only and/or multimedia applications and participating in data only and/or multimedia communication sessions. If it is required, the system elements ashore could include another computer platform (a “hub”) which will provide for instance management services to the shipping enterprise for whom it is installed 21. This is to be further investigated during the development of the system architecture. One of the aims of the requirements’ survey was to clarify end-users and stakeholders’ requirements in relation to technical environment for the COMMAN platforms. The paragraphs below summarise requirements captured, under the following headings:  general requirements, including core requirements relevant to system design, architecture, bearers, system characteristics, services, features and functionality;  user workstation requirements including those relevant to the software and hardware environment of the workstations;  COMMAN server requirements including those relevant to the software and hardware environment of the system’s server;  COMMAN configuration station requirements including those relevant to the software and hardware environment of the configuration station;  requirements for on board gateways including more specific requirements relevant to the software and hardware environment of the gateways to the ISC network. 20 It should be noted that ‘network management’ functionality of COMMAN excludes configuration and management of the ship’s internal Integrated ship control network. It shall be understood as accessing the ISC network services without changing or compromising the its structure 21 It should be noted that investigation, realisation and demonstration of functionality of a potential land based component for the system, is out of the scope of the current project context. A high level description of its functionality is included in [50]. Any specific requirements, in relation to it, will evolve from the architecture development in COMMAN WP05. TR4006/D3.1/MARAC/NP/220399/1.0 - 53 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 3.3.1. General requirements 3.3.1.1. Bearers and basic services  The system shall establish a multi-environment comprising multi-mode, multiband capability. Thus, it shall enable inclusion of any existing or emerging bearer service (satellite and or radio) which can be made available to maritime users22. The system shall also support the exchange of transponder/ AIS information and include or interface with a satellite navigation receiver.  Compatibility with land-based fixed networks and the capability to access ISDN (for tele-medicine services, dissemination of ECDIS updates, etc.) shall be included.  The investigation on the emerging third generation systems revealed that the COMMAN should be capable of being connected to bearers (satellite and/or radio) which are able to support services up to 384 Kbits/s.  COMMAN shall be sufficiently flexible to enable any mix of bearers to be connected to the server. In relation to services to be provided by the system following requirements have been recorded:  The System should provide more ubiquitous and seamless coverage capabilities. Establishment of communications on optimal bearer for access types (voice, data, video, short messages, etc.) is required by the system users. To enable this, system shall provide the capability for:  Route diversification, least cost routing and carrier choice  Message log and cost allocation  A store of “standardised” messages (desirable)  System shall support real time voice and data as well as bidirectional multimedia communications at the best quality of service that can be supported by the available bearers  System shall also support storage and forward transmission of different media types (voice. data, video).  The system shall enable fast connection times and reliable connections to any worldwide e-mail, telex, telephone, fax or data subscriber.  It is highly desirable for COMMAN to provide services by allowing connection to more than one network in any given area.  COMMAN architecture shall allow the integration/interfacing of system(s) and standard applications (on the ship and/or on shore side) which will be used for: ♦ audio (only) conferencing, ♦ Dataconferencing, ♦ Videoconferencing, ♦ White-boarding, ♦ WWW access, internet/intranet access, ♦ E-mail, ♦ FTP (file transfer over Internet) for image transfer, ♦ FTP for data transfer, ♦ EDI, ♦ Fax, ♦ ship position identification & reporting. 22 There were some concerns mentioned concerning the effectiveness of including systems, such as TETRA or DECT, please refer to section 3.7.1 TR4006/D3.1/MARAC/NP/220399/1.0 - 54 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report  The flow of information during an emergency should be, as far as possible, in a standard format.  Transparency of the system is required. Depending on the user choice, in any situation, the linked bearer, time, ship identification etc. should be shown on any monitor.  The COMMAN user interface should be easily adaptable for use in other languages than English. COMMAN should allow the exchange of messages written in various languages. Finally, the system configuration should facilitate, if application enables/allows it, language independent communication23.  The system shall allow secure data exchange if the application requires it.  All the information, processed by the system, concerning navigation and administration should be available on the bridge.  The system server shall enable direct access to vessel and machine data. Where this is not provided by the shipping company, the access shall be organised in a way that the captain has to allow it (transparency).  The System server should allow the exchange of data relevant to automatic integration of the traffic situation, ice and tidal situation etc., with other appropriate media such as radar pictures or ECDIS pictures. At the moment this is done via fax, which is undesirable. Electronic transmission of such data is desirable.  The system server should allow the exchange of data relevant to SAFECO’s Collision Avoidance Advisory System (CAAS), which uses the Electronic Chart Display Information System (ECDIS)  The System server shall allow the downloading and automatic updating of data relevant to ECDIS. It should allow automatic updating of filtered ECDIS-charts if this is technically possible.  The System server should allow voice communication from the cabins not via satellite but automatically via the cheapest provider in that region.  For ship to ship communications, authentication of other vessel is required. A note relevant to GMDSS platform / COMMAN platform relationship  COMMAN server should have access to bearers that will be used by GMDSS. However users expressed the view that it is desirable to treat the “distress” and safety functionality to be provided in GMDSS, separately from other COMMAN functions. 3.3.1.2. Requirements specific to system design & architecture: Requirements listed below are primarily extracted from standardisation institutes documents, documents of organisations dealing with specification of third generation systems as well as projects such as DISC/ PISCES which are providing technical recommendations for on-board system integration & networking. They are also based on the user expectations recorded during the 1st User Forum:  COMMAN has no interest in the on-board applications but should know which applications exist in terms of their associated parameters, e.g. QoS, but not the purpose of the applications.  Existing standards should be taken into consideration. If possible, existing standards for protocols and bus systems should be used. It is highly desirable that design choices in COMMAN should comply with the standards and guidelines produced by PISCES and DISC projects. The relevance of IEC1209, as well as emerging standards of IEC test procedures, will have to be taken into consideration in the near future. Further COMMAN designers should consider the provisions included in ASTM standard & ISO draft standard 15849 on Standard Guide for Implementation of a fleet management system particularly in relation to the following:  fleet management system architecture,  shipboard information technology platform architecture & services,  APIs,  land based information platform.  COMMAN shall make optimum use of existing bearers. 23 This requirement is based on a discussion that suggested that formatted messages with a limited vocabulary could be automatically translated to a standard form for exchange and then presented to the recipient(s) in their own language TR4006/D3.1/MARAC/NP/220399/1.0 - 55 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report  COMMAN shall be able to support multimedia exchanges and be flexible and responsive to dynamic change.  COMMAN should promote interoperability through use of common standards.  COMMAN should offer high capacity, good availability and reconfiguration capability.  COMMAN should be capable of operating in “receive only” conditions (for appropriate applications only).  COMMAN should employ effective & efficient information management techniques.  COMMAN should be capable of carrying operational & support information24.  COMMAN design should, where appropriate (e.g. not for E-mail), allow the user to select the data rate best suited to the specific application requirements, provided that the available communication bearers and the user rights permit it.  Software platforms should be based on an operating system with a layer of standard services for compliant applications.  The system shall provide diagnostics, feedback and error-detection capabilities.  The system architecture should be able to offer backup devices and duplication, if required, for the communication equipment.  The architecture should be open to allow ability to handle today’s system as well as tomorrow’s.  The architecture should allow the use of new approaches for the implementation.  The number of different information transfer mechanisms (protocols, etc.) needed to fulfil the requirements should be minimised. The use of a single protocol should be investigated.  Proper wireless protocols and techniques should be adopted in order that delay/latency is kept at a minimum.  Ship-shore and shore-ship communications must always be available. There should be automatic recovery following a power failure.  It is highly desirable that the system should support the capability to improve the residual error rate of bearers to an acceptable level (e.g. of the order of 1:10^-6 for data).  COMMAN shall enable the use of radio bearer services that can support high speed data applications.  It should be further investigated whether COMMAN should be interfaced to the ship’s PABX25.  The architecture should facilitate exchange of data between applications regardless of location and also with regard to ship and shore.  The architecture should not inhibit the exchange of data between different manufacturers equipment implementing the same function (modularity and interoperability).  The architecture shall allow the specification of requirements for the exchange of information in the system (e.g. quality of service restrictions to enhance cost-effectiveness of the system).  Architecture should allow flexibility in implementation, e.g. different technical trade-offs can be made in different instantiations of systems. Different architectures and different communication protocols should be usable.  Ideally, the system should make use of available cabling infrastructure on board vessels. Installation of extra and expensive cabling should be avoided. Applicability  The network architecture, for COMMAN, shall be (part of) a single IT infrastructure for the whole ship. In particular, it shall be possible to allow transfer data from safety related systems to non-safety related systems. The types of data that should be considered include: control data (small messages), state information (lower real-time requirements), radar, ECDIS and ECS (vector and raster chart data), HMI, video and audio, configuration, documentation, telephone. Entertainment (TV).  There shall be paths for communication between the ship and various information users on land or other ships. Some examples are: On-line diagnosis from shore to pinpoint problems in the control system, transfer of, e.g. EDI or ECDIS updates, transfer of reports from ship to land or other ships, transfer of loading plans, cargo information, etc., transfer of video from the ship, e.g. to visualise problem areas for remote experts.  The system architecture and the technology used to implement it should minimise the requirements for maintenance and down-time. It shall have in principle continuous availability during operation. 24 Users expressed contradicting views on this point 25 Users expressed contradicting views on this point.. However, it should be noted that this is an implied requirement imposed above by the use of phones in cabins. TR4006/D3.1/MARAC/NP/220399/1.0 - 56 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report  It shall be possible to specify the interface of a module to the rest of the system in such a way that other manufacturers can make a mock-up interface and test their modules against it. Connecting subsystems should be easy.  Module interface specifications should be standardised (companion standards). As the use of the open systems is accepted, some systems from different vendors with the same functionality are likely to be more or less identical. If these systems are to be completely interchangeable it is necessary that the systems use the same services, offer the same information and receive the same kind of instructions.  When hardware belonging to inputs, outputs, communication links and user interface is configured to minimise the consequences of failure, the related software should be separated in different computer tasks to provide the same availability. Information types and availability  Interface specifications and information models shall use standard languages.  The network architecture shall, as far as possible, support integrity check of information before information is accepted.  The system shall maintain a consistent time reference, which should be the same as used by the on board ISC and administrative networks  The system shall have facilities for reporting when source of information is lost  The system configuration shall be identified and controlled throughout the life cycle.  When control is possible from several locations, only one shall be in control at a time  There should be a general database service for trending and storage of time series. There should also be a general service for retrieval of various static and semi-static ship information (e.g. drawings or voyage related data). Note: The detailed assessment of DISC/PISCES/MiTS forum recommendations revealed an additional set of generic requirements that may impact on the COMMAN system design. These are relevant to general information models, functional description of the system, additional services requirements and requirements for the application and verification layers of the system architecture. They are recorded in Appendix A5 of this document, for future reference (informative), study and consideration by the COMMAN design team. 3.3.2. COMMAN User Workstation 3.3.2.1. User Preference for Hardware  COMMAN client functionality enabling modules (software and hardware) are to be installed on user station hardware that should normally consist of a standard personal computer (desktop and/or portable26). The station should be equipped with standard keyboard, mouse, high-resolution colour monitor, hard disk, floppy disk, CD-ROM drive and adequate memory to support user applications. Where the stations are used for multimedia applications and multimedia communications they should also include a sound card, speakers and microphone as well as any other peripheral equipment required by the specific multimedia application(s). In relation to peripheral equipment the following requirements have been expressed:  possibility to connect a printer;  possibility to use head sets and microphone in noisy environments;  possibility to connect low cost scanners;  for workstations for tele-medicine applications, possibility to connect digital ECG recorders or other medical diagnostic instrument;  possibility to include video card in combination with low cost digital camera. 26 It should be noted in this respect, that users attending the 1st User Forum of COMMAN were interesting for the availability of information processed by the system on laptop and/ or palm-top type of personal computers. TR4006/D3.1/MARAC/NP/220399/1.0 - 57 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report In relation to networking the following requirements have been expressed:  possibility to connect to local area networks via a standardised interface;  possibility to connect to the COMMAN server via standardised interfaces;  possibility to connect, via the available communication bearers, to ISDN;  possibility to connect the station to existing digital, private branch exchanges installed on board ships.  There are cases when a workstation (in emergency situations, for instance) might be required in areas where a wired connection is not possible. The possibility of a wireless interface to the COMMAN server and/or the ship data bus should be investigated.  In case of “non-specific use” work-stations, it should be possible to use one workstation as display for more than one applications module. It should also be possible to use multiple workstations as back up for each other. An aim should be to reduce the total number of workstations on the bridge. 3.3.2.2. User preferences for Software environment  Most of the current applications require a Windows 95/98 or Windows NT operating system environment for the client machines. This is a constraint which COMMAN designers should respect. However, as industrial partners in the consortium noted, technology changes rapidly and the system architecture to be adopted by COMMAN should allow interoperability with other client operating environments. Other requirements in relation to the software environment are:  user interfaces need to have a common “feel” (similar to Microsoft’s).  Consistency: minimise the difference in dialogue both within and across various user interfaces.  Feedback: provide the user with feedback and error-correction capabilities.  Structure: assist the user in developing a conceptual representation of the structure of the system so that he can navigate through the interface.  Memory: Minimise the amount of information that the user must maintain in short term memory.  Individualisation: accommodate individual differences among users through automatic adaptation or user tailoring of the interface.  Compatibility: minimise the amount of information re-coding that will be necessary.  The COMMAN protocol stack should allow the use of standard, MAPI compliant, e-mail applications and standard internet browsers.  Workstation software should comprise user-friendly software modules for processing pictures and sending messages.  The user interface should comprise standard desktop videoconferencing tools (such as NetMeeting).  Applications may require the access to on-board or on-shore databases, therefore database search tools should be included. The survey revealed a series of technical constraints and nice-to-have features, which have also to be considered:  TCP/IP, UDP support is mandatory, as used from the majority of applications reviewed.  H.323 compatibility is required (mandatory) for videoconferencing sessions during tele-medicine or CSCW applications (H.324 compatibility is also desirable).  Support for Distributed Component Object Model (DCOM) is highly desirable.  Dynamic Link Library for accessing the COMMAN server is highly desirable.  Win32 Dynamic Link Library (DLL) component packaging is highly desirable.  Support of large TCP windows, PAWS and RTTM is highly desirable.  Support of enhanced video compression schemes is highly desirable.  RTP should be supported (highly desirable).  Mobile IP should be supported (highly desirable). TR4006/D3.1/MARAC/NP/220399/1.0 - 58 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report An informative note (for system designers): ISO draft standards on FMS include “informative” annexes describing possible hardware environment of user workstations to be incorporated on the shipboard integrated platform. 3.3.2.3. Reference materials required either to perform tasks with system or to learn about or operate system  All the user groups representatives interviewed expressed the view that applications should include on-line help facilities. 3.3.2.4. Other requirements in relation to user station  The communication call set-up procedures should, as appropriate, be application driven, and initialised via the available user interface for a given application. 3.3.3. COMMAN server The following requirements have been recorded in relation to the hardware and software environment of the COMMAN server. 3.3.3.1. User preferences for the Software & hardware environment in which system will run  The COMMAN server should include appropriate hardware (e.g. routers, communication services controller, etc) and software (e.g. NDIS drivers, etc) which :  will provide support for existing standard interfaces (such as RS232C, Ethernet, NMEA, USB) to interconnect standard hardware devices directly or via a standardised bus;  will allow application developers to make use of existing widely adopted protocols or emerging protocols (PISCES, etc);  will allow application developers to access the available communication channels and set-up, maintain and finalise calls directly from the application’s user interface;  will allow seamless access of available communication bearers.  An appropriate network operating system should be adopted. This should support services which should be transparent to the user. They should enable applications throughout the network to provide for multiple users access to programs, databases, and file/print services, and provide gateways to independent networks.  Besides an operating system as above, system services should include a security management system, data encryption for any type of security sensitive data exchanges and virus protection.  Introduction of Fault Tolerance in Hardware should be considered. The level of fault tolerance necessary should be determined as a function of the criticality of applications supported by the system  The COMMAN server should provide automatic connection to communication bearers where user rights permit. 3.3.3.2. Other technical (stake-holders) requirements relevant to server Technical constraints or “nice to have” features, revealed from the survey are:  both UNIX based or Windows (NT, 98 or their enhancements) based platforms need to be considered. It should be noted, however, that Win32 platforms (NT or 95) are widely adopted by application developers.  It is mandatory to support protocols such as TCP/IP and UDP.  It is highly desirable to support protocols such as, Ipv6, ISDN S0, MiTS.  It is mandatory to support MiTS/PISCES. TR4006/D3.1/MARAC/NP/220399/1.0 - 59 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report  The system implementation should support TCP/IP in preference to ISDN.  The protocols suggested by PISCES and the PISCES protocol suit should be supported.  The PISCES suggestions on companion standards should be considered as well.  Support of enhanced video compression schemes is highly desirable.  RTP should be supported (highly desirable).  The H.323 protocol stack [multimedia over Internet] should be supported (mandatory).  Mobile IP should be supported (highly desirable).  Services like telnet, rlogin should be incorporated.  Access to data shared between applications and held by the COMMAN server (eg. ship’s position) via an open interface is highly desirable. A common COMMAN data base should only be used, if there is no other common data base (like DISC II) on board.  Win32 Dynamic Link Library (DLL) component packaging is highly desirable.  Support for Distributed Component Object Model (DCOM) is highly desirable.  Open Data Base Connectivity (ODBC) interface should be considered (highly desirable).  The support for Wireless Application Protocol (WAP) is desirable, if necessary.  The support of appropriate MAC protocol at Data Link layer is highly desirable.  The support of Large TCP windows, PAWS and RTTM is highly desirable.  The support of Selective Acknowledgement (SACK) is highly desirable.  The support of Fast Retransmit and Fast Recovery is highly desirable.  The support of Slow Start and Congestion Avoidance is highly desirable. Requirements & constraints relevant to carriers to be interfaced/ incorporated into the system:  64 kb/s (via Inmarsat HSD) and 64 kb/s -128 kb/s data rates (via EDSRR) is highly desirable for access to terrestrial WWW services in ports. It should be also noted that support of 64 Kbps or higher (preferably 128 kbps or higher) is highly desirable for efficient support of tele-medicine applications.  For data services, 10-6 BER or better is required from the Radio Access systems incorporated in the system. For non-IP based mobile speech and video services, the maximum bit error ratio is usually specified at 10-3 .  Interfacing and/or integration of carriers supporting Short messages services should be considered. 3.3.4. COMMAN Configuration Workstation  The COMMAN server (or workstation, attached to server) shall include a billing/user authentication mechanism to enable allocation of charges of voice or data calls made on personal basis (or on vessel charterer’s behalf). As a result of the extensive review of standards and recommendations, relevant to COMMAN, the following additional requirements have been identified (extracted, primarily, from recommendations of DISC projects as well as of the ASTM FMS guide currently proposed to ISO as a basis for an FMS27 standard):  Consider inclusion of the following services in the network management system (in accordance with ISO 15849 draft standard Definitions): Process Management, Health Management, Performance Management, Logging Management, Alarm Management, Schedule Management, Time Management, Debug Management, Back-up Management, Test Management, Messaging Management, Replication Management.  Some of the desirable functions are listed below (DISC recommendations): Configuration version control, Monitoring of the actual configuration; sending of alarms on network failures, loss of clients etc., Query functions to access information about other clients, 27 FMS stands for Fleet Management System TR4006/D3.1/MARAC/NP/220399/1.0 - 60 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report Control functions to change configurations, Identification of clients., Debug functions and backtracking of information propagation, Access to an internal representation of the actual and the intended configuration, priority of requests, Monitoring and control of network load, i.e. identification of the number of clients, protection mechanisms (enable/disable access to the network for certain clients) (Security, Name look-up, Maintain and make available a list, on request, with the following information, Applications present in the system, All services presently available in the system, Attributes of present applications and services such as safety criticality, priority, originator etc., System/application status). As a minimum requirement the COMMAN Single data node should support an appropriate billing mechanism as well as a diagnostics, feedback and error-detection capability The following system-oriented applications should be available:  a system manager for resolving resource allocation conflicts (manpower, hardware);  a common database for storing data from different applications and providing them to other applications. In case of applications such as tele-medicine, database design should allow automatic or easy updating of information. 3.3.5. COMMAN on board gateways The following requirements have been identified in relation to gateway linking COMMAN ship-borne platform to ship’s ISC network (extracted, primarily, from recommendations of PISCES project).  User workstations will be connected to the ship’s internal networks, and access the COMMAN server through the PISCES/DISC gateway. The gateway should be one-way unless the computer is approved for two-way communication. Where appropriate, measures will be needed to ensure that data is only accessed by authorised users.  The system should enable, for data collection purposes, direct access to all control systems data (accessed via the gateway) with conversion to a standard protocol (such as MITS/ PISCES) and standard database storage.  The system shall allow the transfer of ECDIS updates.  The system shall allow transfer of reports on integrated ship control subsystems from ship to land or other ships.  The system shall support on-line diagnosis from shore to identify problems in the control system. It should be possible, considering implications for safety, to diagnose the system and to change system configuration, system software or other parameters in the system from off-ship position. This can facilitate remote upgrades, remote error correction and remote diagnosis.  It should be possible to automatically transfer data from safety related systems to non-safety related systems. In this respect safety, security and cost aspects must be considered.  With respect to the transfer of data from safety related systems to non-safety related systems the safety, security and cost aspects must be considered. 3.3.6. Considerations and constraints in relation to the context of this section The requirements identified in this section should be analysed with respect to the related system designing implications, taking into consideration the technical constraints imposed by existing COTS components. This should be subject to further analysis within WP04 and WP05. However, an early assessment by the COMMAN design team, of the requirements recorded previously, concluded: 1. where COMMAN interfaces to legacy or COTS systems, its functionality is constrained by that of the existing systems. 2. Where COMMAN communicates, or manages the communications, with shore based systems, its functionality is constrained by that of the shore system. TR4006/D3.1/MARAC/NP/220399/1.0 - 61 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 3. All communications are constrained by the bandwidth and features of the available bearers and of the shore side connectivity. 4. Any security features required by an application (eg. encryption) are that application’s responsibility. 5. COMMAN has no interest in, or knowledge of, the data whose transfer it manages. Any decisions made by COMMAN (e.g. Quality of Service) are based on the application only. 6. COMMAN has no interest in the on-board applications. It should know what applications exist in terms of their associated parameters, e.g. QoS, but not the purpose of the applications. 7. COMMAN has no internal mechanism for the automatic authentication of other vessels. 8. TCP connections require two-way communications; they cannot function in receive only. 9. The availability and reliability of COMMAN is driven by that of the selected hardware. Features such as fallback and clustering will only be provided if the hardware supports it. 10. The transfer of data between on-board applications is external to COMMAN except where COMMAN functions as the repository for data shared between applications. 11. Where functionality can be provided by the operating environment (eg. the hardware or operating system), existing COTS products or by bespoke development for COMMAN, it is preferable to exploit existing functionality. 12. The COMMAN design will be modelled with object-orientated techniques, using UML and the Rational Rose case tool. The software will be developed in C++ and Visual Basic. Its target environment is a Win32 platform. 13. Management of the COMMAN server will be provided by a client application at either the server machine or at a COMMAN workstation connected to the server by the LAN. Some functions of the client could be made available remotely on shore. 14. Safety critical systems should have separate communications facilities. It is not envisaged that COMMAN will provide a safety critical service (otherwise stringent software development techniques would have to be adopted). TR4006/D3.1/MARAC/NP/220399/1.0 - 62 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 3.4. Physical environment & relevant requirements In this section the key requirements relevant to the physical environment are summarised. It should be noted that specific attention was given to capture information on the parameters of the physical environment listed below, as it is felt that they may have an impact on system design choices, installation, operation or performance28:  thermal and atmospheric environment,  auditory environment,  vibration or instability,  visual environment,  space,  user posture,  location, place of installation,  health and safety hazards related to system use,  protective clothing and equipment,  potential standards or international/local regulations relevant to the above. 3.4.1. User Workstations 3.4.1.1. Location, place of installation Thermal and atmospheric environment System workstations are going to be used in quite different ways by users working in a variety of on-board indoor and/or outdoor environments. In most instances stations will be used “indoors” in an “office”-like environment. In such instances normal temperatures and the atmospheric humidity are applicable (+50 - +40 0C, 15-80 % relative humidity) and users expressed no special requirements. Nevertheless, as there are also some instances where a station could be used in an environment 29 where “extreme conditions” may apply, it is therefore desirable that the workstation can be ruggedised for use in a harsh environment. In these instances the following parameters should be considered:  temperature range: - 15 0C -+55 0C,  humidity: up to 95 % at 40 0C. 3.4.1.2. Auditory Environment  The auditory environment may vary from very quiet to very noisy, even in cases of usage by members of the same user group. Therefore the possibility of using a headset30 as well as a conferencing microphone should be foreseen 3.4.1.3. Vibration or instability  Ship vibration is a common pattern and it is suggested that use is made of suitably ruggedised versions of personal computers (This type of station is available on the market, at an extra cost. The computer hardware is placed in enclosures which are equipped with a special anti-shock base ) taking into account the following parameters: 2-16Hz/ 1mm; 16-100Hz/1G 28 It should be noted that requirements recorded in this section will be considered for the design process only, as – due to budget restrictions – the COMMAN demonstrator may use lower standard equipment. 29 for example  a medical examination of an injured person which could take place in the engine room or one of the decks of the ship an inspection of a technical problem by a distant expert which could take place in a hostile environment 30 In case of operations in outdoor environments under strong wind, headphones may be also necessary. TR4006/D3.1/MARAC/NP/220399/1.0 - 63 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report  Power supply instability/interruption and/or voltage/frequency fluctuations are a problem on board ships. Hence it is suggested that uninterrupterable power supply devices, as well as power stabilisers, should be considered on a case by case basis. 3.4.1.4. Visual Environment  No requirement was expressed by end-users in this respect. However system designers indicated that monitors to be used should comply with the ISO DIS 9241-7 recommendations (Display requirements with reflections). Further visual factors resulting from the use of portable stations in different environments (for instance in the engine room or the deck of a ship) should be taken into account. 3.4.1.5. Space  No specific requirement was recorded in relation to space 3.4.1.6. User posture  No specific requirement was recorded in relation to user posture except the fact that there are Health and Safety specifications available that should be cited. 3.4.1.7. Health and Safety hazards related to system use  Connecting leads are a source of potential hazard. Measures should be taken in order that such hazards can be minimised. Protection from high (lethal) voltages is also required. 3.4.1.8. Protective clothing and equipment  The need to use protective clothing may arise, for example, in medical examination rooms, for inspection and maintenance on board ship, or on rural construction sites. This clothing could hamper the use of the system, and use of headsets, microphone and more advanced speech recognition tools could be a beneficial feature (which should be considered if available on the market) but this has to be analysed and decided on a case by case basis. 3.4.1.9. Potential Standards or international/ local regulations relevant to the above  System workstations should comply with the relevant standards of ISO on ergonomics.  Equipment must be considered as exposed to high levels of radiated and conducted EMI, therefore requirements mentioned in relevant IEC standards (IEC945 and IEC533) should apply. TR4006/D3.1/MARAC/NP/220399/1.0 - 64 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 3.4.2. COMMAN server, configuration station & gateways The COMMAN server will consist, physically, of a series of discrete pieces of equipment (routers, communication controller unit, and – possibly31 - various communication terminal equipment with their associated antenna units, etc) some of which would be installed in an indoor or outdoor environment while some others would always be installed outdoors. The following section summarises the related requirements. 3.4.2.1. Usually “Indoor” Units 3.4.2.1.1. Location, place of installation  On the ship’s bridge or in the radio room 3.4.2.1.2. Thermal and atmospheric environment  Qualification against IEC945 environmental specification is required. As a general rule standard "office" environment conditions will apply (0 - +35 0C, 45 - 85 % relative humidity) However, as some of the indoor units could also be installed "outdoors" ships, it is suggested that the following extreme conditions are considered: ♦ temperature: -40 0C-+55 0C, ♦ humidity: up to 95 % at 400C, ♦ wind speed: up to 100 knots, ♦ precipitation: up to 100 mm/hour. 3.4.2.1.3. Auditory Environment There are no user requirements recorded in relation to auditory environment 3.4.2.1.4. Vibration or instability  It is suggested that designers consider the following parameters: 2-16 Hz/1 mm;10-100 Hz/1 G, or in the case of equipment which will be used outdoors 2-10 Hz/2,54 mm; 10-100 Hz/1G.  To deal with power supply instability/interruption and/or voltage/frequency fluctuations it is suggested that use is made of a robust power supply, comprising battery back-up and voltage stabiliser. 3.4.2.1.5. Visual Environment  Monitors to be used should comply with the ISO DIS 9241-7 recommendations (display requirements with reflections). 3.4.2.1.6. Space  In the case of ships, communication equipment is usually placed on racks. Therefore it is suggested that consideration is given to designing a rack mounted (19’’) version. 31 At this very early stage of the project, there no final decisions made relevant to COMMAN system architecture. Communication terminals, subject to a further study and investigation during WP05, could be considered as an integral part of the COMMAN system or its “boundary”. It is to be noted that specification recorded in this section, as far as outdoor parts of the system are concerned are relevant to parts of communication terminals installed outdoors and/ or interfacing modules, installed – potentially – outdoors, between the COMMAN switching unit and the communication terminals TR4006/D3.1/MARAC/NP/220399/1.0 - 65 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 3.4.2.1.7. User posture No specific requirement was recorded in relation to user posture except the fact that there are Health and Safety specifications available that should be cited 3.4.2.1.8. Health and Safety hazards related to system use  Measures should be taken to minimise hazards due to connection leads. Protection from high (lethal) voltages is also required. 3.4.2.1.9. Potential Standards or international/ local regulations relevant to the above  Equipment should comply with the applicable local regulations, European regulations and IEC recommendations on electromagnetic interference and compatibility. In this respect EN55022 and EC801 need to be considered, as well as IEC 945 (EMC requirements on board ships). 3.4.2.2. Outdoor equipment 3.4.2.2.1. Thermal and atmospheric environment The following parameters should be considered:  temperature: -40 0C-+55 0C,  humidity: up to 95 % at 40 0C,  wind speed: up to 100 knots,  precipitation, rain: up to 100 mm/hour in case of ships,  icing of antenna for normal operation: (In the case of ships only) up to 25 mm. 3.4.2.2.2. Auditory Environment  Not relevant 3.4.2.2.3. Vibration or instability  Qualification against IEC945 environmental specification is required: ♦ The following parameters should be considered: 2-10 Hz/2,54 mm; 10-100 Hz/1 G. ♦ As far power is concerned it is assumed that the power supply unit will be included in the (usually) indoor part of the terminal therefore requirements mentioned in server indoor part should apply. ♦ Effect of pitch, roll and yaw should be considered (usually do not exceed ±150, ±250, ±80 respectively, while ship turning rate will not exceed 120/sec). 3.4.2.2.4. Visual Environment  Not relevant 3.4.2.2.5. Space No specific requirements recorded 3.4.2.2.6. User posture  Not relevant TR4006/D3.1/MARAC/NP/220399/1.0 - 66 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 3.4.2.2.7. Health and Safety hazards related to system use  Measures should be taken to minimise hazards due to connection leads. TR4006/D3.1/MARAC/NP/220399/1.0 - 67 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 3.4.2.2.8. Potential Standards or international/ local regulations relevant to the above Equipment should comply with the applicable local regulations, European regulations and IEC recommendations on electromagnetic interference and compatibility. In this respect EN55022 and EC801 again need to be considered, as well as IEC 945 (EMC requirements onboard ships): 3.4.3. Constraints identified relevant to the content of this section The requirements identified in this chapter require a detailed analysis of the related system designing implications. Technical constraints imposed by existing COTS components to be integrated in the system should be considered (as the environmental performance of the COMMAN equipment will be determined by the characteristics of the supplied hardware). This is subject to further analysis within WP04 and WP05. TR4006/D3.1/MARAC/NP/220399/1.0 - 68 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 3.5. Social and Organisational Environment & Preliminary Organisational approach Emphasis was given, in our user survey, to capturing details relevant to the organisational basis of the system to be developed. The key objective was to understand in depth how the end-users would interact with the system, and communicate with other people as part of their normal work processes or in case of emergencies. This meant looking at their specific operating environments, as well as how information would flow through the system. The following factors have been examined:  staff, management structure and IT policy,  assistance available or required,  interruptions, stressful conditions,  current communications structure,  privacy,  safety and security,  legal issues,  tasks & processes. In order to understand the processes and draw conclusions on information flows, services and functions required, we undertook:  a series of interviews conducted with representatives from companies operating ferries, cargo ships, passenger vessels and cruisers as well as port authorities and VTMIS experts (please refer to table 8 in section 3.1 where a list of companies interviewed is provided);  an assessment of documents such as DISC final report [41] and FMS guide [50] which include information on expected information flows into the integrated shipborne platform (of which COMMAN will be an integral part);  to produce and disseminate a questionnaire (please refer to appendix A4 and [43] for details);  to conduct the user forum in order to discuss with user representatives and domain experts the information flows, communication tasks/processes and their requirements. Requirements relevant to the organisational attributes, which have been examined, are recorded in paragraphs 3.51- 3.5.6 below. DISC proposed information flow diagrams and typical on board information flows (from draft FMS guide), and a preliminary organisational approach for COMMAN are included in paragraph 3.5.7.1-3.5.7.3. Requirements relevant to communications tasks are covered in Section 3.6. A summary of the user forum conclusions is included in appendix A4 of this document. 3.5.1. Staff management structure and IT policy relevant requirements  The system developed in COMMAN should respect the internal hierarchy in a vessel. COMMAN designers should take into account the relations between all the staff on board and their roles. Access rights to system facilities should be controlled and determined in relation to users’ roles, functions and responsibilities. A typical organisational structure of the crew in a vessel is shown below: TR4006/D3.1/MARAC/NP/220399/1.0 - 69 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report Captain machine engineer 2nd Captain Purser 1st Lieutenant 1st Lieutenant 1st Lieutenant Quartermaster 2d engineer Restaurant-hotel 2nd security 2d engineer 2d engineer boatswain Manager manager Name of the team machine technician electricity technician Name of the team On board staff Name of the team Figure 10 Typical organisational structure on board a vessel  COMMAN designers should consider the fact that the ship’s captain is one of the main users of system. He is responsible for decisions relevant to ship’s safety and the day to day operation of the vessel. Therefore, if the user requirements - recorded in this document - reveal contradicting requirements, expressed by different on board user groups, the captain’s requirements should take first priority. Discussions with the users during the first user forum indicated that system cost effectiveness is a key issue. This was a unanimous view expressed by all the participants in the forum.  Therefore it is expected that COMMAN shall ensure selection of the most appropriate communication bearers from those available, optimise the use of expensive bearers (such as satellite bearers) and assist operators to make efficient use of the system. It is expected that the bearer selection, considering the nature of task to be performed (safety/non safety, critical, urgency/routine, etc) would keep the communication costs to a minimum.  The transmission of emergency messages of high priority shall not be constrained by the cost of the service provided by the system. TR4006/D3.1/MARAC/NP/220399/1.0 - 70 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report Participants in the forum indicated that most of the ship to shore or ship to ship information exchanges could be “pre-formatted” and information in most instances could be exchanged in data form. They also indicated that use of data communications and standardised messages may also facilitate communications in the multilingual environment of shipping. Hence, they expect that COMMAN should facilitate information exchange in data form, in all instances that data communications are possible and could be used effectively. Other requirements, identified during our user requirements survey (from interviews, literature survey), relevant to management and IT structure, are recorded below:  Lack of familiarisation with computers is a common characteristic of most of on-board users and hence a user-friendly design of the user interfaces is required.  It will not be possible to employ extra personnel for the COMMAN. Hence the system should be self explanatory, easy to learn and cause no extra workload to the on board personnel.  On board communication system should be available on 24-hours basis.  Operators expect that system implementation should assist them reduce the vessel’s operation cost. Further they expect that they will be able to use the system for remote operation and monitoring of on board processes from ashore offices or control centres.  In case of a chartered vessel, the connection between the vessel and the shipping company (or the charter company) is becoming closer. The vessels are “put on a short lead”. The company ashore wants to have access to the processes on board. Therefore COMMAN shall enable interconnection of the ship and shore based LANs.  Designers should consider including firewalls, as commercial interests are at stake. 3.5.2. Requirements relevant to assistance  The system should assist the operator in maintaining an accurate internal representation of the processes.  The system should provide an online comprehensive help facility.  It is expected that applications which use COMMAN platform should support diagnostic and fault detection procedures comprise embedded help, training and, if necessary, simulation facilities.  Training needs should be considered as an integral part of the development of any communication management system.  The capability to manage a problem with the system on board (e.g. a software crash) is important in the isolated environment of the ship. Therefore it would be highly desirable if on board personnel involved in emergencies (such as tele-medicine operations, for instance) would follow an appropriate training course.  The system server should make it easier to accomplish education on board.  The system should ideally minimise the types of hardware, thereby maximising commonality and minimising training time.  Any system must provide simple operation for the unskilled user. The new system should be, ideally, self-explanatory.  Whilst implementing the new system most of the users will require support in learning how to use it, as well as ongoing access to help facilities to solve problems which may arise. (The possibility of organising a help desk offering support during the course of the project should also be considered.) 3.5.3. Requirements relevant to interruptions and stressful conditions  It is expected that the COMMAN should reduce the workload of its operators and managers (or keep it within acceptable limits). In any case it should not increase the workload of officers on watch. The COMMAN system should automate as much functionality as possible without removing the ultimate control from the manager. TR4006/D3.1/MARAC/NP/220399/1.0 - 71 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 3.5.4. Requirements arising by examination of current communications structure  The new system must be specified so that communications possibilities offered are at least as effective as any current system used by the user groups, and some of the key constraints, imposed by the use of current systems, were raised. The system must provide a more efficient exchange of data between ships and with the shore In this respect COMMAN should provide for the use of cost effective alternatives to currently used satellite communications (via the available radio bearers connected to the system, subject to coverage constraints). .  When high bandwidth bearers are not available, it should be possible to use lower bandwidth bearers and less capable applications (e.g. audio instead of video conferencing). Further, as mentioned in the previous section, the emergency nature of some operations requires guaranteed availability of the communication services whenever and wherever needed as well as fast call set-up times. 3.5.5. Requirements relevant to safety, security and privacy  COMMAN should support selection and use of bearers and protocols a way that, if a given task requires it, provides a trusted connection. The secure services may include authentication and encryption of the data. It should be possible to protect (encrypt) sensitive (commercial or any other) information when passing it over public networks.  Levels of security should be application dependent (for instance, in case of medical applications privacy issues are important but not critical. In this case moderate security is sufficient).  The system server should help the users/applications authenticate each other.  The system should also include, as far as possible, “backup” communication facilities to allow users to communicate through an alternative bearer in case of failure of the principal one. Unauthorised access to essential and important systems from any position (inside or outside the ship) should not be possible.  If the ship is chartered, the ship owner may want to restrict the charter company’s access to information.  Activities such as alarm acknowledgement, change of system values etc., shall only be possible by authorised personnel e.g. by insertion of keys or key cards or by use of personnel codes.  It shall be possible to restrict which users can perform, and workstations can used for, system control.  Configurable user privileges and passwords shall be used to prevent unauthorised bearer access.  Measures should be included in the system that restricts responses to polling, to those received from authorised users. For commercial reasons, the long-range polling would probably need to be limited to company use but there could be wider access at close-range for an accurate ETA estimation.  The system should control access to the bearers.  It should be possible to inhibit incoming requests for information (e.g. position request) from unauthorised third parties.  It should be possible to prove the authenticity of information being used by the system. 3.5.6. Legal issues/standards No legal issue, relevant to the project or system scope, was reported during our survey. However, the organisation of the user forum provided an excellent opportunity to discuss a series of user concerns in relation to standardisation. It is evident that some users already have much of the technology the EU Projects are investigating, but unless there are common standards, the technology cannot be fully utilised and runs the very real danger of creating extra work rather than reducing it. Further, users stated that there is a problem with EU standards and worldwide standards. Projects such as COMMAN should feed TR4006/D3.1/MARAC/NP/220399/1.0 - 72 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report through requirements to the IMO, although there is no formal mechanism to do this. It was suggested that it was the role of the project sponsors to do this. From the users’ perspective, it can be very difficult to conform to the wide variety of different standards.  The COMMAN project should consider developing of a “common performance standard” for on board communication equipment. COMMAN system will be used in a variety of situations with quite varying requirements on quality of service, data rates and cost. COMMAN is establishing an integrated communication platform on board which will enable the use of more than one bearer, of similar functionality, for a given task. Users suggested that COMMAN should consider developing a common performance standard. This may include, for instance, a set of minimum performance criteria. 3.5.7. Information Flows & COMMAN preliminary organisational approach 3.5.7.1. DISC suggested information model In one of the initial stages of DISC project [41], a context model of the ship within the industrial/transport environment was developed (see Figure below), to serve as a tool for the determination of requirements for the ship. This is shown below for reference and further analysis during WP05 activities. It should be pointed out that the figure does not reflect the total information flow in the shipping industry, but only identifies those flows that directly influence the Integrated Ship Control System. Hence, a lot of relations are ignored. However it is felt that it is quite representative for the information flows ship-shore, shore-ship via the COMMAN system. In the current context, all the information is assumed to be represented by the arrows indicated. Figure 11 DISC Information flow Model - Source [41] TR4006/D3.1/MARAC/NP/220399/1.0 - 73 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report It should also be noted that wide development and parallel discussion of the ‘Information Flow Model’ within DISC resulted in a number of general requirements. These are directly relevant to COMMAN and are repeated below:  The system should exhibit maximum flexibility and modularity to support unknown future functions.  The system should support technologies needed to enhance the integration of ships into the transport chain.  The system should support a vast increase in communications needs as compared to present-day requirements. 3.5.7.2. Typical on board information flows (FMS guide) We show below, for reference and further analysis within WP05 activities, the typical data-flows expected for the Shipboard Information Technology Platform (SITP) (as defined in fleet management guide [50]). COMMAN can be viewed as an integral part of future SITPs, installed on board vessels. Voyage Cargo Safety Environmental Maintenance Ship’s Quality Communications Reporting Operations Management Protection & Repair Personnel Documents Management W ireless Communications Operations Tech Support Control System Bus VTS ECDIS Update Communications Bus Ballast Control Trim & Stab. Gyro/Autopilot DR Position Mach. Control Elect. Gen. Global Pos. Sys. Speed & Dist. Ship Shore Liquid Cargo Reefer Controls Radar/ARPA ECDIS Talker Data/Control Fire Control HVAC Controls Depth Finder Rate of Turn Talker/Listener Data/Voice Only Control, Monitoring & Alarm Bus Navigation Equipment Bus Figure 12 SITP Data flow (typical) 3.5.7.3. COMMAN preliminary organisational approach This sub-section describes the system as perceived after most of the work in WP03 is finalised, and before WP04 has started. The boundaries presented are the result of a consortium wide discussion on the refined system concept 32 carried out in a project’s internal workshop organised in Trondheim on 15/1/1999. System boundaries As a prerequisite for the design work, the user requirements set the framework. We defined the limits with respect to users, protocols and services. System users are:  TCP/IP based local area networks as DISC II, PISCES and other existing or new administrative networks, (DISC/PISCES will develop the prototype internal gateway/firewall that will be used to interconnect the COMMAN server to the ship’s real-time and operational control systems.), other 32 Which is included in the subsequent chapter (4) of this report TR4006/D3.1/MARAC/NP/220399/1.0 - 74 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report onboard connected system(s), system administrators, bearers, ashore hub33, telephone network (PABX),  user interfaces regarding connection management of external connections over COMMAN. (COMMAN will provide the interfaces to, and where possible control of the radio systems.) Protocols internal to the ship are:  the TCP/IP protocol suite, UDP (for interfacing legacy systems), ISDN BRI (S0 Interface). Protocols external to the ship are:  PPP (MP), SLIP, IP-MUL. Bearers through Legacy Interface Units are:  Inmarsat A/B/C, VHF, HF, GSM, UMTS, DECT , E-DSRR. Outside the system boundaries are:  workstations, GMDSS as mentioned previously in 4.1.6. Services are:  connections (giving COMMAN access by data only or multimedia applications), store and forward capability (a mail server may be needed inside COMMAN to enable this.). Outside the system boundaries are:  end user applications, on board networks, distress functionality (GMDSS), user interfaces (of the applications), data compression. Context diagram The discussions and presentations at the Trondheim workshop gave the picture of the system and its environment as illustrated below. T e le p h o n e L e g a c y s y s te m s PBX T e le p h o n e S a t e lit e B e a re rs C om m an Com m an/ P is c e s - D I S C b o u n d a ry B e a re rs A d m in is t r a t iv e n e t w o r k s R a d io t o w e r D I S C I I F ir e w a ll O n b o a rd c o n tro l n e tw o rk s M a n a g e m e n t c o n s o le Figure 13 COMMAN working environment and surroundings – preliminary approach 33 The development of the COMMAN system architecture will consider the need for an ashore peer level data hub TR4006/D3.1/MARAC/NP/220399/1.0 - 75 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report From this definition, it follows that – the end user applications and their user interfaces are outside the COMMAN system boundaries. Other projects like PISCES and DISC have catered to the needs of existing on-board systems. It seems that most on board applications can be interfaced through IP traffic, coming through the DISC firewall. As the concepts being developed by PISCES and DISC have yet to be proven, the COMMAN demonstration will have to consider the range of legacy systems that are currently available on board. WP06 will consider the feasibility of integrating voice into the COMMAN system; the system architecture should not prohibit this, or other later additions. TR4006/D3.1/MARAC/NP/220399/1.0 - 76 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 3.6. Key communication tasks & relevant requirements This section summarises requirements relevant to the basic tasks executed by the system, and/or its operators, which may involve communication sessions via COMMAN. The information has been drawn from the literature survey, interviews, and the responses made at the User Forum (reported in [43] and summarised at Appendix A4). The User Forum provided a useful insight into the needs of the users. It is clear that the different forms of shipping (e.g. ferries and cargo ships) have a range of different needs. A key difference is the level of support that is required when passengers are carried. The provision of pay phones to call off-ship and the need for tele-medicine are two significant requirements for passenger carrying vessels. To facilitate reading, sub-sections 3.6.1 – 3.6.4 include requirements relevant to the following groupings:  Passage,  shipping husbandry and operations,  miscellaneous on board requirements,  other requirements. The final sub-section 3.6.5 includes requirements captured which cannot be specifically assigned to a subject They are of a more generic nature as the issues they address may be applicable to a series of communication tasks that will be repeated within a variety of ship operations (for instance establishment of a communication session between ship and ship operator may take place under any of the subject areas listed above). 3.6.1. Passage 3.6.1.1. Pilotage, Docking  If the normal transfer area cannot be used due to bad weather the vessel needs guidance to a safe transfer area. Therefore COMMAN should support the corresponding services provided by VTS centres.  Shore based pilotage should be supported by COMMAN. It should only be provided if it is allowed by the harbourmaster or his representative and accepted by the master of the vessel.  Regular callers knowing the area need advice and updates of changing local conditions and traffic developments.  The transmission of docking and manoeuvring information for enhancing safety is required34.  The system needs to provide information from port authority to pilot or agent by the use of laptop/palmtop display at remote site. 3.6.1.2. Navigation The requirements presented relate to tasks such as Navigation, interrogation of targets for identification of unique characteristics, secure guidance, communication ship/ship and ship/shore for navigation purposes, track other/own vessel using GPS, authentication of other vessels, etc. are as follows: 34 The exchange of information between the vessel and coastal VTSs are specifically safety information: vessel ID, position, dangerous goods, level of tide and the speed of the wind in the port, etc. TR4006/D3.1/MARAC/NP/220399/1.0 - 77 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report  Traffic organisation services and support to navigational decisions provided by the VTS centres should be supported by the COMMAN system. These services are: ♦ instructing vessels regarding entrance to a fairway and permitted speed; ♦ providing information on traffic movements, situations, and density, including vessel intentions as reported, estimated time to, and geographical position to, closest point of approach (TCPA and GCPA), and identification of vessels that entail a rise in risk level; ♦ providing information on local conditions such as ferry traffic, construction work, and temporary regulations; ♦ providing information on various obstacles for vessel traffic such as fishing farms, fishing vessels, and concentration of leisure boats; ♦ assigning fairway, anchorage, waiting locations, etc.; ♦ route planning (vessel movements); ♦ services which provide position, speed and course of a given ship; ♦ services which provide alerts to deviation between positions derived from GPS/transponder and radar; ♦ services which provide position with reference to way points.  Real-time positional information from vessels can be achieved via transponder installed on board ships, integrated/interfaced to the COMMAN system.  Transponders can be also used as an additional system when an emergency message is sent.  Compatibility with helicopter operations should be improved. Transponders can be used to achieve this aim.  Provision of combined interrogator transponder information is required.  The system server should support the capability to update electronic maps.  The system should provide ship identification and characteristics labelled by MMSI number and ship name.  If vessel is equipped with appropriate RADAR or DSC transponder or AIS equipment, the system should provide the possibility to receive information from the nearest VTS information about targets known to the VTS but not necessarily to the ship.  The system should provide an ability to identify and validate information relating to specific vessels. This information could suitably be coupled to the information base on the ECDIS.  The system should include appropriate radio carriers to be able to receive the services provided by VTS, especially the SAR services.  Navigation operations using the system should only be available to authorised personnel.  The system on board a vessel must be able to sustain and manage a higher workload when approaching the port.  The system on board a ship must be able to communicate with and authenticate other ships. It is critical that one vessel actually communicates with the vessel it thinks it is communicating with.  It should always be possible to contact (or be contacted by) other vessels or traffic stations.  The system should include a satellite navigation receiver which must be kept working in order.  Communication sessions must not be interrupted, except for emergencies.  The system should offer noise-free radio communication so the traffic centre can understand what is being send (and vice versa).  The system must support bi-directional and real time communication.  There is a requirement for the communications system to print NAVTEX messages in English.  Transmission of navigation information is required for enhancing safety.  Transmission of docking and manoeuvring information is required for enhancing safety is required.  In an emergency situation the real-time transmission of e.g. man overboard data to the SAR organisation and VTS Centre may be very useful.  Transmission of weather reports is required by the vessel for enhancing voyage information.  Transmission of ECDIS information is required for communicating route information.  Transmission of navigation and manoeuvring information is required for enhancing safety and to enable the VTS to monitor movements.  Ships need to be provided with instant access to the latest weather and navigational information in graphical form. TR4006/D3.1/MARAC/NP/220399/1.0 - 78 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 3.6.1.3. Safety/Emergencies  In emergency situations high system availability and high reliability is essential.  Multimedia applications (video, transmission of digital pictures) should be enabled for emergency situations (fire, damage). 3.6.1.4. Reference data Requirements recorded below are relevant to tasks such as connection to HO office to obtain/download ECDIS related information, access to port value-added services relevant to passage, and data recording, e.g. customs related information for crew, passengers, goods, and on-board supplies, digital map of the port area with all facilities marked, weather reports and/or weather maps.  The system should allow access to port value-added services.  The system should allow port users to monitor vessel information from ashore. Transmission of Voyage Data Recorder information ship-port and accident investigation organisation is required for incident analysis purposes and port state control.  For contacting HO services and get ECDIS updates: ♦ The system should provide access to the Inmarsat B service. ♦ The system should provide dial-up networking. ♦ The system should provide access to ISDN. ♦ The system should provide access to GSM. 3.6.2. Shipping husbandry and operations 3.6.2.1. Engineering  The establishment of connection to different externals, via the application interface, is required.  Short set-up times are required.  Support of higher speed rates than 64 kbps is desirable.  The system should enable automatic access of technical support service to information on board.  The frame rate for video should be adequate.  Access to company’s intranet is required.  The system should provide engineering assessment data for port state control organisations to track any problems with a vessel. 3.6.2.2. Planning  The transmission of all kinds of data should be supported by COMMAN. For instance: ♦ the system should allow transmission of the plan to load dangerous and polluting goods at harbour; ♦ the system should allow transmission of weather reports shore-ship. This is useful for the vessel in enhancing voyage information; ♦ the system should allow transmission of route planning information shore-ship. This can assist the vessel in the acquisition of port data; ♦ the system should allow transmission of planning data ship-shore 35. This enables the port to view the vessel’s plan. 3.6.2.3. Operations 35 ETA message, Name of the ship, Nationality of the ship, Draught at the bows/stern, Indicative (OMI Id, Radio indicative), Captain signature, etc TR4006/D3.1/MARAC/NP/220399/1.0 - 79 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report  It should be possible to prioritise the use of, and to charge for, the use of communication resources.  The system must provide the ability to select a bearer even if one is not currently available. This is a store and forward type of facility.  The system needs to be able to differentiate between applications which require the use of voice and those requireing data communication.  It should be possible to hold low priority data awaiting transmission until a suitable low cost bearer becomes available; this should not preclude the transmission of high priority or safety critical information.  The system should provide selection, from those available, of the most appropriate bearer which, considering the nature of the task to be performed would keep the communication cost to a minimum.  The system should support queuing of low priority information (e.g. routine mail) until a low cost bearer is available.  Many of the ship to shore and ship to ship information exchanges could be pre-formatted and information in most instances could be exchanged in data form. This will assist in saving time and facilitate communication in a multi-lingual environment. (This assumes the data is available in a user selectable language).  The system should automate as much functionality as possible without removing the ultimate control from the manager. 3.6.2.4. Administration  The system should streamline the administration of routine tasks such as payroll and stores.  The system should provide call and cost tracking to pinpoint the source of all communications expenditure.  The system should allow optional confirmation of message receipt back to the sender.  The system should allow fax and telex messages to be converted into data, which can be transferred much more efficiently.  Data administration in the system should occur behind the scenes and not interfere with the users’ activities.  Data transfer logging should be undertaken automatically in the system for traceability purposes.  There is a requirement for the system to support offline and online PC support.  There should be PC support from ashore for ship users (e.g. monitoring LAN usage, checking resources etc). This can all be done without involving the crew, avoiding costly telephone calls and human error.  The system should allow for simultaneous sending and receiving of messages.  The system should allow for the shipping lines operational manager/management to closely/frequently follow up company expenditure. The system could be exploited to provide integration with the company intranet, where the vessel data repository is located.  The system should be able to support applications using a wide variety of standard formats for documents and should not constrain the ability of the user to adapt these or generate new ones. (Examples may include invoices, certificates of origin, movement certificates, transit documents, banking documents, statutory documents, CAP documents, dangerous goods notes, hazardous goods notes, hazardous materials documents, shippers letter of instruction, export cargo shipping instructions and many others.). 3.6.3. Other miscellaneous application areas 3.6.3.1. Personal communications & distant learning  Crew members should be given access to e-mail and fax facilities  Interface to the ship switch is desirable to enable direct access by the bearer service and routing to the crew cabin.  Clear charge collection mechanisms should be provided by the system to enable local billing which can distinguish between official and personal communications. TR4006/D3.1/MARAC/NP/220399/1.0 - 80 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report  It is desirable that the system should facilitate remote access to distant learning services for ship’s crew. 3.6.3.2. Tele-medicine services  Ship users should be provided with specially rescued access to marine medical advice in an emergency.  Tele-medicine systems might be needed in ships involved in transport of passengers e.g. cruise ships and ferries.  The system should make available to on-board physicians remote medical assistance, video facilities (for remote assistance and diagnosis - the requirement for video varies in importance with the type of vessel. Those with fare-paying passengers regard it as more important).  The COMMAN configuration should include a database management system (applications including tele-medicine require it).  User interfaces in the system should be easily adaptable to local languages.  The system should facilitate updating of on-board stored information.  For Video-conferencing with a medical centre a high speed data connection is required by the system.  An adequate frame rate is required for video-conference sessions.  The COMMAN design should facilitate easy or automatic updates of on-board data bases after a ship/ shore data exchange which requires it.  The system should be capable to set up calls to different correspondents based on user preferences  The system should be capable of setting up basic services (required to support applications) using different communication carriers.  The system should support automatic establishment, via the application interface, of connection to the desired correspondent.  Selection of carriers for the system should be made on the basis of speed, application requirements and cost.  The user station software should comprise a browser. 3.6.3.3. Passenger services  The system should facilitate installation of ‘phone booths on board passenger vessels. Only outgoing calls should be allowed in order to avoid the shipping company having to pay the ‘roaming’ charges associated with incoming calls.  A flexible billing system is required, supporting payphones using coins of various currencies, credit cards, pre-paid cards, etc.).  Booths should be operational outside radio coverage (i.e. within a satellite bearer coverage).  Secured on line transactions should be supported.  The system must allow the shipping company to verify the credit card transaction details of the passengers who pay by credit card. It should be made possible to transmit the manifest after the departure of the ship. (It can be sent via a wireless bearer up to 30 minutes after the departure; thus, time can be saved in the port).  Remote access to tourist information systems should be provided.  Passengers should be given access to e-mail and fax facilities.  An interface to the ship switch is required to enable direct access of the bearer service and routing to the passenger cabin. 3.6.4. Requirements of a generic nature  Backup communication via different systems must always be operationally maintained. The minimum is for this to be provided for phone/voice services.  The system shall allow transfer of video from the ship, e.g. to enable remote experts to visualise problem areas.  The system shall allow transfer of loading plans, cargo information, etc.  The system should give continuous access to medical and maritime assistance, navigational hazard warnings and ships’ position reporting. TR4006/D3.1/MARAC/NP/220399/1.0 - 81 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report  The System server could support data exchange between shore and ship of cargo data and enable electronically input to the cargo computer on board during the journey.  ISM application provider (IDES) requires the provision of Internet-style access from/to ship/shore.  The system should support still-picture transmission in real-time, or store and forward modes (for tele- medicine and or CSCW tasks).  The system may be used to centralise output for similar information (i.e. now different printers for VHF and satellite are used).  Transponder data from other ships may need to be automatically added to the radar picture. The system should enable automatic transmission of transponder data receive to the ship’s radar.  The user of the system should have the option of transferring information to execute the transfer immediately, at regular intervals (e.g. daily, weekly) or triggered by a specific event.  It would be useful to be able to request data files from ashore and to be able automatically to retrieve them.  There should be a communications focal point, which acts as the co-ordinator and manager of message traffic (to include planned maintenance, cargo data, crew information, weather, charts etc.).  There is a requirement for the automatic transfer of reference data for cargo handling, crew rosters and planned maintenance (in the form of files) between ship and shore.  Automation of data bulletin boards (e.g. weather, charts, news services etc), which are kept up to date and are accessible upon user request, is required.  Ship users want to be able to send e-mail with attachments (such as spreadsheets) to their on-shore office networks.  The system should allow the user to exchange messages using different types of e-mail including MS Mail, CC:Mail, DOS MHS.  The system should allow the user to have multiple addresses to avoid having to re-send the same message to several destinations sequentially.  The system should have a remotely manageable address book, permitting concentration of user knowledge on shore, making periodic changes transparent to the on-board user.  Messages sent to the ship from ashore should be stored in a mailbox for convenient retrieval.  The system should provide users with a range of message receipt notification options.  The ship based user requires to call the system into service to send messages and retrieve waiting messages within a single communication.  The communications system should be compatible with industry standard e-mail software in the shipping companies’ head offices.  The system server could automatically provide the identification number of the appropriate coast station. 3.6.5. Identified technical Constraints relevant to requirements presented in this section 1. COMMAN provides communications management and will provide centralised database functions (f.e. store and forward functionality) for data shared between applications. It does not have any knowledge of what the data is. 2. COMMAN selects the bearer based on the application requiring the connection. It cannot select the bearer, or features of the bearer, based on the actual data. 3. Acknowledgement of the receipt of transmitted information is an application-layer function; it is outside the scope of COMMAN. The use of reliable protocols (e.g. TCP) will however ensure that the packets will be received at the other end of the connection. 4. COMMAN can schedule when information supplied to it is transmitted on a given bearer (hence store and forward). However, COMMAN has no control over when applications supply data for transmission. 5. E-mail functions (e.g. address lists) will be provided by the email application not COMMAN. Remote management of the email service, if necessary, is outside the scope of COMMAN. TR4006/D3.1/MARAC/NP/220399/1.0 - 82 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 3.7. Other Design Ideas and Concepts The requirements summarised in this section are extracted from review of relevant systems, concepts, technologies or projects that have been reviewed during the course of WP03 activities. It should be noted that we tried to include only ideas that have not been included in previous parts of this document. However duplication, in certain instances is unavoidable, for the sake of completeness. Requirements presented are classified according to their input “source” (system, system category, technology or project). 3.7.1. Requirements resulted from review of terrestrial mobile systems/ system proposals  (GSM): System design should foresee the future incorporation/integration into the multimode terminal of at least one GSM communication channel in order for users to benefit from GSM competitive offerings (versus satellite) in all the areas where GSM could be directly available.  (EIES, ArchiPELAGO) As there are geographical areas where GSM or its future enhancements (GPRC, UMTS) will not be directly available, the project should investigate whether emerging technologies, such as E-DSRR and MESMR, could be integrated in the multimode communication system’s design to provide lower cost access mechanisms to the core GSM/UMTS/ ISDN services for high speed (nx64kbps) or narrowband applications respectively.  (DECT): It should be very carefully considered if there is added value to include a DECT mode in COMMAN communication platform.  (TETRA) as TETRA technology is also focusing at the need of a very closed group of users in which the majority of maritime users is not included, it should be also very carefully considered the usefulness to include a TETRA mode in COMMAN. However it should be further investigated if proper integration mechanisms on shore, should be established to enable connection of maritime users on board COMMAN vessels (using any of the available communication services) with users using TETRA handsets. 3.7.2. Requirements relevant to review of IMT2000, UMTS  (3G services requirement): COMMAN should support voice and non voice services (telephony, digital data services as well as audio and visual communications).  (Recommendations ITU-R M.687 and 816): ♦ compatibility with land-based fixed networks should be secured; ♦ the system should provide services by allowing connection to more than one network in any given area; ♦ services should be made available even if the density of users in an area is low; ♦ services should be offered to users at acceptable costs; ♦ the COMMAN server should be based on an open architecture which will allow future expansion and adaptation; ♦ the COMMAN structure should be modular in order for the system to be adapted properly in a variety of environments and grow as necessary in terms of both size and complexity.  (IMT2000 requirement on Coverage & Cost): the system should support more ubiquitous and seamless coverage capabilities, and allow operators to offer services at a competitive price. TR4006/D3.1/MARAC/NP/220399/1.0 - 83 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report  (IMT2000 - Transmission & Delay requirements): ♦ for mobile speech and video services, the maximum bit error ratio is to be specified at a BER of 1:10-3; ♦ for data services, a maximum BER of 1:10-6 is required from the Radio Access systems incorporated in COMMAN; ♦ proper wireless protocols and techniques should be adopted in COMMAN in order for delay to be kept to a minimum.  (3G mobile systems architecture): future (third generation (3G) Systems) are expected to provide a much greater array of services than voice, with seamless access procedures and man machine interfaces. By default they will be “multiband”, “multimode”, multivendor” and multi-operator/service provider oriented. Thus, in order to maximise cost effectiveness, for the benefit of the users, effort should be made, by application providers, to offer “platform” and “technology” independent solutions. This implies that developments should be based, as much as possible, on widely adopted existing or emerging software standards. Further, it implies that, in the case of COMMAN, the mobile terminal should include appropriate hardware (e.g routers, communication services controller, etc.) and software (e.g. NDIS drivers, etc) which : ♦ will provide existing standard interfaces (such as RS232C, Ethernet, USB) to interconnect standard hardware devices directly or via a standardised bus, ♦ will allow application developers to make use of existing widely adopted protocols (such as TCP, IP, Ipv6, UDP, ISDN S0, MiTS, etc) or emerging protocols (PISCES, etc.), ♦ will allow application developers to access the available communication channels and set-up, maintain and finalise calls directly from the application’s user interface, ♦ will allow seamless access of available communication bearers.  (3G Feature, “bandwidth on demand”): it is desirable that COMMAN system design should, where appropriate, and the bearer supports the capability, allow the user to select the data rate best suited to the specific application requirements.  (IMT2000): the System configuration should allow ship operators to offer passengers services at competitive prices. 3.7.3. Requirements relevant to review of forth-coming satellite systems/ system proposals The state of the art survey clearly indicated that integrating an S-PCN (otherwise referred as GMPCS) communication system in the COMMAN multimode configuration (such as ICO or Globalstar) may have important consequences for the cost-effectiveness of voice related satellite services for some users. Therefore, the system architecture should allow for the future integration of at least one S-PCN communication channel (such as ICO or Globarstar) in the E-DSRR multimode terminal configuration.  (TOMAS): integration of a satellite UMTS communication channel in COMMAN communication terminal which is able to inter-operate with current Inmarsat Constellation, and able to support high speed data applications at rates up to 384 kbps.  (Horizons): horizons’ developments with Inmarsat should be reviewed, and appropriate measures taken in the COMMAN system design in order to secure future integration of a Horizons compatible communication channel into the system.  (PCS systems): as there is the potential to “share” a mobile terminal among different users, the COMMAN management software should include a “billing” mechanism to enable proper allocation of TR4006/D3.1/MARAC/NP/220399/1.0 - 84 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report costs. In this respect further investigation is needed to see if user stations could be connected to the mobile terminal via a digital (ISDN compatible) private branch exchange.  (LEO constellations investigation): as LEO satellites are not geostationary, it is necessary for a connection to move from one satellite to another as satellites move, out of range. LEO satellites are arranged in constellations so that coverage is, more or less, constantly available. It is desirable that COMMAN copes with any side-effects of this hand-off, e.g.. short interruptions to the connection. Further investigation is required to assess the extent of hand-off effects.  (DVB): to reduce satellite costs when the principle data flow is shore to ship (e.g. for internet access), the ship to shore traffic can be sent on a low cost, low bandwidth link and the shore to ship link can be a high speed satellite link. For COMMAN it should be possible for the ship/shore link to use local VHF/radio links. Further investigation into the feasibility of this mechanism is required.  (TOMAS): generic communication services provided by the COMMAN multimode system should be subdivided into bearer- and tele-services. ♦ Bearer services should include: ♦ low Speed Services with bearer rates up to 64 KBit/s, ♦ medium speed services with bearer rates up to 384 KBit/s, ♦ high speed services with bearer rates up to 2 MBit/s. ♦ Tele services should include: ♦ video/audio Services using bearer rates up to 384 KBit/s, ♦ multimedia services using bearer rates up to 384 KBit/s, ♦ IP-connectivity using bearer rates up to 2048 KBit/s. 3.7.4. Requirements relevant of maritime communication systems & services  (NEVTERK): the on-board system should be configurable as: ♦ single server (a full feature system) comprising all the application modules and supporting two way automatic connections over the available communication links, or ♦ multi Server (a network version of the system) allowing the connection of multiple on-board clients via a standard LAN).  (NEVTERK): The COMMAN architecture should be client/sever while any operating system that is adopted should allow configuration flexibility. The need for an on-shore server should be considered as part of the overall system configuration. There are two possible versions:  corporate (for the individual company) with requirements for its own server for its communication needs),  Telecom (intended for service providers who will offer value-added communication services). 3.7.5. Requirements extracted from projects dealing with on-board data integration and decision support  (SHIDESS): the system configuration should allow the connection to other on-board systems. Otherwise it will be impossible for systems like SHIDESS to acquire, from on-board subsystems, the data necessary for its decision support applications (ship efficiency assessment, predictive maintenance, safety level assessment, data logging and analysis) and transmit them to shore. TR4006/D3.1/MARAC/NP/220399/1.0 - 85 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 3.7.6. Requirements relevant to review of transponder/AIS equipment, systems & system proposals In relation to integration of an appropriate AIS device into COMMAN configuration designers should primarily consider the following documents:  recommendation on AIS performance standards, IMO MSC69/22/Add.1/Annex 12, May 1998;  technical characteristics for a universal shipborne automatic identification system using time division multiple access in the maritime mobile band, Draft ITU recommendation, working party 8B, 30/3/1998. 3.7.7. Requirements relevant to tele-medicine projects review  (MERMAID, NIVEMES): COMMAN should support applications enabling structured communication between paramedic and doctor using predefined report forms, message types and information request forms.  (MERMAID): COMMAN user stations should be based on a standard environment allowing access by a variety of communication channels.  (MERMAID): the COMMAN system configuration should allow updating of multimedia information stored locally.  (MERMAID): COMMAN should establish a user-friendly interface allowing the recording and playing back of audio and video messages (to be used in case bandwidth constraints do not allow the transmission of live information).  (MERMAID): the COMMAN configuration should enable the integration of tools enabling language- independent communications.  (MERMAID, NIVEMES): the system configuration should allow the incorporation or access to on- board databases.  (MERMAID): the system should support connections to many different medical centres, according to location of the user, availability of medical centre and user preferences. 3.7.8. Requirements relevant to review of TCP/IP communications over satellite (Informative note for further consideration by the design team) The TCP/IP protocols are designed for use in high-bandwidth networks with low Bit Error Rates (BERs). In contrast, marine communications and satellite communications have a comparable low bandwidth and high BERs. TCP is designed to respond to the overall traffic across a busy network and therefore it treats all lost packets as due to network congestion; it does not expect packets to be lost due to corruption. In addition, TCP begins each connection by determining the network usage which, due to the satellite uplink and downlink transmission times, can be a significant overhead on the end-to-end connection. The TCP protocol elements that can be used to counteract these effects are described below. Note that as TCP over satellite is an area of research in the Internet community this section is only a snapshot of the mechanisms (which may not be implemented in commercially available protocol stacks). In addition, due to the end-to- end nature of TCP connections, the mechanisms described can apply to the overall connection, the shore TR4006/D3.1/MARAC/NP/220399/1.0 - 86 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report side of the connection, the satellite link, or the COMMAN server side. Further investigation is required to determine which mechanisms need be supported. To address the BER of the satellite link it is possible to split the end-to-end TCP connection at the satellite link and either use a different protocol over the link, or use specific correction techniques across the link. The use of a different protocol is referred to as spoofing. The disadvantage of this technique is that the end-to-end aspects of the TCP connection are lost. An example of changes to the protocol for the link is Snoop, which uses an additional network layer protocol to retransmit corrupted packets. To address the high latency across the satellite link and the resulting overhead caused by the TCP startup process, the following protocol elements can be used: Slow Start, Congestion Avoidance, Path MTU Discovery, Fast Retransmit and Fast Recovery. In addition, the protocol could be amended so that different connections on the same bearer use the same (already validated) TCP parameters which removes the need for the parameters to be negotiated for every connection, or to employ large TCP Windows (which implies the use of PAWS and RTTM). To address the low bandwidth of the satellite links, channel aggregation techniques can be employed. Effectively, the TCP packets are partitioned across a set of satellite connections by the originating end and recombined at the receiving end. It is possible to add or remove channels during the course of a connection to give bandwidth on demand. Note that this technique is not applicable to UDP packets. The technique is described in several protocols, i.e. AS/NZS 4064, ISO/13871BONDING and Multilink Point- to-Point Protocol. Generally, it is useful to minimise the amount of data sent; the less data the lower the probability of corruption and the impact of the bandwidth and latency is reduced. It is desirable for compression techniques to be used on the IP payload (which has lesser effect if the data is pre-compressed) and on the TCP/IP header. 3.7.9. Requirements relevant to review of VSATs  The capability for COMMAN to be extended to support Very Small Aperture Terminals (VSAT) is desirable. VSAT is used for localised Intranets and potentially could be employed for harbour area Intranets. Note that X.25 is the most commonly used network protocol on VSATs. 3.7.10.Other “Nice to have” features  (Navtex): it should be possible to filter the relevant NAVTEX-data (according to the area and categories). In practice the NAVTEX-printer produces a large amount of data, which has to be viewed by the officer of the watch, and the relevant material extracted, which is time-consuming. It should be possible to filter data from Inmarsat. In practice data sent by Inmarsat and NAVTEX are in parts identical. It would make the work of the officer of the watch much easier, if the information was filtered. Information which is not safety relevant should be stored in an adequate way, to allow the on- board personnel to view it at a convenient time. (However, the filtering should not be done with the server; it is an application function.)  (SINTEF): a Windows 95/98/NT platform is subject to stability problems in a critical environment. SINTEF suggests using Unix as platform for critical servers.  (ArchiPELAGO): in cases where GSM is not directly available the project should investigate whether emerging technologies, such as MESMR, could be integrated in the multimode communication system’s design to provide lower cost access mechanisms to the core GSM/UMTS for narrowband applications). TR4006/D3.1/MARAC/NP/220399/1.0 - 87 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report  (ArchiPELAGO): consider for inclusion the following set of services via the available narrowband radio systems (including AIS): bearer services: connection oriented packet data, at rates up to 19.2 kbps. End to end services: automatic ship position reporting (including handling and delivery of differential corrections), ship identification & reporting, short message service. Other data services involving ship stations and on-board computer systems (data bearer services is used): general purpose e-mail with attachments, ship/ship and ship/shore, secured short messaging with attachments ship to ship, secured short messaging with attachments and electronic data interchange ship/shore, language independent messaging (data) ship/ship and ship/shore, WWW access, intranet access, data file transfer (direct or via internet, based on standard internet compatible protocols), image file transfer (direct or via internet, based on standard internet compatible protocols). 3.7.11.Identified technical constraints relevant to requirements presented in this section 1. COMMAN can only select the least cost route and make optimal use of the channel; it cannot affect the cost of the channel. 2. The use of TCP mechanisms for satellite connections is constrained by their use across the overall connection. TR4006/D3.1/MARAC/NP/220399/1.0 - 88 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 4. Refined system concept & conclusions This final chapter of this document includes, at its first section, a “bird’s eye view” of the COMMAN concept, summarising key information recorded in previous chapters. The table reflects the current views of COMMAN partners and resulted from the discussions carried out during our internal review meeting36. In the final section of the chapter are the main conclusions of the project team, relevant to the context and future of the COMMAN project, as resulted from the user and state of the art survey. 4.1. Refined system concept 4.1.1. Vision statement (a brief statement of WHAT the system should achieve) The primary objective of the COMMAN project is the development and validation of a prototype/demonstrator for an on-board communication manager system. The project addresses the implementation of a “single data node” on board ships, functioning as a hub through which all of the ship’s external communications flows except distress. This will centralise the communications management and give information services access to all available communication bearers (including access to bearers used by GMDSS, when not used for an operation related to distress/safety functionality defined in the GMDSS specifications). Thus, it will provide on board users with a ‘single point access’ to existing or future communication services and shore users a single entry for remote login to the ship’s internal network. An object-oriented communication system architecture shall contribute to establish an overall waterborne transport system architecture. This will be achieved together with a vessel’s internal communication architecture and, taking into account the results from other EU/ National projects (e.g. PISCES/MiTS II). 4.1.2. Target market planned Versions of the system (depending on specific customer requirements) should be suitable for installation in all types of vessels of 500 GRT displacement and above. The main customers for this type of equipment will be shipping companies. 4.1.3. Main users and stakeholders Primary users of the COMMAN system are the crew members on board, especially the watch on the bridge, the captain and the ship’s engineers. Secondary on-board users would include passengers, medical/ paramedic personnel, pilots and visiting technicians. Shore users would include the ship owner, the shipping agent, equipment manufacturers and suppliers, the harbour master, VTS centres, pilots, service providers, network operators and ship-borne retailing services. 36 Carried out on 15/1/98 at Trondheim. According to the procedures foreseen in the RESPECT methodology, being the basis of COMMAN user requirements analysis, at the end of user requirements capture phase, the original system concept should be reviewed by experts within the project team, in the light of the user requirements captured. Based on the results of the review, the concept should possibly be refined or amended to reflect expressed user expectations, and it should be assessed in order to decide whether it constitutes a good basis to develop a prototype. TR4006/D3.1/MARAC/NP/220399/1.0 - 89 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report Further regulatory bodies, especially standardisation bodies and classifications societies define mandatory constraints for the system. 4.1.4. Mission statement, development concept (a brief statement of HOW it is proposed to produce the system) The mission of the COMMAN system is to offer a user-friendly, reliable, and easy to access communication system to support ship-ship and ship-shore communication within all functional areas of the ship operation process, such as:  passage execution, e.g. navigation and data communication between VTS’s and vessels,  management and cargo handling,  engineering and planning operations,  safety, e.g. support of any non-distress related tasks, such as standard reporting procedures according to ISM code, ECDIS updating, etc.. Additionally the system will support personal communications, health monitoring, training, retail services. Ship-ship and ship-shore communication will be improved by integrating the communication manager seamlessly with the on-board ISC network. COMMAN will act as a gateway/firewall between all ship- borne networks and the external world. To ensure flexibility within the COMMAN system, new standards may be considered for adoption. The vessel’s internal flow of information, especially exchange of documents including multi-media documents, will be done in co-operation with the PISCES project producing an on-board integration architecture. 4.1.5. System overview (a brief statement of what the system will look like and how it will operate) The main purpose of COMMAN is to act as a server to support external data communication. The COMMAN single data node on-board a vessel will comprise, at minimum, the following physical modules:  a server, which consists of databases, routers and a switching module (providing switching among various carriers),  a configuration station for network management and system configuration,  gateways/firewalls to the on-board ISC. All available communication bearers (including bearers used by GMDSS, when not used for an operation related to distress/safety functionality defined in the GMDSS specifications) will be accessible by the system. The communication manager shall make optimum use of existing maritime bearers and existing mobile bearers. The project shall exploit the potential arising from connecting COMMAN to emerging/forthcoming satellite & radio/mobile systems. COMMAN should be capable of control, monitoring and distribution of communications services for multiple, disparate legacy and future communications networks from one centralised position. COMMAN should provide the co-ordination and connectivity of components into a heterogeneous information systems environment. These components should include:  communications assets with associated peripherals including radios, switch matrixes, LANs, Legacy Interface Units and modems, TR4006/D3.1/MARAC/NP/220399/1.0 - 90 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report  data services with associated peripherals including input/output processors (IOPs). COMMAN should provide a fully flexible, responsive, resilient and efficient system based on open architectures. COMMAN should promote interoperability through the use of standards. COMMAN, as a minimum, should comprise a high performance workstation using a resilient database storage facility and standard protocols to collect and distribute management information. This includes:  event management & logging. COMMAN should be capable of logging general, diagnostic, security, fault and equipment configuration events; certain events can be inhibited from the log, as determined by COMMAN. COMMAN should be capable of filtering log entries for display in accordance with user selectable criteria, providing the facility to archive log entries to an electronic storage media, and to print logs.  Alarms: COMMAN should be capable of generating visual or visual/audible alarms on detection of specific events. The events for which alarms may be raised should be configurable.  Scheduler: COMMAN should be capable of providing a general facility to permit users to enter timed events (e.g. release of e-mail). Expiry of a timed event results in the provision of a visible indication.  System management: COMMAN should provide system management services covering printer management, physical device storage management, backup and restore facilities, audit facilities, and user account and security management.  Event Reporting: COMMAN should provide an event reporting service that will be used to report detected faults and the results of any BITE results reported by equipment’s. COMMAN will report its own status and the status of each item of equipment that supplies COMMAN with fault or diagnostic information; the equipments supply COMMAN with differing degrees of fault and diagnostic information. COMMAN should provide the following benefits: • centralised management, • faster maintenance through BITE reporting. COMMAN should be both asset and bearer independent and should be capable of being scaled to meet varying platform fits and requirements37. The work should be seen as providing candidate protocols for adoption as maritime standards by the EU in the near future. During the COMMAN single data node evaluation and demonstrations a number of representative end user systems/applications will exchange data over radio/ satellite bearers. 4.1.6. System boundary The COMMAN single data node provides the mechanism for connecting users of all clients connected to the on-board networks to the ship’s external communications. • The COMMAN architecture will include the capability for future expansion to include the management of off-board dial-up voice (and fax) connections.  COMMAN will support data/user authentication.  The development of the COMMAN system architecture will consider the need for an ashore peer level data hub.  COMMAN will provide the interfaces to, and where possible control of, the radio/satellite systems. 37 Due to current project’s budget restrictions the system demonstrator, to be developed during the project, will be capable for data only functionality. However, it must be noted, that COMMAN should be designed in order to enable future enhancements, for instance providing connections for voiceband applications such as telephony and fax, by accessing any available bearer able to support such functionality. TR4006/D3.1/MARAC/NP/220399/1.0 - 91 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report  It is expected that DISC project will develop the prototype internal gateway/firewall that will be used to interconnect the COMMAN server to the ship’s real-time and operational control systems. Outside the system boundaries:  With the exception of the system management workstation, which may support limited end user functionality, the client workstations used for multimedia and/or data only end-user applications accessing COMMAN system, will be plugged into , DISK, PISCES, networks, any other administrative local area network on board vessel, or will be part of legacy systems interfaced to COMMAN. Such workstations will be properly equipped (from software and hardware point of view) in order to be capable of accessing COMMAN and its services via a user friendly and easy to use graphical user interface and/or the end-user application HMI.  COMMAN will not include GMDSS distress functionality. It will make use of the bearers that are also used by GMDSS and will provide mechanisms to enable their use when required for GMDSS exchanges. The COMMAN system should not disturb safety procedures that are using GMDSS capable communication devices. 4.1.7. System boundary (COMMAN demonstrator) The COMMAN single data node provides the mechanism for connecting users of all clients connected to the on-board networks to the ship’s external communications. The COMMAN architecture will include the capability for future expansion to include the management of off-board dial-up voice (and fax) connections. The system boundaries of the COMMAN demonstrator can be defined along the following axes: system users, protocols and generic functions. (See also context diagram in D3.1/ paragraph 3.5.7.3.) System users:  TCP/IP based local area networks (as DISC II, PISCES and other existing or new administrative networks); DISC/PISCES will develop the prototype internal gateway/firewall that will be used to interconnect the COMMAN server to the ship’s real-time and operational control systems;  other onboard connected system(s),  system administrators,  bearers,  ashore hub; the development of the COMMAN system architecture will consider the need for an ashore peer level data hub;  telephone network (PABX),  user interfaces regarding connection management of external connections over COMMAN; COMMAN will provide the interfaces to, and where possible control of, the radio systems. Protocols internal to the ship  TCP/IP protocol suite, UDP, (For interfacing legacy systems) ISDN BRI (S0 Interface) Protocols external to the ship  PPP (MP), SLIP, IP-MUL Bearers through Legacy Interface Units:  Inmarsat A/B/C, VHF, HF, GSM, UMTS, DECT , E-DSRR Outside the system boundaries:  Workstations, GMDSS as mentioned previously in 4.1.6 TR4006/D3.1/MARAC/NP/220399/1.0 - 92 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 4.1.8. Generic functions Generic functions are independent of specific applications forming the basic functionality of the communication manager system. They include:  integration of disparate legacy and future communications networks,  “seamless roaming” and least cost routing among available carriers,  effective and efficient communications management techniques,  provide operational and support information relating to communications usage,  network management: resources and trouble shooting,  network security: authorisation and protection mechanisms, validation of messages,  system configuration,  quality of service routing,  internet/intranet access,  provide access to on-board/on-shore databases with/without multimedia content,  wireless access to terrestrial ISDN,  wireless access to terrestrial or satellite high speed communication networks. 4.1.9. Basic applications (used as tools to execute several tasks) Functional and non-functional requirements relating to end users applications, supported by other systems and requiring external connection through COMMAN require consideration for impact upon COMMAN functional and non-functional requirements. Basic applications cannot be allocated to a specific task or function, but are used as “tools” to execute several tasks. They include:  video-conferencing via the available (depending on the system configuration) high speed communication channels; COMMAN should incorporate both PAL and NTSC format;  e-mail with attachments (limited in size),  internet/intranet browser capabilities,  IP-voice communications via the available (depending on system configuration) narrow band or high speed communication channels38,  short messaging service via on board transponder equipment,  Internet Relay Chat (IRC),  whiteboarding,  database access.  (Future enhancements) Telephony, Fax 39 4.1.10.Future basic applications An indicative set of applications which might be supported in the near future include:  wireless access to UMTS, S-UMTS (if possible),  communication aids to vessel automatic berthing operations, support to language independent communication and bridge information exchange tasks by integrating suitable language independent communication and speech processing tools. 38 Implementation in the project’s demonstrator is subject, budget permitting, to further investigation during WP06 39 Not to be supported/ implemented in the COMMAN demonstrator during the course of the present project TR4006/D3.1/MARAC/NP/220399/1.0 - 93 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 4.1.11.Communication channels  The system should establish an environment comprising a multi-mode and multi-band capability. It should incorporate a variety of communication modes which enable inclusion of any existing or emerging bearer service (satellite and/or radio) which can be made practically available to maritime users.  The system should include a transponder/AIS capability.  The system should have an interface to a satellite navigation receiver.  Compatibility with land-based fixed networks should be included.  The capability to access ISDN (for tele-medicine services, dissemination of ECDIS updates etc.) should be included.  The investigation on the forthcoming third generation systems revealed that the system should be able to be connected to bearers (satellite and/or radio) able to support services with data rates up to 384 Kbits/s. 4.1.12.Maintainability The selected technology shall be used to create a robust network architecture which will minimise requirements for maintenance and down-time. It shall have in principle continuous availability during operation. 4.1.13.Existing system or new development The project strategy is to base the communication manager system as far as possible on commercially off the shelf products and minimise additional hard- and software. The end product must become an add-on to the available range of commercial systems in use, not requiring replacement of such equipment. 4.1.14.Single user or multi-user COMMAN will be a multi user system to be accessible from all clients connected to the on-board networks (ISC network and administrative networks). With respect to the operation of the COMMAN server itself there will be one single management workstation. 4.1.15.Physical environment As a general rule standard “office” environment conditions will apply for equipment installed indoors: 0 – 35 °C, 45-85 % relative humidity. For equipment installed outdoors the following conditions will apply:  -15 - +55 °C temperature,  up to 95% humidity at 40 °C,  up to 100 knots wind speed,  up to 100 mm/hour precipitation. TR4006/D3.1/MARAC/NP/220399/1.0 - 94 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report Vibration or instability: the following parameters should be considered: 2-10 Hz/ 2,54 mm; 10-100Hz/1G; as far power is concerned it is assumed that the power supply unit will be included in the (usually) indoor part of the terminal therefore requirements mentioned in server indoor part should apply;  the effect of pitch, roll and yaw should be considered (usually do not exceed ±150 , ±250 , ±80 degrees, respectively, while the ship turning rate will not exceed 120/sec). 4.1.16.Basic characteristics of the COMMAN system user interface (the way the users will use the system) Staff on board ships usually lack of familiarisation with computers; this requires a user-friendly human machine interface (HMI). COMMAN should allow on-board users, having access to work-stations anywhere on board, to access bearers connected to the COMMAN server seamlessly, via a common user interface. Good ergonomics are essential. Easy to use equipment should result in fewer human mistakes. User interfaces need to have a common “feel” (similar to Microsoft’s). Consistency: minimise the difference in dialogue both within and across various user interfaces. Feedback: provide the user with feedback and error-correction capabilities. Structure: assist the user in developing a conceptual representation of the structure of the system so that they can navigate through the interface. Help: a comprehensive online help facility should be provided. Individualisation: accommodate individual differences among users through automatic adaptation or user tailoring of the interface. Compatibility: minimise the amount of information re-coding that will be necessary. COMMAN GUI should allow the integration or linking to standard end-user application interfaces such as MAPI compliant e-mail applications, standard internet browsers, standard desktop video conferencing tools and standard picture editors. Applications may require the access to on-board or on-shore databases, therefore database search tools should be included. 4.1.17.Organisational/institutional/social aspects (relationship between the operators/users of the system) The communication system should be available on 24-hours basis. COMMAN should reduce the workload of its operator and in any case should not increase it. It is expected that system should adapt the available information to the cognitive process of the operator and foster operator acceptance. Further it is expected that it will reduce cognitive tunnel vision. Operators expect that system implementation should assist them in reducing the vessel’s operating costs. Further they expect to use the system for remote operation and monitoring of on-board processes from offices or control centres ashore. TR4006/D3.1/MARAC/NP/220399/1.0 - 95 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 4.1.18.Safety/security/privacy aspects System services should include a security management system, data encryption for any type of security sensitive data exchanges and virus protection. The introduction of fault tolerance in hardware should be considered. The system should allow secure exchange of data. The level of security should be application dependent. Any security features required by an application (e.g. Encryption) are that applications responsibility. The system server should help the users/applications authenticate each other. Safety critical systems should have separate communications facilities. It is not envisaged that COMMAN will provide a safety critical service (otherwise rigorous software development techniques would have to be adopted). Unauthorised access to essential and important systems and data from a position outside the ship should not be possible. If the ship is chartered, the ship owner may want to restrict the charter company’s access to information. 4.1.19.Standards to consider The COMMAN project should consider developing a “common performance standard” of on board communication equipment. This may include, for instance, a set of minimum performance criteria. For standards to be further considered during design phase, see Appendix A2, User Requirements & State of the Art Survey Report. 4.1.20.Data and information (issues needed by and produced by the system) Not yet identified 4.1.21.Degraded modes of operation (e.g. after failure or during maintenance) Not yet identified 4.1.22.Future expansion (both functional and geographical, planned and possible) Not yet identified 4.1.23.Financial (system development) (Costs and benefits expected) Not yet identified, although this is very important. TR4006/D3.1/MARAC/NP/220399/1.0 - 96 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 4.1.24.Financial (payment of services) (How the user will pay for the service) Not yet identified 4.1.25.Technical constraints 1. Where COMMAN interfaces to legacy or COTS systems, its functionality is constrained by that of the existing systems. 2. Where COMMAN communicates, or manages the communications, with shore based systems, its functionality may be constrained by that of the shore system. 3. All communications are constrained by the bandwidth and features of the available bearers and of the shore side connectivity. 4. COMMAN has no interest in, or knowledge of, the data whose transfer it manages. Any decisions made by COMMAN (eg. Quality of Service) are based on the application only. 5. COMMAN has no interest in the onboard applications. It knows which applications exist in terms of their associated parameters, (e.g. QoS) but not the purpose of the applications. 6. COMMAN has no internal mechanism for the automatic authentication of other vessels. 7. TCP connections require two-way communications, they cannot function in receive only. 8. The availability and reliability of COMMAN is driven by that of the selected hardware. Features such as fallback and clustering will only be provided if the hardware supports it. 9. The transfer of data between onboard applications is external to COMMAN except where COMMAN functions as the repository for data shared between applications. 10. Where functionality can be provided by the selected operating environment (e.g. the hardware or operating system) or by bespoke development for COMMAN, it is preferable to employ existing functionality. 11. The COMMAN design will be modelled in UML using the Rational Rose tool using object-orientated techniques. The software will be developed in C++ and Visual Basic. Its target environment is a Win32 platform. 12. Management of the COMMAN server will be provided by a client application at either the server machine or at a COMMAN workstation connected to the server by the LAN. Some functions of the client will be available remotely on shore. 13. The environmental performance of the COMMAN equipment will be determined by the characteristics of the supplied hardware. 14. COMMAN provides communications management and will provide centralised database functions for data shared between applications. It does not have any knowledge of what the data is. 15. COMMAN selects the bearer based on the application requiring the connection. It cannot select the bearer, or features of the bearer, based on the actual data. 16. Acknowledgement of the receipt of transmitted information is an application-layer function; it is outside the scope of COMMAN. The use of reliable protocols (e.g. TCP) will however ensure that the packets will be received at the other end of the connection. 17. COMMAN can schedule when information supplied to it is transmitted on a given bearer (hence store and forward). However, COMMAN has no control over when applications supply data for transmission. 18. Email functions (e.g. address lists) will be provided by the e-mail application, not COMMAN. Remote management of the e-mail service, if necessary, is outside the scope of COMMAN. 19. COMMAN can only select the lowest cost route and make optimal use of the channels; it cannot affect the cost of the channel. 20. The use of TCP mechanisms for satellite connections is constrained by their use across the overall connection. 4.1.26.Risk (both technical and financial) Not yet identified TR4006/D3.1/MARAC/NP/220399/1.0 - 97 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 4.2. Other general conclusions from state of the art and user needs survey. Project opinion on the high level architecture of future maritime communication systems Emerging satellite systems and third generation communication systems will evolve from today’s second generation mobile systems. They will be compatible with the earlier systems and tend to complement them (not to compete with them), as well as complementing offerings from fixed network providers. As investments will be VERY substantial, such systems will need a large number of users (a critical mass) before their operators will be able to offer prices better than those of today. Future mobile networks, offering higher data rates, are therefore likely to be deployed initially within or around metropolitan areas, while satellite networks will either focus on voice for fixed or mobile users (narrow-band constellations) or fixed users only (broadband constellations). Effort is therefore required to devise new concepts for integration or new technologies. Project partners confirm that, in the light of the state of the art survey, and the user requirements analysis, they continue to see the COMMAN concept as of primary importance for the maritime users. A more detailed review of the context being considered by the project is given in the subsection which follows. In spite of the expected dramatic changes in communications media, and in available terrestrial and satellite technology, the general impact on maritime users is potentially limited.  With the exception of Inmarsat’s Horizons, the networks able to support advanced high speed or broadband service, are focusing on fixed users (Teledesic, SkyBridge, Cyberstar, etc) or mobile users in or around metropolitan areas (terrestrial UMTS, GSM/ GPRS). There are no references in the literature (with the exception of references to studies currently executed under European projects such as ACTS EIES in relation to E-DSRR, and in TOMAS in relation to S-UMTS terminals) which suggest that there are plans for development of terminals or access mechanisms to support maritime applications requiring high speed data rates.  The proposed “narrow-band” Big LEO or MEO systems (such as Iridium, Globalstar, ICO, etc) are focusing primarily on telephony (voice) services. In relation to narrow-band data services, as far as the maritime users are concerned, there are no obvious improvements or new services to be offered compared with what is available today through the Inmarsat 3 constellation. Further, there is no clear evidence that price offering, for data services, will be more competitive. As far as voice applications are concerned, however, it seems that the existence of new systems in the sky may create benefits for maritime users, provided the systems are able to offer similar QoS as Inmarsat today.  There is no current evidence that the Little LEO constellations (Orbocomm, LEO One, and FAISAT) will offer any significant advantage over the Inmarsat C service. It seems that they will offer very low cost terminals but, as Inmarsat C is already available on board (required by GMDSS ), these systems are only likely to be successful (in the maritime community) if they are introduced with a very aggressive pricing policy  UMTS networks, due to spectrum restrictions, investment considerations, and low user density, are not likely to expand over extensive coastlines or sea areas. GSM however, wherever it is available, may provide a cost-effective alternative to Inmarsat.  There are some requirements of maritime users (such as the AIS related requirements) which cannot be covered by any existing or forthcoming generic communication system. Therefore new types of VHF networks will probably emerge primarily focusing on services offered via AIS devices. TR4006/D3.1/MARAC/NP/220399/1.0 - 98 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report Significant improvements for maritime communications can only be expected:  when communication servers are deployed on-board ships as our project suggests; (They should be able to support “seamless” roaming among available carriers and should be equipped with software which will assist the operator to choose the most cost effective communication route.)  when S-UMTS concepts, currently under study in European projects such as TOMAS, are implemented in existing (Inmarsat) or forthcoming systems; (There is very clear evidence that Inmarsat, which participates actively in TOMAS, is very active in this direction.)  when “cordless” technology proposals (such as the systems under investigation in the EIES project, our project, (E-DSRR) or ArchiPELAGO, (MESMR) mature) are integrated into 2G or 3G networks at affordable rates (similar to, or better than, the rates of terrestrial operators; (It is also anticipated that such systems may cost effectively close the gap between the “cellular” or “fixed” operators and the satellite operators, by enabling services in coastal or archipelago areas similar to today’s fixed (ISDN, Internet) or mobile (GSM) networks.) Thus, according to our project view - in the light of the results of the state of the art survey as well as of the user needs analysis, the high level architecture of a communication system able to offer cost effective support for existing or future maritime applications is represented in the following picture: Management Systems Wireless access 3G Satellite Access Multiband S - UMTS Multimode S-PCN S - PCN Maritime Communication System GSM BSS GSM Access Gateways to fixed and/or Other LANs MESMR Systems Mobile core MESMR Networks Ship E-DSRR Gateway (PISCES) E - DSRR Internal LAN Figure 14 Vision on 3G high level architecture – Terminals & Access Networks for maritime users Notes : S-PCN is a term referring to systems such as ICO. S-UMTS is a term related to enhancements of existing terminals or emerging transportable satellite terminals able to support high speed or broadband rates. AIS functionality can be “incorporated” in the access mechanism of MESMR networks, that is why it is not referred to as a separate item. Satellite PCN as well as GSM mode are intended primarily to provide voice services and narrowband bearer services, wherever available. MESMR (or AIS) is intended to provide automatic identification services and be used for narrow-band bearer services wherever available. E-DSRR and S-UMTS modes are intended for high speed bearer services, to support multimedia applications. TR4006/D3.1/MARAC/NP/220399/1.0 - 99 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 5. References 1. GSM overview, by John Scourias, University of Waterloo, October 14, 1997 2. Mobile Data Communications in Europe, a market perspective, a report of Dataquest prepared for the mobile data initiative, October 1996 3. Mobile Internet Intranets, a report from OVUM, February 1998. 4. The pan-European trunking standard TETRA, Current status, perspectives and technology, by Pekka Blomberg/ Nokia, presented at KKRR'97 Poland, May 1997 5. TETRA, a golden opportunity, by J.A. Richter, European Commission, TETRA workshop, Autel, Madrid January, 1986. 6. Summary of ”Vision for the Evolution from GSM to UMTS”, version 3.0.0, TG13, GSM MoU organisation, 28/4/1998 7. Vision for the evolution from GSM to UMTS, version 3.0.0, TG13, GSM MoU organisation, 30/4/1998 8. MoEBIUS Deliverable: "Local Data Radio Link - Part 1: Concept Definition", Document R2040/UHB/FB1/DS/L/041/b1, June 1993. 9. Schubert, T. Antoulinakis, I. Mourtsiadis: "Radio Link for Unimpeded Data and Digital Video Transmission from Confined Spaces", Seminar on Advanced Communications in Shipping, Athens, June 1994. 10. Schubert: "Ship-Board Cordless Extension of Mobile Satellite Communication Links Supporting Multimedia Services", RACE Mobile Telecommunications Workshop, Amsterdam, May 1994. 11. Wireless Multimedia needs & Scenarios, EIES Deliverable D15, November 1996, 12. Space Siren, by Jonathan Burke, The Red Herring Magazine, November 1997 13. Does latency matter? a white paper from TELEDESIC, published currently at http://www.teledesic.com 14. FPLMTS brochure by ITU, published on IMT2000 official ITU Internet site 15. ITU vision on IMT2000, published on IMT2000 official ITU Internet site 16. UMTS forum Report on UMTS/IMT-2000 Spectrum Requirements, prepared for WRC97, October 1997 17. UMTS Market forecast study from Analysis UK & INTERKAI, conducted in behalf of the European Commission, February 1997 18. TOMAS a project overview, prepared by TOMAS project, 1998 19. S-UMTS technical guidelines, by M. Franken (Inmarsat), A. Timm (University of Bremen) and A. Schubert (MediaMobil), Tomas deliverable D6.1 20. Survey on Modulation and Coding Schemes applied for Mobile Satellite Communications, A. Timm, G. Karachos, Dec. 1997, TOMAS Document,, Doc. No: AC201/UHB/IHN/PI/L/008/a1 21. Requirements for the third generation system architecture, The GSM MoU organisation, Version:3.1.0., 28th April 1998 22. ISDN General Structure and Service Capabilities; Broadband Aspects of ISDN, ITU Rec. I.121 : Geneva 1991 23. Transmission & Encoding Systems For Third Generation Mobile Communication Systems, GSM MoU 3GIG PRD TG.35 : 24. Target 3G Core Network Requirements, GSM MoU 3GIG PRD TG.34 : 1998 25. UMTS Access Network Requirements, GSM MoU 3GIG PRD TG.37 : 1998 26. Terminal Equipment For Third Generation Systems, GSM MoU 3GIG PRD TG.32,. 1998 27. The application of the Integrated Shipboard Information (ISIT) platform to Ship Safety and Port Inspection, by E. Story, 31/5/96 28. Capacity & Throughput using a self organised time division multiple access VHF data link in surveillance applications, Master Thesis, R. Kjelberg, April 1998 29. Ship Identification and data transfer. An analysis of limiting factors in the choice of technical solutions, by Captain A. Winbow, UK Marine Safety Agency. 30. Recommendation on AIS performance standards, IMO MSC69/22/Add.1/Annex 12, May 1998. TR4006/D3.1/MARAC/NP/220399/1.0 - 100 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report 31. Technical characteristics for a universal shipborne automatic identification system using time division multiple access in the maritime mobile band, Draft ITU recommendation, working party 8B, 30/3/1998. 32. What is Skyplex, an article of Eutelsat published at Eutelsat www site, August 1998. 33. “Spectrum Issues – Recommendations on MBS and WLANS”, by Robert Geiss, ERO – presented at Wireless broadband Communications work-shop organised by DGXIII-B, September 1997 34. “DECT – The standard explained” , Paper published at DECT forum website, February 1997 35. An innovative approach for automatic identification systems and narrow-band communications services in the vicinity of a VTS, by N. Panagiotarakis, September 1998 – a paper presented in MARCOM98 conference 36. User centred Requirements and Design handbook, D5.2, version 2.0, April 1998, RESPECT project 37. Guidebook for User needs analysis, Version 3, February 1998, CODE project 38. Analysis of user requirements & tele-medicine experiences world-wide, MERMAID deliverable D1.1 39. State of the Art Survey, October 1998, conducted from Horama Marketing & Engineering services on behalf of Marac Electronics S.A for ArchiPELAGO, E-DSRR & COMMAN projects 40. The application of the Integrated Shipboard Information (ISIT) platform to Ship Safety and Port Inspection, by E. Story, 31/5/96 41. DISC final Report, D101.00.01.047.003C, 24/3/98, by DISC project 42. Guidelines for the Development and Assessment of Intelligent Transport System Architectures, Deliverable DSA2.3, 10/2/98, CONVERGE project. 43. COMMAN: 1st COMMAN User forum report, DERA January 1999 44. ATOMOS Requirements Specification on Data Transmission, Id-Code 2312.01.03.063.001E (Aalborg University, 1992) 45. ATOMOS Model Specification for the ATOMOS Diagnostic System. Id-Code 2306.06.07.064.001B, (STN Systemtechnik Nord, 1995) 46. ATOMOS II ISC Architecture and Reference Model – System requirement Specification. Id-Code A221.02.09.051.001A, (Lyngsoe Marine A/S, 1996) 47. PISCES User requirements. Id-Code TR-STF/ojr-3.1-2 (Internal document, 1998) 48. PISCES ISC Protocol requirements. Id-Code MD-STF/ojr-3.0-36 (Public after review, 1998) 49. POSEIDON Consolidated Report on the specific User requirements. Id-Code TR104/A/DE/ISSUS/d21-v10.doc/W6.0a/1.0, (1996) 50. Standard guide for Implementation of a Fleet Management System, ISO draft standard No 15849, 9-11-1998 TR4006/D3.1/MARAC/NP/220399/1.0 - 101 -
    • COMMAN/D3.1/User Requirements & State of the Art Survey Report APPENDICES A1 Glossary & Abbreviations A2 Standards to consider (Informative) A3 Ideas for COMMAN graphical user interface (Informative) A4 1st User Forum Report Summary A5 Requirements to the system architecture (Informative). TR4006/D3.1/MARAC/NP/220399/1.0 - 102 -