Docstoc

COMMAN rescue and medical equipment

Document Sample
COMMAN rescue and medical equipment Powered By Docstoc
					             COMMAN
   Communication Manager System
for Data Exchange for Ship Operations

      Telematics Application Programme
              Transport Sector
             Project No TR4006




       Deliverable D4.1

 Functional Specifications



             Version 1.3




            August 1999
COMMAN / D4.1 Functional Specifications


                                   COMMAN

           Communication Manager System for Data Exchange
                         for Ship Operations



                                    D4.1
                           Functional Specifications


Copy No: 0/1/2/3/…



Deliverable:             Functional Specifications
Work Package:            WP No 4
Dissemination Level : restricted
Nature: Draft Report


Agreed delivery date :         July 1999   Actual delivery date : August 1999




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                          Page 2
COMMAN / D4.1 Functional Specifications

Technical Abstract:
This report is intended to summarise information gathered within the COMMAN project
related to the study of the functional specifications for the proposed Single Data Node, which
will be studied and demonstrated within the project. It begins by a short presentation of the
objectives and the aims of the use of the Single Data Node. Then, a summary of the
methodology is provided so as to emphasise the different phases of the project and especially
to link the user-centred approach and the system-centred approach. After that, a very general
overview of the service required by the users is done, linked with the COMMAN system
overview, from the point of view of the applications used and of the system high-level
architecture.
Then, the functionalities of the system are detailed. First, concerning the communication tasks
in their entirety and then, more specifically concerning the communications themselves; at
this step, some sub-functions are identified. In the continuity, the focus of the next step is on
the management of the communications with a special interest on the COMMAN database.
To finish, the features specified in the document are illustrated in two “real-life” situations.




Keywords: Functionalities, Specifications, Feature, System, Management,
Database, Sub-function




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                    Page 3
COMMAN / D4.1 Functional Specifications


                                   COMMAN
         Communication Manager System for Data Exchange
                       for Ship Operations


                        Functional Specifications

       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
              EUTELIS                           Pierre GESLOT
                                                Yann DEPOYS

        Contributing Organisations              Contributing Authors
                      ISSUS                     Sylvia ULLMER, Jörg THIESING, Lars
                      DERA                      Gerhard KUEHL
                                                Peter KNIGHT, Mike HADLEY, Andrea
                     SINTEF                     LEWINGTON, Steven ADAMS
                                                Ole SOLBERG, Anders SOLHAUG, Bjorn
                       Bae                      BJANGER
                                                Richard HENSMAN




Authorised by:

        Project Co-ordinator
               ISSUS                            Prof. Jens Froese


Document History:
           Version             Status/Revised Paragraph (s)            Date
             0.1         Draft version                                         8/06/99
             1.1         Version for internal validation                      30/06/99
             1.2         Version for peer review                              16/07/99
             1.3         Final (after final internal validation)              10/08/99




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                   Page 4
COMMAN / D4.1 Functional Specifications



                                            No.
                    PAGES                   125
                    FIGURES and TABLES      48
                    ANNEXES                 35


                                    Issued by
                         Pierre GESLOT and Yann DEPOYS




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                   Page 5
COMMAN / D4.1 Functional Specifications

Distribution List:


Copy No Recipient                         Status    Location

1         Sylvia Ullmer                   C1        ISSUS
2         Alexandra Kalapoutis            A1.1      TRUTh
3         Kersten Gevers                  S1.1      Seven Cs
4         Peter Knight                    C2        DERA
5         Brian Houston                   A2.1      BAeSEMA
6         Yann Depoys                     C3        Eutelis
7         Pierre Geslot                   C3        Eutelis
8         Jean-Manuel Canet               C3        Eutelis
9         Antony Kantidakis               C4        MARAC
10        Nick Panagiotarakis             S4.1      HORAMA
11        Bjorn Willoch Bjanger           C5        SINTEF
12        Paul Flament                    DG XIII   CEC
13        Christos Pipitsoulis            DG XIII   CEC




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                         Page 6
COMMAN / D4.1 Functional Specifications


                                Table of Contents




EXECUTIVE SUMMARY                                                                 14

1 - INTRODUCTION: AIM OF WP4                                                      16

2 - THE COMMAN SYSTEM : PRESENTATION AND OBJECTIVES                               17

2.1     Presentation of the COMMAN system                                         17

2.2     Target market                                                             17

2.3     The present situation                                                     18

2.4      COMMAN features                                                          18
  2.4.1.   Main features                                                          18
  2.4.2.   Likely impact of the COMMAN system                                     18

2.5      Main functionalities of the COMMAN system                                19
  2.5.1.    The COMMAN system will allow connection to the following bearers      19
  2.5.2.    COMMAN System Services                                                20
  2.5.3.    COMMAN Management Services                                            20
  2.5.4.    COMMAN concept of usage concerning IP Communications                  21
  2.5.5.    Real life use of the COMMAN system                                    23

3 - METHODOLOGY AND FRAMEWORK                                                     24

3.1     Introduction                                                              24

3.2      Detailed presentation of WP4                                             25
  3.2.1.     Overview                                                             25
  3.2.2.     Work breakdown                                                       26
    3.2.2.1.     Phase 1                                                          26
    3.2.2.2.     Phase 2                                                          26
    3.2.2.3.     Phase 3                                                          27
    3.2.2.4.     Phase 4                                                          27
    3.2.2.5.     Phase 5                                                          27

4 - OVERVIEW OF THE COMMUNICATION TASKS                                           29

4.1      Requirements                                                             29
  4.1.1.     General needs                                                        29
  4.1.2.     Communication tasks                                                  30
    4.1.2.1.    Categories                                                        30
    4.1.2.2.    Task list                                                         30

4.2      View of the system                                                       36
  4.2.1.     Position                                                             36


TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                         Page 7
COMMAN / D4.1 Functional Specifications

  4.2.2.     Available applications                                             37
    4.2.2.1.     Application generating IP traffic                              37
    4.2.2.2.     Application generating non-IP traffic                          38
    4.2.2.3.     Mapping of the different applications with the different types of
    communication tasks                                                         38
  4.2.3.     Characterisation of the different types of traffic                 41
    4.2.3.1.     Off-line IP from ship                                          41
    4.2.3.2.     Online IP from ship                                            42
    4.2.3.3.     Off-line non-IP from ship                                      42
    4.2.3.4.     Online non-IP from ship                                        42
    4.2.3.5.     Off-line IP to ship                                            42
    4.2.3.6.     Online IP to ship                                              42
    4.2.3.7.     Off-line non-IP to ship                                        43
    4.2.3.8.     Online non-IP to ship                                          43

5 - FUNCTIONALITIES OF THE COMMAN SYSTEM                                         44

5.1      Functional architecture of the system                                   44
  5.1.1.    Presentation                                                         44
  5.1.2.    High Level Functional and Communication Architecture                 45
  5.1.3.    High-level architecture                                              45

5.2      User Level features of the COMMAN system                                48
  5.2.1.     The COMMAN SDN Access                                               48
  5.2.2.     Compose, Send and receive Message                                   49
  5.2.3.     COMMAN Delivery Requirements (CDR)                                  50
    5.2.3.1.     CDR for offline communications                                  50
    5.2.3.2.     CDR for online communications                                   51
  5.2.4.     Configuration and Maintenance of the system                         51
  5.2.5.     Miscellaneous                                                       52
  5.2.6.     Current issues                                                      52
    5.2.6.1.     Functionalities to add or refine                                52
    5.2.6.2.     Interfaces issues                                               53

5.3      The processes supported by the COMMAN system                            54
  5.3.1.     Outgoing communications                                             55
    5.3.1.1.     List of tasks                                                   55
    5.3.1.2.     Flowchart: Outgoing communication with and without request      56
    5.3.1.3.     Flowchart: Routine Outgoing communication                       58
  5.3.2.     Incoming communication                                              61
    5.3.2.1.     List of tasks                                                   61
    5.3.2.2.     Flowcharts: Download and receive with request                   62
    5.3.2.3.     Flowcharts: Download without request                            65
    5.3.2.4.     Flowcharts: Broadcast and generic incoming communications       66
  5.3.3.     Bi-directional communications                                       68
    5.3.3.1.     List of tasks                                                   68
    5.3.3.2.     Flowcharts: Voice                                               69
    5.3.3.3.     Flowcharts: Web access                                          71
    5.3.3.4.     Flowcharts: Secured payments                                    72
    5.3.3.5.     Flowcharts: Remote management network                           73

6 - SUB-FUNCTIONS OF THE COMMAN SYSTEM                                           74

6.1     Sub-functions list                                                       74

TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                        Page 8
COMMAN / D4.1 Functional Specifications

  6.1.1.      System Access related sub-functions                            74
  6.1.2.      Bearer management related sub-functions                        75
  6.1.3.      Network monitoring and management related sub-functions        75
  6.1.4.      QoS management related sub-functions                           76
  6.1.5.      Store and forward related sub-functions                        76
  6.1.6.      Service related sub-functions                                  76
  6.1.7.      Non IP related sub-functions                                   77

6.2      Links between the sub-functions                                     78
  6.2.1.     IP communications detailed                                      78
    6.2.1.1.     Outgoing Offline IP communication                           78
    6.2.1.2.     Incoming Offline IP communication                           80
    6.2.1.3.     Outgoing Online communication                               81
    6.2.1.4.     Incoming online                                             82
  6.2.2.     Non-IP communications detailed                                  83
    6.2.2.1.     Outgoing call                                               83
    6.2.2.2.     Incoming call                                               83

7 - MANAGEMENT SUB-FUNCTIONS DETAILED                                        84

7.1        The different management areas                                    84

7.2      Detail of the “System Access” sub-functions                         85
  7.2.1.     Check authenticity of incoming request                          85
  7.2.2.     Check acceptability of incoming request                         86
  7.2.3.     Filter non-authorised data service requests                     87
  7.2.4.     Check Authority                                                 88

7.3      Detail of the “Bearer” sub-functions                                88
  7.3.1.     Detect incoming call                                            88
  7.3.2.     Bearer selection                                                89
  7.3.3.     Check bearer availability                                       90
  7.3.4.     Connect to bearer(s)                                            90
  7.3.5.     Connection termination                                          91

7.4      Detail of the “Network” sub-functions                               92
  7.4.1.     Detect outgoing call request                                    92
  7.4.2.     Determine onboard host                                          93
  7.4.3.     Establish connection to onboard host                            93
  7.4.4.     Identify host(s) available                                      93
  7.4.5.     Connect onboard e-mail server to server ashore                  94
  7.4.6.     Connect non-IP to appropriate destination                       95
  7.4.7.     Connect call to appropriate IP service                          95
  7.4.8.     Format data for onboard host                                    96
  7.4.9.     Recording                                                       96

7.5      Detail of the “QoS” sub-functions                                   96
  7.5.1.     Request appropriate connectivity                                96
  7.5.2.     Negotiate QoS that can be provided                              96
  7.5.3.     Obtain CDR                                                      97

7.6      Detail of the “Store and forward” sub-functions                     97
  7.6.1.     Queue request/Prioritise calls                                  97
  7.6.2.     Download mail in accordance with urgency and cost criteria      98
  7.6.3.     Poll host mail server and send queued mails                     98

TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                    Page 9
COMMAN / D4.1 Functional Specifications

7.7      Detail of the “Service” sub-functions                                 99
  7.7.1.     Identify call service type (IP/non-IP)                            99
  7.7.2.     Calculate call cost                                               99
  7.7.3.     Identify user call characteristics                               100
  7.7.4.     Call cost estimation                                             100
  7.7.5.     Real time calculation and display of cost                        100
  7.7.6.     Record call cost                                                 100

8 - OPEN ISSUES                                                              101

8.1      Databases                                                            101
  8.1.1.     Messages database                                                101
  8.1.2.     Management database                                              101
    8.1.2.1.      System access management                                    102
    8.1.2.2.      Bearers management                                          102
  8.1.3.     Entity-Relationship Model                                        103
    8.1.3.1.      Request for Establishment and Use of Connection             103
    8.1.3.2.      Users (Accounts) and Groups                                 105
    8.1.3.3.      Bearer Availability Forecast                                106
    8.1.3.4.      Transmission Forecast                                       107
    8.1.3.5.      Communication Accounting                                    108
    8.1.3.6.      COMMAN Delivery Requirements                                109
  8.1.4.     General data                                                     109

8.2      Security                                                             109
  8.2.1.     The security needs                                               109
  8.2.2.     Requirements for the COMMAN firewall                             115
    8.2.2.1.      General considerations                                      115
    8.2.2.2.      Requirements for the COMMAN firewall                        115

9 - ILLUSTRATION OF THE FUNCTIONALITY                                        117

9.1      1st scenario: The collision                                          117

9.2      2nd scenario: The cruise                                             120

10 -     GLOSSARY                                                            124

11 -     ANNEXES                                                             127

I.   USE OF SCENARIOS                        TO     ASSESS      THE   FUNCTIONAL
SPECIFICATIONS                                                               128

A. Introduction                                                               128

B. Summary of method                                                          128

C. Detailed Assessment Method                                                 129

D. Scenario 1 : The Collision                                                 129

E. Scenario 2: The cruise                                                     133


TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                     Page 10
COMMAN / D4.1 Functional Specifications

F. Assessment results                                       136
  1. Activity (from scenario 1) VS Applications             136
  2. Activity (from scenario 2) VS Applications             139
  3. Application types VS Sub functions                     141

G. Conclusions                                              148
  1. Functionalities to add or refine                       148
  2. Interfaces issues                                      148
  3. Payment procedure                                      149

II. GENERAL DATA EXCHANGED DURING THE COMMUNICATIONS 150

III. INTERVIEWS                                            152

A. DELMAS Company Interview                                 152

B. “Port Autonome du Havre” Piloting Station Interview      154

C. Interviews at ISSUS and SUSAN related to WP3 and 4       157

IV. PEER REVIEW REPORT                                     158

1 The Peer Review Process                                   160

2 Comments on Deliverable                                   160

3 Summary                                                   161




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                   Page 11
COMMAN / D4.1 Functional Specifications



                                                  Table of Figures



FIGURE 1: METHODOLOGY OF THE FUNCTIONAL SPECIFICATIONS WORK
    PACKAGE ...................................................................................................................... 24
FIGURE 2: STEPS OF THE SPECIFICATIONS .................................................................. 25
FIGURE 3: LINK BETWEEN THE USER-CENTRED APPROACH AND THE SYSTEM-
    CENTRED APPROACH ................................................................................................ 39
FIGURE 4: MATCHING OF THE COMMUNICATION TASKS WITH THE
    APPLICATIONS ............................................................................................................. 41
FIGURE 5: MAIN COMPONENTS OF THE COMMAN SINGLE DATA NODE ............. 44
FIGURE 6 COMMAN HIGH LEVEL FUNCTIONAL AND COMMUNICATION
    ARCHITECTURE ........................................................................................................... 45
FIGURE 7: COMMAN HIGH-LEVEL ARCHITECTURE ................................................... 46
FIGURE 8: COMMAN LOGICAL LAYERS ........................................................................ 47
FIGURE 9: THE DIFFERENT TYPES OF PROCESSES UNDERTAKING
    COMMUNICATION TASKS......................................................................................... 54
FIGURE 10: OUTGOING CALLS ......................................................................................... 56
FIGURE 11: FLOWCHART OF THE GENERIC OUTGOING CALL ................................ 57
FIGURE 12: SEND THE ETD................................................................................................ 58
FIGURE 13: FLOWCHART OF THE ROUTINE GENERIC OUTGOING CALL .............. 59
FIGURE 14: SENDING THE ETA......................................................................................... 60
FIGURE 15: INCOMING CALLS.......................................................................................... 61
FIGURE 16: FLOWCHARTS OF GENERIC DOWNLOAD WITH REQUEST ................. 62
FIGURE 17: GENERAL INFORMATION ABOUT THE PORT ......................................... 63
FIGURE 18: ECDIS UPDATE ............................................................................................... 64
FIGURE 19: FLOWCHARTS OF GENERIC DOWNLOAD WITHOUT REQUEST ......... 65
FIGURE 20: ACCESS TO TOURIST INFORMATION ....................................................... 65
FIGURE 21: FLOWCHARTS OF BROADCAST AND GENERIC INCOMING
    COMMUNICATIONS .................................................................................................... 66
FIGURE 22: WEATHER FORECASTS ................................................................................ 67
FIGURE 23: BI-DIRECTIONAL COMMUNICATIONS ..................................................... 68
FIGURE 24: FLOWCHART GENERIC VOICE CALL ........................................................ 69
FIGURE 25: SHORE BASED PILOTAGE ............................................................................ 70
FIGURE 26: FLOWCHART WEB ACCESS ......................................................................... 71
FIGURE 27: FLOWCHART SECURED PAYMENTS ......................................................... 72
FIGURE 28: FLOWCHARTS: SECURED PAYMENTS ...................................................... 73
FIGURE 29: TYPES OF COMMUNICATIONS ................................................................... 74
FIGURE 30: SYSTEM ACCESS RELATED SUB-FUNCTIONS ........................................ 74
FIGURE 31: BEARER MANAGEMENT RELATED SUB-FUNCTIONS .......................... 75
FIGURE 32: NETWORK MONITORING RELATED SUB-FUNCTIONS ......................... 75
FIGURE 33: QOS MANAGEMENT RELATED SUB-FUNCTIONS .................................. 76
FIGURE 34: STORE AND FORWARD RELATED SUB-FUNCTIONS ............................. 76
FIGURE 35: SERVICE RELATED SUB-FUNCTIONS ....................................................... 77
FIGURE 36: NON IP MANAGEMENT RELATED SUB-FUNCTIONS ............................. 77
FIGURE 37: TYPES OF IP COMMUNICATIONS ............................................................... 78
FIGURE 38: BEARER PROCESS ......................................................................................... 88
FIGURE 39E-R – REQUEST, ESTABLISHMENT, AND USE OF CONNECTION
         104
FIGURE 40E-R                    –                      USERS                             AND                           GROUPS
         105


TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                                                   Page 12
COMMAN / D4.1 Functional Specifications

FIGURE 41E-R         -         BEARER                         AVAILIBILITY                              FORECAST
        106
FIGURE 42E-R             -                        TRANSMISSION                                          FORECAST
        107
FIGURE 43E-R           -                  COMMUNICATION                                           ACCOUNTING
        108
FIGURE 44: E-R – COMMAN DELIVERY REQUIREMENT .......................................... 109
FIGURE 45 : LEVEL OF SECURITY IN THE COMMAN SYSTEM ............................... 113
FIGURE 46: INFORMATION EXCHANGED DURING OUTGOING CALLS ................ 150
FIGURE 47: INFORMATION EXCHANGED DURING INCOMING CALLS ................ 151
FIGURE    48:    INFORMATION           EXCHANGED                      DURING                BI-DIRECTIONAL
    COMMUNICATIONS .................................................................................................. 151




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                                        Page 13
COMMAN / D4.1 Functional Specifications




Executive summary

This document has been produced thanks to the work provided during the overall work
package 4 by all the partners involved. It deals with the Functional Specifications of the
COMMAN system. Consequently, this document provides the description of the features that
will be supplied by the COMMAN system. The aim of this document is to provide a precise
description of the service that will be provided by the Single Data Node and more generally to
describe how all the system will work.

COMMAN has adopted an evolutionary approach for the development process. To achieve
this there are strong links between the Functional Specification, System Architecture and
Demonstrator Development packages. Therefore this document may need to be revised as
those activities complete.

This document is composed of three main sections:
First, an overview of the service and of the system is detailed. Indeed, so as to specify a
system, we have tried to identify very precisely the needs of the potential users. The solution
adopted has been to identify all the communication tasks that could be likely to be supported
by the COMMAN system. Then, those requirements have a direct impact on the system;
that‟s why the applications dedicated to the communication tasks have been identified and the
high-level architecture of the system has been deducted.
Then, the functionalities are explicated according to two levels of description. The first is
dedicated to the description of the processes that are supported by the system so as to
undertake the communication tasks. The second focuses on the communications themselves.
For this second point, sub-functions that undertake a specific part of the communication
support are identified and all the communication types are detailed as sequences of those sub-
functions.
To finish, the last main part deals with the communication management that is the core of the
service provided by the COMMAN system. All the sub-functions linked to management are
detailed to describe their internal working. The COMMAN database is detailed on this
occasion.


The results of this work package can be hardly listed because it covers different aspects and
deal with specific contexts at each time. Nevertheless, we can provide a first approach of the
results included in this document.

   Technically speaking, COMMAN is a router with a management software. COMMAN
    offers a management of IP communications and allows non IP communications to access
    to bearers. This management of IP communications is the core of COMMAN
   First, we have identified most of the casual communication tasks.
   Thanks to the identification of the communication tasks, we have concluded that most of
    the communication needs could be satisfied with data applications, so without the use of
    voice.
   The applications that have been chosen to support the communication are the following:
    E-Mail with attachments, WWW: Internet / Intranet browser capabilities, Telnet, Quality
    of Service/Type of Service, FTP, Whiteboarding, Netmeeting: Video conference via the
    available (depending on system configuration) high speed communication channels, IRC
    (Internet Relay Chat), Still Imagery, Remote Database Access: Access to Value Added
    Port Services and port Intranet Access to passenger/ traveller information systems, AIS,
    Video Imagery, Fax, Positional Information.

TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                Page 14
COMMAN / D4.1 Functional Specifications

   Those applications can be sorted according to 3 criterions: if the generate IP traffic or not,
    if they support incoming or outgoing communications, if they support online or offline
    communications.
   The architecture of the system that is likely to support the services contains three different
    logical layers. The first deals with user access (e.g. for message preparation: compose the
    message, determine all the parameters, negotiate QoS), the second deals with the schedule
    of the communications and the third is devoted to the connection issues.

   Concerning the processes supported by the COMMAN system, we have identified and
    described 3 different types of communication tasks that take place in the same way for
    each category: the incoming/outgoing calls, IP/non IP services, and online/offline
    communications.
   More precisely, concerning the communication support, several sub-functions have been
    identified that can be listed here but the important point is that they cover two different
    topics: the data transmission (format data, data transfer) and the communication
    management (the connections management, the scheduling management and the
    attribution of parameters to the communication management). It is important to notice
    that most of them deal with communication management.
   Concerning the database, its use is very important and it will contain a lot of information.
    We can here identify the different categories of data that will be stored: messages related
    data (messages sent, received, time of sending,…), the management data that deal mainly
    with system access management (connections historic, events log, etc…) and with bearers
    management (cost schedules, bearers configuration, etc…) and the general data that are
    data directly usable for the communications (ETA, load maps, etc…).




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                   Page 15
COMMAN / D4.1 Functional Specifications



1 - Introduction: Aim of WP4

The aim of WP4 is to specify the services offered by the Single Data Node developed during
the COMMAN project. What has been done during this work package is a precise description
of the services and of the functionalities of the system. The main objective of this work
package is to give a complete picture of the working of the system.

WP4 gives a high level solution to the needs of the users. This work package is mostly
independent of advanced technical choices; no technical detailed specifications will be
provided in this deliverable. The focus is to describe how the system will work to support the
communication management.


Before going further, it is important to define more clearly the links and the differences
between the other work packages that are closely linked to WP4:

   WP3 (User Requirements Study) has as main objective to collect the user needs and to
    take into account their suggestions.

   WP4 (Functional Specifications) gives a high level solution to the needs of the users. The
    service provided is defined at this stage.

   WP5 (System Architecture) aims at defining a physical and technical architecture
    compatible and suitable to the specified services.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                Page 16
COMMAN / D4.1 Functional Specifications



2 - The COMMAN system : presentation and objectives

2.1       Presentation of the COMMAN system

COMMAN stands for COMmunication MANager. The COMMAN system is an on board
communication management system which provides navigators with a “single point access”
to all communication services. In other words, all the bearers (VHF, satellite, GSM…) will be
accessed through the same platform, which will support fax, e-mail and other IP
communications.

Thanks to its integration of all existing bearers, this platform will manage the transmission
and the reception of all1 the communications between a ship and the shore. Thus it will allow
a better and centralised management of the communication and information services (phone,
fax, mail, internet etc…).

The “Single Data Node” (SDN) will offer functionality that will be integrated seamlessly into
the on board ISC network and the system can act as a gateway between ship-borne networks
(except safety critical ones such as GMDSS) and the external world. Therefore, the
COMMAN system will offer ashore users a single entry for remote login at ship‟s internal
network.


Technically speaking, COMMAN is a router with a management software. This management
application is the core of COMMAN. COMMAN offers a management of IP communications
and allows non-IP communications to access to bearers.
The Internet Protocol (IP) is the method or protocol by which data is divided in packets and
sent from one computer to another on the Internet. IP communications use software
applications like E-Mail, Internet/Intranet access, FTP, Telnet, Whiteboarding, Video
Teleconferencing (VTC), Internet Relay Chat (IRC), Still Imagery, Remote Database
Access, Window sharing , Remote control. Non-IP communications can be Video Imagery,
AIS, Positional Information, Voice



2.2       Target market

The COMMAN system can be installed on every kind of ship but is targeted on medium and
big commercial ships such as freighters and ferries.
Vessels greater than 500GRT displacement were selected for attention because they will carry
a greater range of communication equipment and thus have a more demanding performance
requirement for a communication server.




1
    Except safety critical communications which are undertaken through GMDSS.

TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                               Page 17
COMMAN / D4.1 Functional Specifications

2.3       The present situation

As far as telecommunication management is concerned the present situation can be described
this way:
 The wide variety of carriers, protocols, equipment and procedures results in extensive
     workload to navigators no longer supported by radio officers (by the introduction of
     GMDSS radio officers have largely been made redundant).
 There is a real danger that navigators performing communications as concurrent
     secondary tasks to their watchkeeping role, are unnecessarily distracted and may make
     them unable to fulfil their tasks.
 Although existing and emerging technologies may be used for developing an integrated
     maritime communication system, there is a need for faster communication systems to
     realise the full potential of telematic services that can be offered.



2.4       COMMAN features

2.4.1.         Main features
Here are summarised seven main functionalities that will be provided by the COMMAN
Single Data Node :

1. Access to all available bearers.

2. Support of all the communication services and applications.

3. Readiness for integration of emerging and future technologies, and will help dealing
   with and exploit the expected drastic increase of maritime data communications from
   radio transponders, DGPS correction service, ECDIS data bases and updating, remote
   login into shipborne automation system for diagnosis and maintenance and multi-media
   applications.

4. Management and Optimisation of the communication emission with QoS criteria’s.

5. Integration with ship-borne networks, with network security mechanisms.

6. Multi-users system with system access management capacities, that will be accessible
   to all clients connected to the on board networks (ISC network and administrative
   networks).

7. Tools for monitoring and management of communications expenses.




2.4.2.        Likely impact of the COMMAN system
To give a first general overview of the benefits of the use of the COMMAN system, we have
here listed some of the most important impacts that they could have:

     Communications management will be improved:
       Error rates, congestion and delay problems imposed by current communications will
        be kept to a minimum. Reliability and availability of communications will be
        increased.
       Reduction of communication management workload

TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                            Page 18
COMMAN / D4.1 Functional Specifications


     Communication costs will be reduced thanks to:
       Least cost routing, i.e. the selection at each moment of the cheapest available bearer.
       Queuing messages according to off-peak rate hours and to their urgency.
       A more relevant use of the different communication services. For instance, thanks to
        the simplification of the interface, e-mail will be used rather than fax which costs
        more.
        At the level of a shipping company, the savings will be drastic.

     Efficiency will be improved:
       The access to all communication services including the vessels' internal flow of
          documents, is made easier and quicker. The flow of documentation between ship and
          shore will be improved.
       The administrative load of on-board personnel will be reduced.
       Fleet management will be improved.

     Benefits on communication services will increase :
       On ferries, liners and other ships transporting passengers, the volume of commercial
         communications will increase drastically thanks to the possibility of offering
         improved communication services to the passengers, such as credit card phone boxes
         and office facilities (telecommunication tools for distant working).


For instance, the COMMAN system will enable the use of the following applications,
that will also be demonstrated at the end of the project:

     E-mail
     Access and transfer of Weather, Hydrographic and Ship Movement Information - ECDIS
      on line updates.
     Exchange of information in accordance to the requirements of ISM code.
     Computer Supported Co-operative Network application.
     Position Polling application.
     COMMAN management application.



2.5       Main functionalities of the COMMAN system

2.5.1.         The COMMAN system will allow connection to the following bearers

The COMMAN system will provide an access to different types of telecommunication
networks like terrestrial networks, third generation networks as well as satellites systems.
Following, you will find a non exhaustive list of the different bearers that could be available
through the COMMAN Single Data Node in the future.

     Terrestrial Networks: VHF, GSM, DECT, TETRA.
     Third Generation Systems, still under developments: IMT 2000, UMTS.
     Satellites Systems:
       Fixed satellite services: Eutelsat
       Broadband GEOs: Spaceway, Cyberstar
       Narrow band GEOs: Inmarsat
       Big LEOs: Iridium
       Little LEOs: E-SAT, OrbComm
       Etc…

TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                 Page 19
COMMAN / D4.1 Functional Specifications




2.5.2.       COMMAN System Services

The COMMAN System provides IP access to and from the ship. I.e. the following IP-services
will be available for use through the COMMAN SDN:

   E-Mail with attachments
   WWW: Internet / Intranet browser capabilities
   Telnet
   Service availability forecast presentation FTP
   Whiteboarding
   Netmeeting: Video conference via the available (depending on system configuration) high
    speed communication channels
   IRC (Internet Relay Chat)
   Still Imagery
   Remote Database Access: Access to Value Added Port Services and port Intranet Access
    to passenger/ traveller information systems
   Quality of Service/Type of Service (COMMAN Delivery Requirements – CDR)
    specification for the above


NON-IP services include:

   Voice
   Fax
   AIS
   Positional Information
   Video Imagery




2.5.3.       COMMAN Management Services

To finish, we have listed, so as to give a more precise idea of the service provided, some
general features that will benefit the users of the COMMAN system. Following, to be more
concrete, we will present some “real-life” situations illustrating the functionalities of the
services.


   Easy configuration
   “Seamless roaming” among available carriers
   Network management: resources and diagnostic tools
   Network security: authorisation and protection mechanisms for validation of messages
   Least cost routing
   Prioritise calls : Upload mail in accordance with urgency requirements
   Download mail in accordance with urgency and cost criteria
   Establish call QoS/CDR demands : Urgency, Volume, Timeliness, Privacy,
    Authentication, Integrity
   Estimate cost before the call.


TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                               Page 20
COMMAN / D4.1 Functional Specifications

   Monitor the communications, keep an event log registering date, time, duration, volume
    (and cost) of all the incoming or outgoing communications.
   Receive time, own ship position, course and speed data from onboard sensors
   Login procedure with password allowing personal accounts and personal authorisations
    for access to specific functions of the COMMAN system


2.5.4.       COMMAN concept of usage concerning IP Communications

COMMAN Summary
COMMAN will provide an integrated ship-borne system that will automatically route and
   schedule outgoing communications and route incoming communications to the
   appropriate destinations.

COMMAN Fundamental User Requirements:
1. COMMAN should provide the link between the on-board networks and the ship‟s
   external communications
2. COMMAN should be scaleable, flexible and configurable to meet a wide range of needs
3. Support IP and Non-IP connectivity
4. Non-IP Connectivity
   a) Only support non-GMDSS connectivity
   b) Manage connectivity to bearers
   c) Record usage of bearers
   d) Non-IP connectivity is not further considered in this document
 IP Connectivity
   a) Connect IP users/networks afloat to IP users/networks ashore
   b) Enable the same network based functionality as if ashore (subject to cost and
       availability of communications)
   c) Provide cost-effective connectivity
   d) Provide real-time and S&F connectivity
   e) Provide users with charge options prior to connection/submission
   f) Record usage and cost information

Assumptions:
1. This section covers the concept of usage for the data (IP-based) services.
2. COMMAN will (eventually) manage all of a ship‟s non-safety-related communications
   (non-GMDSS)
3. The user needs may be summarised as wanting Internet (or Intranet) connectivity and
   facilities from afloat using the most cost-effective communications connectivity.
4. The majority of end user functionality will be provided by the networked computers that
   are not part of COMMAN (i.e. standard applications)
5. The only direct user of the COMMAN SDN will be the System Manager/Administrator.
6. The basic COMMAN (afloat) capability may be exploited ashore where intermittent
   communications are required.
7. Companies will have different operational philosophies.
8. Users can be human or applications


High level network connectivity
1. Onboard networks are likely to support administrative and integrated ship control (ISC)
   functionality
2. Onboard network to parent company intranet ashore
    Ship becomes part of corporate intranet (via any bearer)
    Internet/ISP (e.g. web) access can be obtained through corporate connectivity


TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                            Page 21
COMMAN / D4.1 Functional Specifications

      Email would be routed through company server
      Security may/may not rely on corporate protection
      Connection can be established from ship or shore
3.   Onboard network direct to an ISP
      Connectivity to ISP via any suitable bearer
      Email might (depending on company size/policy) be via ISP
      Connectivity only established from ship
4.   Onboard network to other intranets (e.g.              port area network, VTMIS Net,
     Supplier/maintainer support company networks)
      Service to be used (e.g. email, web, TELNET) need to be established
      The ability to dial into the ship, will need specific security measures
      The ability to pass data shore-ship, when connection has been established ship/shore
        may need to be constrained
      Security measures need to be identified
      Firewall onboard?
      Authentication measures
      Connectivity established from ships and shore?
      ……..
5.   Permanent or dialup connection depending on company policy
6.   Onboard network security options (e.g. virus scanning, firewall functionality)
7.   Other ?

Charging Measures
 Charging regime should depend on company policy
    General charging options
        None
        Record costs only for future audit/allocation
        Ask user for agreement having offered options
        Depends on company policy
    Passengers
        Free as part of ticket for passengers
        Direct payment by credit card or onto cabin bill
        Minimise ship‟s staff involvement
        Detailed range of send options (CDRs)
    Staff
        No charge
        Sent according to priority within appropriate time limit
        Charged
        Depends on company policy

Connectivity Establishment
1. Real-time
    Support full (?) range of interactive application
    Establish type of application to be used and proposed costed bearer options
    Ask user to select quality of service (effectively data rate)
    Connect without question on receipt of a request
    Support S&F in background
2. Non-Real-time (S&F email only)
    Queue mails and send on routine (e.g. 2 hourly) basis
    Queue mails and send at next cheapest time in next (e.g.) 2 hours)
    Shore dials up on routine basis to check for mail
    Sent mails according to fully costed user selection (CDR)

TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                             Page 22
COMMAN / D4.1 Functional Specifications

        Send emails on cheapest bearer within next n hours depending on priority
        Company policy needs to drive this, flexible approach
        Needs to be able to be sent as background traffic when interactive services being used

Value added services that can be supported (examples only)
1. Bearers supporting simultaneous users
2. Automatic zipping of attachments
3. Size limitation of attachments (complex rules are possible)
4. Data compression over bearers (particularly useful for non-email traffic)
5. Proxy servers
6. Authentication
7. Information (data) sent from users to onboard or ashore fax line (e.g. send to fax)
8. Web data caching
9. Filling up of unused connection time when billing period is long (e.g. per minute) or
    when minimum charge applies.
10. Virus protection, user terminal and/or at access point



2.5.5.        Real life use of the COMMAN system

Here are described 4 real life situations of the COMMAN system.

                        Real Life uses of the COMMAN system (1)

Reports on the operational state of the vessels: In the case of a collision between two
vessels, those reports are sent back to the Incident Room and remote diagnostic checks carried
out where necessary. These reports are also sent to the vessel owners/agents.


                        Real Life uses of the COMMAN system (2)

Payment at the onboard shop: On most liners/ferries, onboard shopping is provided with
many passengers paying by credit/debit card. During each transaction, the credit status of the
customer can be checked to validate the transaction..


                        Real Life uses of the COMMAN system (3)

ECDIS update: The captain, so as to navigate in a more secure way, uses ECDIS charts. As
every week, he connects the COMMAN Single Data Node to its company‟s server and
requests for a download to update those charts. Since this transfer is very expensive, the
download is executed when the cost of the communication is lower (during the night for
instance).

                        Real Life uses of the COMMAN system (4)

Remote diagnostic: After a collision between a ferry and a cargo caused by poor navigation
judgement combined with a steering problem in the cargo vessel, reports on the operational
state of the vessels are sent back to the Incident Room and remote diagnostic checks carried
out where necessary thanks to the COMMAN system. These reports are also sent to the vessel
owners/agents.


TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                 Page 23
COMMAN / D4.1 Functional Specifications



3 - Methodology and Framework

3.1        Introduction

We have tried to adopt a structured approach to define a proper way to organise the
elaboration of the functional specifications.
The methodology is a three steps process:

     First of all, all the user level communication tasks are identified and the working of the
      system, so as to undertake the communication tasks, is described and specified. A first
      draft of the functional specifications is produced at this stage.

     Then, two scenarios, covering the largest number of cases, are proposed to potential users.
      Their comments about the services offered and about the working of the system are
      recorded.

     This feedback from potential users is compared to the first draft of the deliverable and this
      draft is improved thanks to those new comments and ideas.



                                                   WP3
                                                                      User Requirements




                                              Feedback
                                             (Scenarios)
                                                                WP4




                                                                   Functional Specifications
        Functional Specifications
                                                                            Draft
              Final Version


             Figure 1: Methodology of the Functional Specifications Work Package




The previous sketch shows the way the work has been lead during this Work Package. The
use of feedback is really necessary because deviations can occur between the user
requirements capture and the first draft of the functional specifications. That‟s why a feedback
is necessary, in order to be sure that what will be specified is really what the users need. This
phase is vital because from this point, all the development will be done without any feedback
from users. So, this starting point has to be in harmony with the needs of users.



TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                    Page 24
COMMAN / D4.1 Functional Specifications

3.2       Detailed presentation of WP4

3.2.1.         Overview


In this part, we will try to define more precisely what has been done during this work
package.

     First of all, a list of tasks is extracted mainly from D3.1.
     For each task, an application is affected and the general working of the system to
      undertake this task will be shown
     Then, a sequence of sub-functions describes each type of communication. Those sub-
      functions realise elementary functions useful for the execution of the task. It is necessary
      to divide the tasks into generic sub-functions because most of them are reused frequently.
     To finish, the sub-functions are detailed so as to describe precisely how they will work.




                  High-level
                 Description                               Communication Task



                                                          Identificatio
                                                                            Applications
                                                                n
                                                                               Voice
                                                           Choice of
                                                         the Network

                       Structured                                              E-mail
                                                           Begining
                        flows of
                                                           of the call
                      information
                                                         Managemen
                                                         t of the call          Fax

                                                              Etc
                                                              ...
                                                                               Video



                                                          Parameter
                                                              s




                                    Figure 2: Steps of the Specifications




The previous sketch shows the hierarchy of the division of each task into sub-functions, with
all the corresponding parameters and the application(s) devoted. The sub-functions will also
be detailed in order to specify all the flows of information. Those data exchanges will be
similar to high-level protocols.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                     Page 25
COMMAN / D4.1 Functional Specifications

3.2.2.        Work breakdown

The work to be done has been divided into phases in order to adopt the most structured
approach to work. The first phases describe the functionalities from the users view (user-
centred approach) and then the required features of the system, so as to support the
communication needs, will be highlighted (system-centred approach).



3.2.2.1.            Phase 1

The aim of the User Requirements study was to give a precise and global overview of all the
requirements of the users; what is needed here is to refine this study to specify all the
communication tasks that will be supported by the COMMAN system.

The focus of this phase is on the communication tasks that the COMMAN system will have to
support. This step comes within the scope of the user-centred approach.


   First of all, we try to have an overview of the different types of tasks that are carried out
    in the ships. This is really important for several reasons :
          We have to extract information from D3.1 and from interviews already done; this
             overview gives us a first idea of how to sort those tasks.
          We have to provide new interviews of experts in the maritime field to catch
             complementary information that should had been caught during WP3 so as to
             refine the user needs study.

   Then, the information already produced in other documents are extracted. The work will
    be based on the D3.1 and on the minutes of the interviews already done during WP3.

   Several interviews with different specialists of the maritime field will be lead so as to
    finalise the list of communication tasks already produced.

   To finish, and in parallel with the previous steps, a list of available applications will be
    provided based on D3.1. Those applications will have to support the communication tasks
    already identified.



3.2.2.2.            Phase 2

This phase is the key point dedicated to linking the user-centred process and the system-
centred process. Here, we try to define several types of communication that will be
undertaken in the same way by the system and link them to the communication tasks
previously identified.

Indeed, it is necessary to differentiate the general working of the system from the
communication management.


   First, the objective is to give a functional description of the working of the system to
    undertake the tasks listed during the phase 1 of WP4. This first step mainly provides a
    comprehensive picture of the working of the system. On this high level view, we describe


TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                  Page 26
COMMAN / D4.1 Functional Specifications

    the working of the system, how the tasks are undertaken by the system, with several
    options, and the general features of the system.

   Then, we focus more precisely on the system developed and try to provide a very first
    approach of the description of the communication management itself. To achieve this
    objective, we have to try to define a list of sub-functions that support the management of
    all the flows of the incoming and outgoing data.



3.2.2.3.           Phase 3

This phase is the core of the system-centred approach. During this phase, we mainly have to
describe how the communications will be supported by the system. To do so, we have to
describe each type of communication identified previously as a sequence of the sub-functions
already listed in phase 2.

   First, our focus is to link the user-centred approach to the system-centred approach.
    Consequently, for each communication task identified during phase 1, we make it
    correspond to a type of communication defined in the previous phase. This step is
    important since it will enable to trace the usefulness of the proposed features.

   Then, the sending and receiving of information itself are described as a sequence of sub-
    functions defined during phase 2.

   To finish, the management aspect is detailed at this stage. After having studied how the
    communications will be managed, we deduct some requirements for the system itself to
    support the communications. This step is consequently close to the system architecture.



3.2.2.4.           Phase 4

The purpose here is to give the definition of the internal working of the system. We have
chosen a hierarchical division of the work in order to be more efficient. For the moment, we
have described the general working of the system to take in charge the execution of the tasks
(phase 2) and the phase 3 has provided a “macro-view” of the working of the system
describing which functionality will be required to support the different types of
communication.

The goal of WP4 is to define precisely all the exchanges of information supported by the
COMMAN system. So, it means that we mainly have to describe the exchanges of data for
each sub-function and to define them like high-level protocols or algorithms.



3.2.2.5.           Phase 5

This phase is essential because it provides a feedback necessary to improve the first draft of
the deliverable. It will be the last opportunity to have the feedback from users concerning the
specification.

We have prepared 2 scenarios; each scenario covers very different situations. The scenarios
have to present a wide range of situations. For each situation, the corresponding functionality
of COMMAN will be highlighted.

TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                Page 27
COMMAN / D4.1 Functional Specifications


The scenarios are submitted to specialists of the field (users) that give their feedback about
the functionality provided and specified. Their comments and opinion are a huge source of
inputs to optimise the functionality proposed and to produce a final draft of D4.1.


                  The main terms used in the description of COMMAN


COMMAN’s functionalities help crew members to better manage communication tasks.
Functions and features are elementary capabilities that allow COMMAN to offer such
functionalities.

Communication tasks: Tasks undertaken on a ship that imply a communication with the
shore or with another ship. Nowadays they are often performed with current means (fax,
voice…), but COMMAN can have an impact on the way they are undertaken.

Functionality: The capabilities or behaviours of a program, part of a program or system, seen
as the sum of its features. Roughly, "the things it can do".

Feature: An elementary characteristic. We generally use the term “feature” to design a
capability of COMMAN that, contrary to sub-functions, doesn‟t intervene in the sending or
receiving of a communication.

Function and sub-functions: A capability that intervenes in the undertaking of a
communication. “Function” and “sub-function” can be used indifferently, but we use the term
sub-function when we want to insist on the fact that it is an elementary bit used to decompose
the way COMMAN handles communications.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                Page 28
COMMAN / D4.1 Functional Specifications



4 - Overview of the communication tasks

To have a comprehensive and complete picture of the system, a deep knowledge of the user
needs is necessary so as to then supply the adequate services.
Consequently, we will first identify all the relevant user needs, concerning the use of the
system itself.


4.1      Requirements

4.1.1.        General needs

Nowadays, the total number of the crews are always decreasing and consequently, the
workload supported by each member of the staff is always higher. That‟s why a the
communication procedures relief is highly desired by the users.

The need of an onboard telecommunication platform is also more and more pressing because
most of the modern applications rely on telecommunication means. For instance, the use of
ECDIS charts, being an alternative to paper charts, implies a regular update that will be
additional requirement for bandwidth; the use of the AIS also requires additional bandwidth.
Other systems will not need so much bandwidth but will need very frequent access to the
bearers. An example can be the ship tracking systems. A communication manager is expected
by the users to manage all these different types of communication and to facilitate the
communication management, to access easily with curbed costs to a wide range of bearers, to
access to broadband services and to support modern applications.

Moreover, as a consequence of communications, the volume of information exchanged is
dependent of the number of cargo items itself. Since the capacity of the ships are growing (in
1990, the largest ships had a capacity of 1600 containers, in 2000, the largest one will be able
to transport 4600 containers), the volume of this communication is increasing rapidly.


The generic service that is required by users is a platform supporting and managing all the
flows of information from ship to shore or from shore to ship; the support of communication
from ship to other ships is also requested.

To summarise, the service that will be expected by users is that the COMMAN Single Data
Node will support all the communication tasks that are nowadays executed manually and to
support future usage. The benefits are both a simplification of the communication processes,
reducing the workload of the crew, and a better control of the telecommunication costs. This
last parameter is perhaps the most important one, from the point of view of the maritime
companies. The CMA (Compagnie Maritime d‟Affrêtement, the 4th largest container transport
company in Europe) spends 5 million dollars every year for the communications from their
ships to shore of its turnover of 8 billion dollars. The telecommunication costs are in fact one
consequent charge that is expected to be reduced.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                 Page 29
COMMAN / D4.1 Functional Specifications

4.1.2.       Communication tasks

4.1.2.1.           Categories

Several categories of communication tasks have been identified. Some of them are related to
the different phases of a travel. The others are related to the shipping husbandry. To finish,
the lasts are related to distant survey and distant operations. Here are listed the different
categories that have been identified :


Passage: covering pilotage and navigation, safety:
    When mooring
    Before leaving port
    At departure
    In narrow waters
    In deep water
    Reaching port
    Warning
    Emergencies
    Urgent messages
    Supervision


Shipping husbandry and operations: covering engineering, planning and operation:
    Ship operation
    Cargo handling


Shipping husbandry and operations: covering administration and support services:
    Ship operation
    Communication with authorities


Miscellaneous: covering comfort services, passenger services and other:
    Ship operation
    Cargo handling
    Other




4.1.2.2.           Task list

This task list has been produced thanks to the User Requirements Work Package and thanks
to the first phase of the Functional Specifications Work Package. The different tasks listed
here are communication tasks that are under the responsibility of the crew or that implicate
the crew. Consequently, those communications can be incoming calls (from the shore to the
ship) or outgoing calls (from the ship to the shore).

Following is listed the tasks list sorted according to the different types of communication:
concerning pilotage, concerning engineering, planning and operation, concerning
administration and support services and concerning miscellaneous communications.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                Page 30
COMMAN / D4.1 Functional Specifications


Passage: covering pilotage and navigation, safety
When mooring

Declare entrance into the VTS area: To inform the VTS of the entrance of the ship in its
surveillance area; most of time, ships know when they enter in a new VTS area (maps of the
VTS area exist). So, when they enter a new area, they declare the entrance. The
communicators of this outgoing call are: Captain, VTS, Pilot.

Weather forecasts: Those information are provided by meteorological offices and other
weather authorities, NAVTEX, etc,… A good knowledge of the weather is important for safe
manoeuvring, safe ship handling and passage, provision for safe cargo stowage. The
communicators of this incoming call are : Shipping company, Ship. The weather forecasts can
be received following a request or not.

Traffic maps: Those map are used to give the state of the traffic in a special area. The
communicators of this incoming call are: (for overlay on an ECDIS) SDN, VTS to provide
traffic map data, pilots , Ship. The traffic maps are generally received following a request.

Sending the ETA: To communicate the ETA to the port of next call which is very helpful for
the management of the port of arrival. The communicators of this outgoing call are: Master,
Port.

Make ECDIS update: The use of ECDIS charts requires very frequent updates to allow the
captain to rely on those charts. The communicators of this incoming call are: Officer of the
watch or captain, Local HO. This update is generally done following a request.

Before leaving port

Sending the ETD: To prepare all functions or activities to be executed for departure. The
communicators of this outgoing call are : Ship captain, Agent.

Send sailing plan: The agent, receives from the ship, and sends the sailing plan to the
harbours which will be reached next and makes any necessary arrangements. The
communicators of this outgoing call are: Ship captain, agent.

At departure

Shore based pilotage: Those communications aim at improving the safety of navigation
while entering / leaving the port. The communicators of this bi-directional communication
are: Harbourmaster, Captain.

In narrow waters

Shore based radar assistance: Those communications aim at improving the safety of
navigation. The communicators of this bi-directional communication are : Officer of the
watch or captain.

In deep water

AMVER reporting: This reporting is mandatory so as to localise the ships on different areas.
The communicators of this outgoing call are: Master, AMVER.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                               Page 31
COMMAN / D4.1 Functional Specifications

Get real-time position information from vessels: The aim is to track the vessel. The
communicators of this outgoing call are: VTS, Owner, Chatterer. The position from the
vessels can be received following a request or not.

Ship-ship communication: Agree on passing manoeuvre, collision avoidance. The
communicators bi-directional communication are: Officer of the watch or captain, Officer of
the watch or captain.

Ice patrol reports: Mandatory reports on severe sea conditions and ice conditions, safe
navigation of vessel. The communicators of this outgoing call are: Master, Local
organisations for ice patrol reports, HO's, Coast Guard.


Reaching port

Shore based pilotage: Those communications aim at improving the safety of navigation
while entering / leaving the port. The communicators of this bi-directional communication
are: Harbourmaster, Captain.

Announce hazardous goods: This communication is useful for the preparation for
emergencies connected with transport as well as unloading/discharging and storing hazardous
goods. Main goal is to protect environment and own vessel and crew. The communicators of
this outgoing call are: Master, Harbour police.

Announce arrival: To prepare all functions to be executed when arrived. The communicators
of this outgoing call are: Captain, harbourmaster, agent, customs, immigration, various other.

General information about the port: To provide information about the port before the
arrival. The communicators of this incoming call are: Port, Ship.

Port entry guide: Guide the ship during the approach and berthing manoeuvre, improve safe
navigation of the vessel while approaching and berthing. The communicators of this bi-
directional communication are : (pilot who performs the approach of a port and the berthing
of a vessel), Local pilot, Port agent, Captain.


Warning

Ice messages: To inform the other ships, via the ice patrol, that there is ice in certain area (it
only reflects one observation). Support of safe navigation of vessel. The communicators of
this mandatory outgoing call are : Captain, ice patrol.

Ice warnings: Safe navigation of vessel. The communicators of this incoming call are:
Officer of the watch, Local HO.


Emergencies

Mayday/PAN/medical Service: Restore a safe situation for people, vessels, environment in
distress or in danger. Minimise damage. The communicators of this bi-directional
communication are: Masters of vessels affected, masters of assisting vessels, On Scene Co-
ordinator, SAR Centre, Land based medical service, SAR vessels, Airborne SAR, other
aeroplanes within reach.



TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                   Page 32
COMMAN / D4.1 Functional Specifications

Fire fighting, safety: Restore a safe situation for people, vessels, environment in distress or
in danger, minimise damage. The communicators of this bi-directional communication are:
Master, Fire-fighting crew on board, Assisting other vessel, other vessels in vicinity, SAR,
VTS.

SAR: Restore a safe situation for people, vessels, environment in distress or in danger.
Minimise damage. The communicators of this bi-directional communication are: Master,
Assisting other vessel, other vessels in vicinity, SAR, VTS, appropriate authorities.

Reporting acts of piracy: Restore a safe situation for people, vessels, environment in distress
or in danger, minimise damage. The communicators of this bi-directional communication are:
Master, appropriate authorities, nearby ships.


Urgent messages

Safety messages (drifting containers, switched lighthouse,…): Support safety of
navigation. The communicators of this outgoing call are : Captain, other ships, Coast Radio
Station, NAVTEX, VTS.


Supervision

Ship tracking: To inform the maritime company of the position and of the speed of the ships.
The communicators of this outgoing call are: SDN, Maritime Company. The position can be
sent following a request or not.

Distant survey: To provide a remote survey to prevent from piracy, damages, etc … The
communicators of this outgoing call are: SDN, Maritime Company. The survey can be
executed following a request or not.



Shipping husbandry and operations: covering engineering, planning
and operation
Ship operation

Logistics machine: Order of mechanical parts to have the parts necessary at the next call. The
communicators of this outgoing call are: Mechanical staff onboard, on shore fitting-out
engineer.

Remote maintenance: Fault diagnosis and maintenance. The communicators of this bi-
directional communication are: Ship, manufacturer.

Remote Damage Survey: Evaluate the importance of damages (for insurance, possibly). The
communicators of this bi-directional communication are: Captain, Company technician.

Logistics husbandry, supplies acquire supplies and spare parts needed: Management of
the ship. The communicators of this outgoing call are : Ship, Supplier.

Message to the agent: Messages related to fuel & bunker, sludge discharge, garbage ship,
ordering of boats, tugs, ordering of linesmen. The communicators of this outgoing call are:
Captain, Agent.

TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                Page 33
COMMAN / D4.1 Functional Specifications


Remote Surveillance of Safety Critical Operations: Supervise safety critical operations,
record manoeuvres for insurance or fault diagnosis. The communicators of this bi-directional
communication are: Captain, Company technician.

Import/ Export of ISM code relevant messages or forms: Comply to ISM rules, increase
safety of navigation and environment: Master, shipping company, Coast Guard, other proper
authorities.


Cargo handling

Cargo handling, loading, discharging: Transmission of loading plans and plans of
hazardous goods, cargo manifest. The communicators of this outgoing call are: Ship,
Agent/shipping company.

Cargo management: Get cargo in time to the correct destination. The communicators are:
Agent, Shipping Company, Master.

Slop discharge: Services for slop discharge and cleaning Getting a clean cargo hold in-time
to increase economy. The communicators of this outgoing call are : Vessel.

Garbage-cargo handling: Services for handling and cleaning garbage from cargo Getting a
clean cargo hold in-time to increase economy. The communicators of this outgoing call are:
Vessel, agent.

Sending of load maps: To reduce the time of unloading in the port. The communicators of
this outgoing call are: Captain, Port.



Shipping husbandry and operations: covering administration and
support services

Ship operation

People management for cleaning and laundry: To provide the service. The communicators
are : Hotel trade staff, Suppliers.

Catering for crew and passengers: To be supplied at the next call. The communicators are :
Hotel trade staff, Suppliers, agent.


Communication with authorities

Customs: Provision of customs lists, cargo lists. The communicators are : Vessel, customs
station.
Communication with coast guard: Comply to local authorities and regulations. The
communicators are : vessel, coast guard.

Immigration authority: Send crew lists in advance, via agent and embassy to immigration.
The communicators are : vessel, Immigration, agent or shipping company.



TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                              Page 34
COMMAN / D4.1 Functional Specifications

Agriculture authority: Send information regarding vermin, rodents, rats etc. The
communicators are : vessel, agriculture.

Medical authority: Inspect vessel and crew regarding clean bill of health to prevent
infectious diseases ashore. The communicators are : vessel, medical officer of port.

Sending of the list of crew, the licences, the vaccination list and the passport numbers:
To reduce the wait of the crew in the ship after the arrival. The communicators are : Captain,
Port (via the agent).



Miscellaneous: covering comfort services, passenger services and
other
Ship operation

Distant learning and general education: Distant learning and general education.
Additionally training courses regarding ISM code (that will soon become mandatory). The
communicators are : vessel, training authority.

Entertainment: At present e.g. rent videos, create board journal using radio messages. The
communicators are : Crew, other vessels, land-based newspapers.

Medical service: Provide basic medical services on-board. The communicators are : land
based medical service, master, ships doctor.

Cargo handling

Secured payments: To check the bank account before the payment. The communicators are:
SDN, Bank.

Phone boxes: To phone during the travel. The communicators are : Passengers, Ashore…

Medical assistance: This functionality will provide medical advice but not remote diagnosis.
The communicators are : Captain or onboard doctor, Hospital specialised in remote medical
assistance.

Office facilities: To give at the disposal of the passengers, telecommunication tools for
distant working for example. The communicators are: Passengers, Ashore…

Access to tourist information: Ashore databases (tourist office) provide tourist information
for passenger and crew as service. The communicators are: SDN.

Entertainment: Provide tourist entertainment for passenger and crew as service. The
communicators are: Passengers, Ashore…

Medical service: This functionality will provide medical advice but not remote diagnosis.
The communicators are: Captain or onboard doctor, Hospital specialised in remote medical
assistance.

Virtual Round Tables: business passengers or crewmembers. Provide access to video
conferencing.


TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                Page 35
COMMAN / D4.1 Functional Specifications


Other

Personal Communications: Talking. The communicators are :Crew, Relatives.

Money order: Order money to pay the crew in cash. The communicators are : Captain,
Agent.




4.2       View of the system

4.2.1.         Position

Technically speaking, COMMAN is a router with a management software. This management
application is the core of COMMAN. COMMAN offers a management of IP communications
and allows non IP communications to access to bearers.
The Internet Protocol (IP) is the method or protocol by which data is sent from one computer
to another on the Internet by dividing them into packets. A more descriptive definition is
provided in the glossary in annex.

To support the communication tasks previously described, the system will have to provide
several features considering also generic technical solutions. Our focus is not to provide an
overall description of the technical constraints with which the COMMAN Single Data Node
will have to cope, but first to try to evaluate the generic high-level constraints of the
communication handling. Of course, this will include obvious remarks but it will help us to
border our study.

In fact, the use of communication applications have a direct impact on the system itself.
That‟s why we will try to define coherent categories that include all the communication types
(dependant from the communication applications) that will be all treated in a specific way by
the system.

     The system will need to enable ship-shore, shore-ship and ship-ship connectivity. The
      majority of the services will require bi-directional (see later comment on duplex/half-
      duplex etc) communications – IP cannot generally be supported by one-way
      communications.
     First, the system will have to enable communication both ways: from ship to shore as well
      as from shore to ship. Access control will be provided to control incoming and outgoing
      calls (prioritisation, authorisation) but the COMMAN system will have to provide this
      two-way connectivity.

     Secondly, it is well known that IP applications are more and more frequent and the
      Internet Protocol is becoming a standard in all the world for a large range of application.
      So, the COMMAN system will have to support mainly IP information exchange as well
      as non-IP information exchange. This first categorisation is essential since those two
      types of information flows will not be managed in the same way.

     Some applications will require on-line connection while others will require off-line
      connection. The on-line connections will be requested by applications that need bi-
      directional communications and especially, real-time connections. WWW access is an
      example. On the other hand, other applications require off-line connections; this is


TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                  Page 36
COMMAN / D4.1 Functional Specifications

    generally the case for store-and-forward systems such as email. The message, except if it
    is urgent, is composed and stored; it will be sent later according to specific requirements.




4.2.2.        Available applications

As we have seen in the previous paragraph, the use of specific communication applications
have a direct impact on the system itself. That‟s why we will list them so as to evaluate all the
applications that are available for the COMMAN Single Data Node. For the list, we have kept
our fundamental categorisation that sort the different types of application considering if they
generate IP traffic or non-IP traffic.


4.2.2.1.            Application generating IP traffic

All the applications that are listed here are applications related to the “Internet world”. Their
use is logical in the specific case of maritime communications since those communications
involve ashore communicators that use those standards. Moreover, the Internet Protocol is
becoming a de facto standard, so it is natural that most of the communication applications that
will be proposed by the COMMAN system are applications generating IP traffic. To finish,
we must also keep in mind that most of those applications will be used in both way : from the
ship to the shore and from the shore to the ship.

Here are the applications generating IP traffic :

   E-Mail: This is the most common tool used that will support attachment. It is used for
    messaging since it is a store-and-forward application. According to the users, it is the
    most suitable and flexible tool.

   Internet/Intranet access: Those types of access will be more and more used in the future
    especially because a lot of information will be available on the Web and because most of
    the maritime companies are developing their own Intranet. In this case, security issues
    will have to be taken into account. It is obviously an on-line application.

   FTP: The use of FTP will be casual so as to download files. This can occur for the update
    of ECDIS charts that would be requested by the ship in the sea to a server ashore. It is an
    on-line application.

   Telnet: Telnet is an underlying TCP/IP protocol for accessing remote computers.

   Whiteboarding: This application will be a useful for distant working and distant repairing.
    It is an on-line application.

   Video Teleconferencing (VTC): This capability will be a useful for distant working and
    distant repairing but also for distant diagnosis for sick or injured persons. It is an on-line
    application whose capabilities will be dependant on the available bandwidth.

   Internet Relay Chat (IRC): IRC will be used for casual chat that does not require image or
    sound. Consequently, it will be dedicated to non-safety critical communications. It is an
    on-line application.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                   Page 37
COMMAN / D4.1 Functional Specifications

   Still Imagery: Still imagery will be mainly used for medical issues and sometimes for
    distant repair. This application will be off-line.

   Remote Database Access: This type of access will be very developed so as to enable the
    access to databases located on the COMMAN server or ashore. It is an on-line
    application.
    This is not necessarily an application - remote access would use an application like telnet.

   Remote control: Remote control will be used by the company‟s engineers to remotely
    configure the COMMAN system.



4.2.2.2.            Application generating non-IP traffic

Concerning non-IP communications, they are less numerous for two reasons. As said before,
IP is a very developed standard and secondly, the COMMAN Single Data Node concerns
only data communication; as a consequence, it is natural that IP is the core of the information
flows.


Here are the applications generating non-IP traffic:

   Video Imagery: It is required for medical purpose only. It is an on-line application.

   AIS: This system will be more and more used since it enable a localisation and an
    identification of the surrounding ships; it provides a richer information than a radar echo.
    AIS will not in itself generate IP traffic, however the IP network may be used to support
    its operation e.g. as a controls station, as a source of data for the short message service (if
    one exists).

   Positional Information: This information can be necessary for ship tracking. It is reported
    at regular intervals. It is an off-line application.

   Voice, via VHF or telephone.

   Fax, via telephone



4.2.2.3.            Mapping of the different applications with the different types of
                    communication tasks

Before going further, it is important to check one last time that the communication
applications previously listed will be able to support the communication tasks that were
expressed by the user needs. This step is necessary to trace that what will be specified is really
coherent with the user expectations since the choice of the communication applications has an
impact on the service specification and on the system architecture.


This moment is a key point that will link the user-centred approach and the system-centred
approach. It is really important to be sure that the users expectations are really taken into
account at this stage.



TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                    Page 38
COMMAN / D4.1 Functional Specifications



WP 3                                WP 4                                 WP 5               WP 6

            User-centred process

                                   System-centred process



                      Mapping of the applications
                      with the communication tasks


    Figure 3: Link between the User-centred approach and the System-centred approach


According to the previous scheme, this stage is mandatory for the following of the project.
This step goes in fact within the scope of the Quality Management of the Functional
Specifications. To achieve this objective, we have to check for each communication tasks,
whether one of the previously quoted applications are applicable or not.

To give a more concise presentation of this checking, we will determine for each application,
all the communication tasks that could be supported.


     Application                             Communication tasks supported
E-mail                        Declare entrance into VTS area
                              Sending the ETA
                              Sending the ETD
                              AMVER reporting
                              Ice patrol reports
                              Announce hazardous goods
                              Ice messages – ice warnings
                              Safety messages
                              Logistics machine
                              Import / export of ISM code relevant messages or forms
                              Message to the agent
                              Cargo handling, loading, discharging
                              Cargo management
                              Slop discharge
                              Garbage-cargo handling
                              Sending of load maps
                              People management for cleaning and laundry
                              Catering for crew and passengers
                              Customs
                              Immigration authority – Agriculture authority – Medical
                               authority
                              Sending of the list of crew, the licences, the vaccination list and
                               the passport numbers
Internet/Intranet access      Weather forecasts
                              General information about the port
                              Phone boxes (voice over IP)
                              Access to tourist information

TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                 Page 39
COMMAN / D4.1 Functional Specifications

                            Office facilities
                            Entertainment
Telnet                      Traffic maps
                            Weather information (specialised bulletin boards)
                            Make ECDIS update
                            Send sailing plan
                            General information about the port
                            Logistics husbandry, supplies and spare parts needed
                            Secured payments
FTP                         Traffic maps
                            Make ECDIS update
Whiteboarding               Shore based pilotage
                            Shore based radar assistance
                            Port entry guide
                            Remote maintenance
                            Virtual round tables
Netmeeting                  Fire fighting, safety
                            SAR
                            Reporting act of piracy
                            Distant survey
                            Remote damage survey
                            Remote surveillance of safety critical operations
                            Distant learning and general education
IRC                         Ship-ship communication
                            Communication with coast guards
Still imagery               Remote damage survey
                            Reporting act of piracy
                            Medical service
                            Medical assistance
Remote Database access      Send sailing plan
                            General information about the port
                            Logistics husbandry, supplies and spare parts needed
                            Secured payments
AIS                         Get real time position from vessels
                            Ship tracking
Video imagery               Remote damage survey
                            Reporting act of piracy
                            Medical service
                            Medical assistance
                            Fire fighting, safety
                            SAR
                            Distant survey
                            Remote surveillance of safety critical operations
                            Distant learning and general education
Remote control              Any configuration operation of the COMMAN system
Voice, Fax                  Import/ Export of ISM code relevant messages or forms
                            Customs
                            Medical service
                            Shore based pilotage
                            Shore based radar assistance
                            Port entry guide
                            Ship-ship communication
                            Phone boxes
                            Personal Communications

TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                           Page 40
COMMAN / D4.1 Functional Specifications

                               Remote maintenance
                               Declare entrance into the VTS area
                               Announce hazardous goods
                               Distant survey
                               Remote Damage Survey
                               Remote Surveillance of Safety Critical Operations
                               Ice patrol reports
                               Sending the ETA
                               Sending the ETD
                               AMVER reporting
                               Cargo management
                               Access to tourist information
                               Announce arrival
                               Message to the agent
                               Ice messages
                               Ice warnings
                               Mayday/PAN/medical Service
                               Fire fighting, safety
Positional information         Get real time position from vessels
                               Ship tracking

            Figure 4: Matching of the communication tasks with the applications

The previous table gives a solution (not the only one) showing that all the communication
tasks identified can be properly supported by the applications listed. For the rest of this
document we will therefore only need to discuss the identified communication services.




4.2.3.        Characterisation of the different types of traffic

As seen before, each communication task is supported by a specific application. Each
application generates a specific type of traffic. It is interesting to characterise with a high-
level description each type of traffic that are categorised according several criterions : IP-
traffic, non-IP traffic, off-line communication, on-line communication, incoming call,
outgoing call.

Given the eight groups of communication tasks of the system the all important services in
view of the COMMAN SDN is covered.



4.2.3.1.           Off-line IP from ship

This group is supported at the user level via an email server, which performs the store and
forward functionality. The user interface is an off the shelf email program supporting Internet
email. E.g. MS outlook, Eudora etc. The user is connected to this server on the onboard LAN.
The user parameters are set by his profile and by priority in the email application. From the
administration point of view the mail schedule may look like a list of handled and unhanded
messages. The user may get feedback from the system when the message has left the ship e.g.
by an email message.



TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                 Page 41
COMMAN / D4.1 Functional Specifications




4.2.3.2.            Online IP from ship

This service may be supported in the way MS supports dialup connections. The user gives the
system a request for an IP connection and a via a dialog box where the user can specify the
parameters for this connection. When making the connection the SDN will first try to find an
existing connection if this exist. If there are existing connections the SDN must check the
QoS parameters and verify that this connection request may use the active connection without
violating the existing agreement on the connection. If no existing connections may be used
the SDN will try to open a new connection if this is possible or give the user a connection
reject. A user with appropriate rights may also set the connection priority to disconnect other
calls.
During the connection period, the user uses off the shelf software to communicate. E.g. MS
Internet Explorer, Telnet, Real-audio, MS net meeting etc.
When disconnecting the SDN will end the connection over the bearer if it is not used by other
users.



4.2.3.3.            Off-line non-IP from ship

A fax sending from a user workstation will be defined as an offline service if it is sent through
a message handler. From the user point of view the users uses off the shelf software to write
the message, and sends the message in the same way as when printing to a network printer.
When printing a dialog box will prompt the user for the parameters and information that is
necessary to send the message. The message is then stored in the message server and
scheduled there. The message will then be sent in accordance with the parameters for this
message e.g. priority, least cost routing etc.
The administration of this service will be similar to the administration of the (email) Off-line
IP from ship service.

4.2.3.4.            Online non-IP from ship

Online non-IP services will in the user point of view be making a call from an ordinary
telephone. The difference may be the kind of authentication of the user ID. Normally these
connections are not possible via the computer user terminals (later this may be solved using
voice over IP). Traditional fax is also defined in this category.



4.2.3.5.            Off-line IP to ship

Typically email messages are sent to a user onboard. The SDN must poll the ashore email
system to check if there are any new mails. There may be constraints regulating when to
check and which emails to download in conformance with e.g. priority and least cost routing.
The user uses off the shelf email software and may check his mail account when he logs on
next time, or when logged on, by polling the onboard mail server in the SDN. The
administration system may poll the ashore system after a manual request.


4.2.3.6.            Online IP to ship

An example is a dialup connection to the ship. In this case external users dial the ships dialup
number and connects in the same way as in a MS Windows dialup connection. After the

TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                  Page 42
COMMAN / D4.1 Functional Specifications

connection set-up including authentication of the user, the user may connect to the onboard
systems via IP. The access rights must be regulated by a user profile.


4.2.3.7.           Off-line non-IP to ship

From the ship, fax was an example of services defined in the non-IP category. To the ship a
fax must also be handled as an online service. The fax messages may however be stored in a
message server. When using an ashore fax server, downloading fax messages after a request
from the SDN this may still be defined as an offline service.


4.2.3.8.           Online non-IP to ship

Voice and fax services are covered by this category. Voice services are as in the old system:
A call is received and the phone is ringing. Fax handling can be routed directly to a fax
machine, or stored in the SDN and printed on request. Automatic delivery of fax to the users
will not be supported, so all faxes is handled by some predefined users with access to the fax
administration system. The functionality of this may be similar as receiving an email.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                Page 43
COMMAN / D4.1 Functional Specifications



5 - Functionalities of the COMMAN system

5.1        Functional architecture of the system


5.1.1.           Presentation

The COMMAN Single Data Node is the link point between the onboard clients and the
available bearers for communication. Consequently, we can list the following elements that
constitute the Single Data Node:

               The server itself that will drive the exchanges of data between the ship and the
                exterior.
               The bearer interface that format data to the bearer standards.
               The onboard LAN that is generally an IP network; this part is outside of the
                boundaries of the COMMAN System.
               The non-IP module that will have a specific access to the bearer interface since
                that traffic cannot be supported by the onboard LAN.
               The Human-Machine Interface through which the service will be presented to the
                users.


      COMMAN SDN



      COMAN                                                                                  Bearer
       Server                                                                              Interfaces
      COMAN
       Server




                             IP
                          Network


      Client                                                                               Non-IP
      HCIs




                  Figure 5: Main components of the COMMAN Single Data Node



TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                  Page 44
COMMAN / D4.1 Functional Specifications


The previous scheme gives a useful global view of the main components of the COMMAN
SDN high-level physical and communication architecture.




5.1.2.           High Level Functional and Communication Architecture

A preliminary Functional and Communication Architecture is shown in the following figure
with the purpose of illustrating how functionalities are distributed in the COMMAN System.
As mentioned: the purpose is to illustrate functionalities, actual implementation may vary!
E.g. the routing functionality required per bearer may be implemented in one physical unit
with several bearer interfaces.


                                                                                        Bearer
         Services                                                         Bearer Bearer
          (e-mail,       COMMAN Scheduler,
           video-         Mail Server, User                                                  LIU and
           conf.,           Agents etc.                                  LIU and LIU and Filtering
                                                                         Filtering Filtering
         telnet,...)
                                                          COMMAN
                                                         Firewall and
                "internal" IP network                                    "external" IP network
                                                            Router
                                                         Functionality


                                        Firewall X
            Firewall A


                                                     X network


                             A network




    Figure 6               COMMAN High Level Functional and Communication Architecture




5.1.3.           High-level architecture

So as to give a first presentation of the high-level architecture of the COMMAN system, we
have to evaluate all the types of traffic that the system will support. To achieve this, a
categorisation is necessary. The categorisation uses three dimensions:

   Outgoing (from ship) / incoming (to ship),
   Offline / Online and
   IP / Non-IP.

The following diagram defines three main application classes on the user level:
            Messaging Clients - Applications that prepare a message, document or similar
            and may send these at some suitable time. E.g. e-mail clients, standard
            applications with the ability to "send" a document, etc.



TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                                 Page 45
COMMAN / D4.1 Functional Specifications

              Online Clients - Applications that require direct connection to the "destination",
              e.g.
              COMMAN Administrative Clients - Administration of users of the COMMAN
              system (access to functionalities, bearers, priority levels, etc.), administration of
              COMMAN transmission policy (bearer cost and availability profiles, bearer
              access, etc.)

On the intermediate level we define three main function classes:
            COMMAN "Scheduler" - facilities to prepare messages or direct connections
            for transmission at appropriate/required time.
            COMMAN Connection database - facilities to keep track of the
            communication status, bearer availability/status, etc.
            COMMAN Administrative database - (see COMMAN Adm. Clients above)

At the "lowest" level we have a single function:
             COMMAN Connection Handler - which performs the actual transmission via
             the selected bearer. (Detecting in-, and out-going transmission requests and
             performing these.)




           Work Station


                                         COMMAN (IP)
      User              COMMAN
    Application         User agent                         COMMAN
                                                             HMI




                          IP Store
                                                                                      Control
                             and              COMMAN
                           forward            controller                              Information
                           service




                          IP Online
                           service
                                                                             Bearer



                                                   COMMAN
                                                    bearer
                                                    handler




                          Figure 7: COMMAN high-level architecture




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                    Page 46
COMMAN / D4.1 Functional Specifications

COMMAN SDN Functionality Layers:

We have found it convenient to separate the functionalities of the COMMAN SDN in three
logical layers: User, Service/Scheduler and Service/Connection.
The following diagram gives examples of functionalities found in the different layers.




                                             User Level
                             COTS Appl.            COMMAN HCI Appl.
                               e-mail client,       COMMAN Service Dialog
                            desktop appl./print,    (e.g. Message Attribute Client),
                                    ....                          .....



                                 Service/Scheduler Level
                                            functions to
                                   request connection category,
                                       schedule connection,
                           get/set connection atributes (QoS attr. etc.),
                                                .....


                               Service/Connection Level
                                           functions to
                          detect outgoing and incoming communication,
                                    and establish connections,
                                                .....




                              Figure 8: COMMAN logical layers




This scheme presents in a condensed manner the different types of actions that are necessary
to handle a communication:
 To compose the message and to determine the parameters (including QoS parameters).
 To time when and how the message will be sent or the connection opened.
 To manage the connection to enable the sending of data.


We assume that communications can be predicted based on planned sailing route, estimated
bearer coverage areas, bearer cost profiles etc. A change in the sailing route will change these
predictions and have a direct impact on scheduled communications.
Similarly, higher prioritised communications (whether message or direct) will potentially
delay some other communications.
When such a change occurs users, whose scheduled communications are affected, will receive
a message to be able to reschedule their planned communications.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                 Page 47
COMMAN / D4.1 Functional Specifications

Relevant COTS (Common Off The Shelf) software applications providing necessary services
for COMMAN are:

     e-mail clients like MS Outlook, Eudora, Pegasus Mail etc. for composing, sending and
      receiving messages
     video/voice communication clients like MS NetMeeting for low-quality video/voice
      “meetings”,
     IRC – Internet Relay Chat clients like Netscape AOL Instant Messenger, Mirabilis ICQ
      and as included in MS NetMeeting for online textual communication
     FTP (file transfer protocol) clients like WS-ftp from Ipswitch, Inc., Marathon FTP from
      NCD for general file download and upload
     WWW clients like MS Internet Explorer, Netscape Communicator, Opera from Opera
      Software for internet/intranet/extranet browsing and information retrieval
     whiteboarding clients as included in MS NetMeeting for shared drawing/sketching
      (often used in combination with video/voice and IRC type communication)

All these software applications / services will be used “as is” by the COMMAN “end users”
(ship crew, passengers etc.). The user will not experience any difference in behaviour except
that on an attempt to utilise these services he may be informed by the COMMAN system that
the requested service is available with a given set of COMMAN Delivery Requirements
(CDRs) or not available. In both cases it may be possible for the user to adjust the CDRs
(depending of the users profile and rights) to achieve different communication conditions.
E.g. after sending an e-mail the user will be presented for the possible bearers available for
future delivery of his message, where he may also adjust parameters like maximum delivery
cost, latest delivery time, preferred bearer etc. (via a Message Attribute Client).

The COMMAN HCI Applications include the aforementioned Message Attribute Client
(CDR client) and a Communication Availability Forecasting Client which enables users to
examine expected availability and cost of using relevant communication bearers during the
predicted course and time. End users will also be able to reserve time-slots for future use of
high bandwidth online communications (IP or non-IP) like video/voice communication.
Administrative tasks performed by the COMMAN system operator allows defining users and
their profiles including rights and priorities for communicating via the COMMAN SDN.




5.2       User Level features of the COMMAN system

The management application concerning IP communications is the core of COMMAN.
The 3 main functionalities that will be provided are the connection management, the timing
management (scheduling) and the message edition management.

All this will be detailed now, taking into account that those features have to be detailed
because they include sub-functionalities.


5.2.1.         The COMMAN SDN Access

All users of the COMMAN SDN must be registered in the COMMAN User Database. Each
user shall have a set of rights allowing the user to perform functions in the COMMAN SDN.

We distinguish between:
   1. System Administrator (with access to all administrative and technical functionalities)

TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                Page 48
COMMAN / D4.1 Functional Specifications

     2. User (with access to administrative and technical functionalities as configured by the
        System Administrator).

            Technical Functionalities:
Logon User to COMMAN SDN
Logoff User
Present Users Technical Rights
Present Users Administrative Rights
Present Users Allowed Message Addressees
Present Message Attributes (outgoing and incoming messages)

             Administrative Functionalities:
Create User (requires executing user to be System Administrator or a user which has been
given the necessary administrative rights)
Modify Technical Rights of a User
Modify Administrative Rights of a User
Modify set of Allowed Message Addressees for a User
Modify Users Maximum Message Attribute values
Create Communication Bearer
Modify Communication Bearer Transmission Attributes

The COMMAN services will be provided in several languages.



5.2.2.        Compose, Send and receive Message

Compose and send message : Message Contents are stored (in a Message Server) until
sending. Message Attributes are stored (in a COMMAN Message Server) until sending.

The general model is that of a COMMAN Message Scheduler which based on COMMAN
Delivery Attributes (or delivery requirements) selects the Messages with Message Attribute
values satisfying the current COMMAN Delivery Attribute values.
To create, modify and send a Message the User must have access to the following Functions2
via a Message Client and/or a Message Attribute Client:

    Create Message.
    Edit Message Content.
    Include attachment
    Set Message Attributes.
    Store Message.
    Fetch Message.
    Submit Message.

The user may, depending of the e-mail client, be able to choose whether or not his message
needs acknowledgement receipt. (Acknowledgment receipt is generally client dependent –
applies for both sender and receiver). The COMMAN Message Server will be able to provide
acknowledgement receipts if desired. This could be part of the user profile (for outgoing
message Ack. request) and in the COMMAN Address Book (for incoming messages from
selected external addresses).



2
    This Functional Specification does NOT decide how functionality is split between a
    traditional Message Client and a Message Attribute Client.

TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                Page 49
COMMAN / D4.1 Functional Specifications

The system will allow secure exchange of data, including data encryption. This functionality
will not be part of the COMMAN SDN as such but must be handled via third party services
like TeameWares TWISS or DataFellows Ltd.s F-Secure SSH for secure communication,
and Pretty Good Privacy Inc.s PGP for message and document encryption.
The system will have available the identification number of coast stations so as to enable the
communication with the appropriate cost station as quickly as possible.


There will be a COMMAN Address Book that will be manageable by the administrator of the
system and also remotely manageable. The use of this address book (which will not include
personal addresses) is a good solution to prevent the use of the system for personal calls. The
only calls permitted will be those which will be addressed to receivers included in the address
book. To make a personal call, the user will have to specify it to the system, so as to access to
an address or a number not stored in the system. All personal calls will be identified and
invoiced to the corresponding users.



Receive Message: In the case of an incoming e-mail message the user will see no difference
between a message origination externally and onboard. The users standard Messaging Client
will provide the necessary functionality.
(In the case of a message delivered by e.g. onboard fax there will equally be no difference in
reception functionality.)
We assume that possible COMMAN message attributes for received messages can be
presented via the COMMAN SDN Access functionality.


5.2.3.        COMMAN Delivery Requirements (CDR)

As quoted before, rather than talking about QoS that generally refers to IP (and especially v6)
features, we define for the COMMAN System a slightly different concept: The COMMAN
Delivery Requirements (CDR).

The attribution of those parameters rests on the fact that we are able to predict, according to
the COMMAN database and to the sailing plan, at each moment in the future, the bearers that
will be available; this database could be created thanks to tracking coverage on a number of
trips. This database (detailing coverage areas) will always be updated because the system will
check, every hour for example, which bearers are available. Thanks to the GPS positioning,
the result will be compared to the data stored and the necessary updates will be done.

Those requirements will define how and when a message will be sent or when a connection
will be opened. To do so, we have to separate those parameters according to the types of
communication: online or offline. In any case, the user will choose those parameters.

To finish, in case of necessity, the COMMAN SDN Administrator will have the opportunity
to ask for an immediate message sending or an immediate connection opening. In this
situation, the planed messages or connections will be delayed and all the users concerned will
receive a warning from the system. As said before, the same process will be followed if the
vessel‟s route changes and impacts the scheduling of the communications.



5.2.3.1.            CDR for offline communications



TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                  Page 50
COMMAN / D4.1 Functional Specifications

Typically, those parameters will have to be defined for email sending or for any message
sending. The user after having composed his message will define the parameters.

   First, he will define the maximum call cost.
   Secondly, he will determine the deadline for delivering the message.
   Then, he will sort, according to his needs, the bearers that could support the
    communication. It will only be possible to choose among the bearers that could support
    the communication before the deadline with a lower cost than the maximum cost defined.
    For each bearer, the time of delivery and the cost of the communication will be
    calculated.
   To finish, some parameters concerning system access management will have to be
    defined. For instance, the name and password of the user will have to be filled in.



5.2.3.2.           CDR for online communications

The aim is now to access directly to a bearer to open a connection for e.g. a VTC session. In
the best case, the connection will be opened immediately; otherwise, the user will book a
window for his use of the connection.

   First, he will define which parameter will be the restricting parameter: cost or bandwidth.
   Secondly, according to the first information, the user will determine the maximum call
    cost per minute or the minimum bandwidth available.
   Thirdly, he will determine the deadline for the opening of the connection and the duration
    of the connection.
   Then, he will sort, according to his want, the bearers that could support the
    communication. It will only be possible to choose among the bearers that could support
    the communication before the deadline according to the conditions defined (cost or
    bandwidth). For each bearer, the time of availability, the cost of the communication and
    the bandwidth will be calculated.
   To finish, some parameters concerning system access management will have to be
    defined. For instance, the name and password of the user will have to be filled in.




5.2.4.        Configuration and Maintenance of the system

   The system may have to be partially reconfigured before each departure and on each
    change of crew. – this can be significantly reduced by the use of titles (e.g. Chief
    Engineer) rather than names.
   User profiles should be defined and should only be changed by the administrator of the
    system.
   Network security will have to be defined: authorisation and protection mechanisms,
    validation of messages.

The COMMAN system has to store general information that will be frequently and repeatedly
transmitted: ship, cargo, crew and journey identification. The choice has not been made yet
whether this information has to be stored by the server itself or by the services which use the
server. In any case, this information has to be shared between the “off the shelf” applications.
The structure of the information concerning the handling of the communication and the
management of the system will be tackled in the next chapter, which deals more with internal
and technical aspects of the system.


TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                 Page 51
COMMAN / D4.1 Functional Specifications


Automatic updates for every software and database may be performed under the control of the
administrator.
A backup capability should be provided. Thus, backups of the system can be executed
regularly.




5.2.5.           Miscellaneous

The Single Data Node developed during COMMAN project will not include GMDSS distress
functionality (D3.1, page 90).
 Self positioning every one hour in deep water, every 20 minutes near the coasts and every
    5 minutes in specific cases, through an end-user application.




5.2.6.           Current issues
The assessment through user‟s feedback has allowed to identify areas of extra functionality
needing to be refined or developed. However, some decisions concerning these functionalities
haven‟t been taken yet, and will be taken as development allows us to know more precisely
what is feasible or not.


5.2.6.1.       Functionalities to add or refine
1. Bearer management: additional functionality is required to fully cover likely situations.
    These are:
         - Non-Availability   of bearers;
         - System   hysteresis when in difficult, changing reception environments;


2. There is also a need to consider bearer management and scheduling in response to need
   rather than just cost.
3. Scheduling management: Additional functionality is needed to take account of
   opportunistic connections to satisfy least cost sending (for example when crossing into an
   area of GSM reception, taking advantage and sending the stored email rather than waiting
   for the next scheduled connection time when it would cost more) and utilising a constraint
   based approach to re-schedule the queued calls without bothering all users and enabling a
   more flexible transmission policy.
    These two areas relate to general COMMAN CDR and QoS requirements where concern
    is expressed about:
             -    Practicality of users specifying maximum transmission cost;
             -    Individual users selecting bearers to send email, rather than a scheduled
                  service
    The assessment has highlighted that system usage and task policies need to be further
    refined before any more functionality short falls can be positively identified.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                               Page 52
COMMAN / D4.1 Functional Specifications

5.2.6.2.             Interfaces issues
4. On a liner, the main source of data is the company‟s server. It also can be the Internet
    access of the ship. 2 to 4 times a day, a connection is established between the ship and the
    server at off peak rate and all the data stored, including e-mail, is sent. The ship also
    retrieves all the data that the company (different departments of the company) has placed
    on the server in a dedicated folder.
    This shows the need to further define the automation capacities of the COMMAN system
    (linked to store and forward) and their articulation with the automation capacities of
    COTS applications. A browser or any client application, can be programmed to
    accomplish this task of automatic retrieval. How will it deal with COMMAN‟s constraints
    (access to bearers denied) ? Is it possible to refine the communication between these
    applications and COMMAN in order to avoid repeated error messages ?


5. Passengers have telephones in their cabin. However all the outgoing calls are made
   through the radio operator. COMMAN can improve the operator‟s work and help to
   provide the customers with a better service. In the long term, thanks to cost estimation for
   instance, COMMAN can help to provide additional services to the customers. The user
   interface must lighten the work of intermediary of the radio operator, if not allow
   customers a direct access to communication services. The definition of the interface of
   COMMAN and the PBX needs to be refined.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                 Page 53
COMMAN / D4.1 Functional Specifications


5.3       The processes supported by the COMMAN system


In this part we will examine which processes are supported by the system to undertake a
communication task in its entirety, and then, in the next part, which sub-functions the system
must undertake to the communications themselves.

Indeed, two levels can be identified:

     First, the communication tasks are entire processes that include the sending or the
      reception of communications or messages.
     Secondly, the communications themselves that consists in exchanging (sending,
      receiving) information.

To synthesise the entire processes that describe the development of communication tasks, we
will use flowcharts that will be shown below. To decompose the communications themselves,
we will use sub-functions that will target on the communication handling. Those sub-
functions will be detailed later. Our focus here is to adopt a more general point of view.


The processes described here show how the COMMAN system will be used by the end-users.
We have defined several types of procedures by filing the tasks which are similar regarding
the use of the COMMAN system. Each task listed in the task list corresponds to one of these
three types of use of the COMMAN system.

These procedures are summarised in the following table :

       Type of         Characteristic                  Sub-categories (non exclusive)
      procedures           of the
                        information
                            flow
      Outgoing            Simplex           With request       Without request           Routine
    communication
      Incoming             Simplex        Download and       Download without       Broadcast and
    communication                          receive with          request           generic incoming
                                              request                              communications
     Bi-directional      Half or Full     Currently voice        Online
    communications         duplex                             communications

          Figure 9: The different types of processes undertaking communication tasks


Note : The link in general cannot be simplex – simplex means one way. IP communications
(barring possibly UDP) require two way communications. The information flow may be one
way (e.g. email) but the bearer must be two way. There is only a limited range of simplex
(data) communications, NAVTEX may be one, met fax broadcasts and commercial TV are
others.

These categories seem to roughly overlap the IP/non-IP, In/Out, online/offline distinctions
which are technical descriptions of the communication. But these categories describe more
how the COMMAN system takes place in the daily communication tasks performed on a ship


TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                 Page 54
COMMAN / D4.1 Functional Specifications

than how it technically handles the communication. The flowcharts and the examples
provided here show the interactions between the system and the user.




5.3.1.        Outgoing communications
5.3.1.1.          List of tasks

Here are the tasks that can be filed in the “outgoing communication” category.
“On request” means that these tasks are performed on request of an external actor (generally
ashore).“Ad hoc” means that these tasks can be performed when the crew finds it suitable.
“Routine” means that these tasks must be performed regularly or require certain conditions
(schedule, availability of information) to be performed.

Note: It is not excluded that a task could be performed with request and without request.
However, in most cases, it is probable that the request and response will be separate activities.
Therefore the distinction is academic.

             Outgoing communication                   On request         Ad hoc        Routine
Ship tracking                                             X                X
Declare entrance into the VTS area                        X                X
Announce hazardous goods                                  X                X
Distant survey                                            X
Remote Damage Survey                                      X
Remote Surveillance of Safety Critical Operations         X
Ice patrol reports                                                          X              X
Sending the ETA                                                             X              X
Sending the ETD                                                             X              X
Send sailing plan                                                           X              X
Sending of load maps plan                                                   X              X
AMVER reporting                                                             X              X
Cargo handling, loading, discharging                                        X              X
Cargo management                                                            X              X
Slop discharge                                                              X              X
Garbage-cargo handling                                                      X              X
Access to tourist information                                               X
Announce arrival                                                            X
Logistics machine                                                           X
Logistics husbandry, supplies                                               X
Message to the agent                                                        X
Money order                                                                 X
Catering for crew and passengers                                            X
Immigration authority                                                       X
Agriculture authority                                                       X
Medical authority                                                           X
Sending of the list of crew, the licences, …                                X
Office facilities                                                           X
Ice messages                                                                X
Ice warnings                                                                X
Mayday/PAN/medical Service                                                  X
Fire fighting, safety                                                       X

TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                  Page 55
COMMAN / D4.1 Functional Specifications

            Outgoing communication                   On request        Ad hoc       Routine
SAR                                                                       X
Get real-time position information from vessels                           X

                                 Figure 10: Outgoing calls




5.3.1.2.           Flowchart: Outgoing communication with and without request

Concerning the flowcharts, there is no significant difference between an outgoing
communication with or without request. The only difference lies in the fact that before the
emission of data, the ship has received a request through voice, fax, telex, or e-mail…, so we
won‟t differentiate both cases here.
Nevertheless, this will have an impact on the routine communication because their execution
will be driven by the request reception.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                               Page 56
COMMAN / D4.1 Functional Specifications

GENERAL CASE




                                                 Data sending
                                                 w ith/w ithout
                                                    request




                                                 Request reception




                                              Beginning of the sending
                                                      process




                                                  Scession opening




                                                   Selection of the
                                                    service (fax,
                                                    mail, telex...)
                                                                           With request
                           Without request




                                             Composition of the messag e




                                                      Setting of
                                                     parameters




                                                      Sending




                                                      Archiving




                   Figure 11: Flowchart of the generic outgoing call




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                    Page 57
COMMAN / D4.1 Functional Specifications

EXAMPLE: SEND THE ETD
                                          Send the
                                            ETD




                                             Login




                                        Selection of the
                                          serv ice (f ax,
                                         email, telex...)




                                  Composition of the message :
                                   ETA, next port of call, ETD




                                          Setting of
                                          parmeters




                                           Sending




                                           Archiv ing




                                  Figure 12: Send the ETD




5.3.1.3.           Flowchart: Routine Outgoing communication

The most important specificity of routine outgoing communication is that because these
communication tasks are regular or depend only on the availability of certain data, they can be

TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                Page 58
COMMAN / D4.1 Functional Specifications

partly automated. In fact, two levels of automation can be defined. On the one hand, the
process can run on the system and an alarm is activated each time communication needs to be
carried out; then the communication itself is carried out by the user. On the other hand, all the
process is automated, including the communication itself.

GENERAL CASE


                                              Routine data se nding




                                                            no
                                      time or data
                                        condition
                                        f ullf illed ?




                                           y es




                                    automated task
                                                                 Y es
                                          ?




                                            no

                                         Alarm




                                    Selection of the
                                     serv ice (f ax,
                                     mail, telex...)




                                                                   Automated composition of
                               Composition of the message
                                                                        the message




                                                                         Automated
                                       Setting of
                                                                          setting of
                                      parameters
                                                                         parameters




                                        Sending




                                       Archiv ing




                  Figure 13: Flowchart of the routine generic outgoing call




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                        Page 59
COMMAN / D4.1 Functional Specifications

EXAMPLE: SENDING THE ETA

                                                Task: se nding the ETA at se a



                                                             Departure of the ship




                                                                 Is the journey
                                                                supposed to last
                                                               more than 48H00?



                                                                                               y es
                                                                       y es


                                                                                                 No
                                               no                   48 hours
                                                                  or less bef ore
                                                                       the                                       ETA more
                                                                      ETA ?                                     than 2 day s
                                                                                                                  ahead ?

                                                                       Y es


                                                               First ETA sending
                                                          See ETA sending detailed procedure
                                                                                                            ETA amendment
                                                                                                      See ETA sending detailed procedure
                                                                                                                                           no


                                                                      Any
                                   y es, a signif icant            signif icant            y es, a signif icant
                                       adv ance                     delay or                     delay
                                                                   adv ance ?



                ETA amendment
          See ETA sending detailed procedure
                                                                        no



                                                                                               no

                                                                 6 hours or less
                                                                  bef ore ETA ?




                                                                       Y es


                                                             Second ETA sending
                                                          See ETA sending detailed procedure




                                                                       Any
                                                                    signif icant                         y es
                                                                     delay ?




                                                                        no


                                                               Arriv al of the ship
                                                               Docking procedure




                                                 Figure 14: Sending the ETA




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                                                                          Page 60
COMMAN / D4.1 Functional Specifications


5.3.2.       Incoming communication
5.3.2.1.         List of tasks

Here are the tasks that can be filed in the “incoming communication” category.
“With request” means that the download or the reception occurs after request to an external
speaker.
“Without request” means that the download occurs through a server and that there‟s no need
to ask for an authorisation or for the availability of the data.
Broadcast and generic incoming concern data that are sent to the ship by an external speaker,
without asking.


     Incoming Communication                Download/          Download        Broadcast/
                                         reception with    without request generic incoming
                                            request
Make ECDIS update                              X                  X
Weather forecasts                              X                                     X
Entertainment                                  X                                     X
General information about the port             X
Access to tourist information                  X                  X
Generic incoming communications :                                                    X
   Incoming e-mail                                                                   X
   Incoming fax                                                                      X
   Incoming telex                                                                    X
   Incoming ...                                                                      X


                                 Figure 15: Incoming calls




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                               Page 61
COMMAN / D4.1 Functional Specifications

5.3.2.2.                           Flowcharts: Download and receive with request


GENERAL CASE
                                        Receive/dow nload w ith request


   Request (eg voice)                                                     Receive                     Dow nload



                                                                     Listening watch
                                                                                                        Login
     pick up the receiv er




                                                                                                     Choose serv er
                                                                                                 (directory , in case of
                                                                   Arriv al of a message
                                                                                                         need)




      choose the serv ice
      (VHF, telephone...)
                                                                                                  connect to serv er

                                                                     Reception signal
                                                                   (v isual and/or sound)

                                                                                                    send demand




           dial-up                                                                                  Receiv e data
      or use a directory

                                                                           Display

                                                                                                 close communication

                                         receiv e



                                                                                                  Archiv e download
 ask f or the data to be sent by
                                                                                                        report
          f ax, mail, etc.

                                                                        transf er of
                                                                      receiv ed data
                                                                          to other
                                                                         sof tware




    SDN display s the time                                                  y es            no
    elapsed and the cost




                                                                          Printing




           Hang-up
                                                         no                 y es




                                                                          Archiv ing

                                       Download or
                                        receiv e ?

                                                      Download




                               Figure 16: Flowcharts of generic download with request




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                                Page 62
COMMAN / D4.1 Functional Specifications

EXAMPLES : GENERAL INFORMATION ABOUT PORT AND ECDIS UPDATE

                                          General information about the port


                 Request                                                    Receive



                                                                         Listening watch
            pick up the receiv er




                                                                       Arriv al of a message




             choose the serv ice
             (VHF, telephone...)


                                                                         Reception signal
                                                                       (v isual and/or sound)




                  dial-up
         or use a directory (call the
             port or the agent)                                       Display (port maps and
                                                                         phone numbers)




        ask f or the data to be sent by
                 f ax, mail, etc.

                                                                            transf er of
                                                                          receiv ed data
                                                                              to other
                                                                             sof tware




           SDN display s the time                                              y es             no
           elapsed and the cost




                                                                             Printing




                                                               no
                  Hang-up
                                                                               y es




                                                                            Archiv ing




                             Figure 17: General information about the port


TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                               Page 63
COMMAN / D4.1 Functional Specifications



                    ECDIS Update


  first step : ask the local                           Second step : download
   harbour officer for the                                  the update
           update

                                                                   Login

         Every week




                                                                 email or
                                                                                   e-mail
                                                                  f tp?

     pick up the receiv er


                                                                  serv er


                                                             Choose serv er
     choose the serv ice                                 (directory , in case of
     (VHF, telephone...)                                         need)




           dial-up                                           connect to serv er         Check email account
      or use a directory




                                                              send demand

             talk


                                                               Receiv e data




    SDN display s the time
    elapsed and the cost                                close communication




                                                          Archiv e download
          Hang-up                                               report




                                                             transf er receiv ed
                                                               data to ECDIS
                                                                  sof tware




                                   Figure 18: ECDIS update




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                      Page 64
COMMAN / D4.1 Functional Specifications

5.3.2.3.         Flowcharts: Download without request

GENERAL CASE
                                          Dow nload


                                              Login




                                       Choose serv er (use
                                       directory , in case of
                                              need)




                                        connect to serv er




                                          send demand




                                          Receiv e data




                                      close communication




                                        Archiv e download
                                              report



               Figure 19: Flowcharts of generic download without request
EXAMPLE: ACCESS TO TOURIST INFORMATION

                                       Access to tourist
                                         information




                                              Login




                                        Choose serv er
                                      (ashore databases)




                                       connect to serv er




                                         send demand




                                         Receiv e data
                                        (pictures, data)




                                      close communication




                                       Archiv e download
                                             report



                        Figure 20: Access to tourist information


TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                     Page 65
COMMAN / D4.1 Functional Specifications

5.3.2.4.            Flowcharts: Broadcast and generic incoming communications

GENERAL CASE

                                           Listening watch




                                         Arriv al of a message




                                           Reception signal
                                         (v isual and/or sound)




                                               Display




                                              transf er of
                                            receiv ed data
                                                to other
                                               sof tware




                                                 y es             no




                                               Printing




                                   no
                                                 y es




                                              Archiv ing




           Figure 21: Flowcharts of broadcast and generic incoming communications




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                              Page 66
COMMAN / D4.1 Functional Specifications

EXAMPLE : WEATHER FORECASTS
                                  Weather forecasts (fax)




                                     Enter a NAVTEX, weather
                                           authority area




                                         Listening watch




                                          Arriv al of a f ax




                                         Reception signal
                                       (v isual and/or sound)




                                              Display




                                         transmission of
                                          receiv ed data
                                             to other
                                            sof tware




                                                y es            no




                                             Printing




                             no
                                                y es



                                            Archiv ing




                            Figure 22: Weather forecasts


TR4006/D4.1/EUTELIS/6/8/99/version 1.3                               Page 67
     COMMAN / D4.1 Functional Specifications

     5.3.3.       Bi-directional communications

     5.3.3.1.          List of tasks

     Here are the tasks that can be filed in the “bi-directional communications” category.
     “Currently voice” : many communication tasks are currently performed through simple vocal
     dialog and/or require the instantaneous and flexible information exchange only allowed by
     vocal dialog.
     “Data Communications preferable”: in some cases, according to the users themselves, data
     communications would be preferable, or complementary to the voice.


   Bi-directional Communications       Currently voice Data Communications    Online
                                                            preferable     Communications
Import/ Export of ISM code relevant          X                  X
messages or forms
Customs                                      X                  X
Medical service                              X                  X
Shore based pilotage                         X
Shore based radar assistance                 X
Port entry guide                             X
Ship-ship communication                      X
Phone boxes                                  X
Personal Communications                      X
Virtual Round Tables                                            X
Distant learning and general education                          X
Remote maintenance                           X                  X
Web access                                                                      X
Remote access to databases                                                      X
Secured payments                                                                X
Remote network management                                                       X
Remote access to COMMAN system                                                  X


                             Figure 23: Bi-directional communications




     TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                           Page 68
COMMAN / D4.1 Functional Specifications

5.3.3.2.         Flowcharts: Voice

GENERAL CASE
                                           Voice




                                     pick up the receiv er




                                     choose the serv ice
                                     (VHF, telephone...)




                                           dial-up
                                      or use a directory




                                             talk




                                 SDN display s the time
                                 elapsed and the cost




                                          Hang-up




                       Figure 24: Flowchart generic voice call




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                           Page 69
COMMAN / D4.1 Functional Specifications

EXAMPLES : SHORE BASED PILOTAGE

                            Shore -base d pilotage
                                   (v oice )




                                   pick up the receiv er




                                   choose the serv ice
                                   (VHF, telephone...)




                                         dial-up
                                    or use a directory




                                talk : ev ery minute to ev ery
                               10 seconds, course, speed,
                                   position and the same
                              inf ormation about the ships in
                                       the same area.




                                 SDN display s the time
                                 elapsed and the cost




                                        Hang-up




                           Figure 25: Shore based pilotage




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                           Page 70
COMMAN / D4.1 Functional Specifications

5.3.3.3.         Flowcharts: Web access

                                  We b acce ss



                                       Login




                                Dial ISP number and
                                    connect (use
                                     connection
                                parameters stored in
                                      memory )




                                  Launch browser




                                      Browse




                                close communication
                                  and quit browser




                          Figure 26: Flowchart Web access




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                      Page 71
COMMAN / D4.1 Functional Specifications

5.3.3.4.         Flowcharts: Secured payments




                                          Secured Payments




                                      Launch the payment
                                    application or sub-function




                                    Insertion of the Credit Card
                                     (or pre paid card), or enter
                                       the credit card number




                                          Connect to the
                                           bank server




                                          Control of bank
                                             account




                                              Payment                          End of the
                                                                     No
                                               allow ed                         process



                                                 yes




                      Display on the screen : cost and payment authorisation




                                           Acceptance to                   End of the
                                                                    No
                                               pay                          process




                                                 Yes



                                               Billing




                        Figure 27: Flowchart secured payments




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                      Page 72
COMMAN / D4.1 Functional Specifications

5.3.3.5.         Flowcharts: Remote management network



                                  Remote netw ork
                                   management



                                    Connect to the
                                   Comman sy stem
                                     (phone line)




                                      Login as
                                    administrator




                                 Access to COMMAN
                                 sy stem management




                                         log out




                      Figure 28: Flowcharts: Secured payments




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                          Page 73
    COMMAN / D4.1 Functional Specifications



    6 - Sub-functions of the COMMAN system


    6.1      Sub-functions list

    This part is dedicated to the description of COMMAN communication sub-functions. The
    definition of a sub-function is: a sub-function performs an elementary service during the
    communication. Therefore, every communication can be described as a sequence of sub-
    functions.

    Features are COMMAN functionalities that, contrary to sub-functions, don‟t intervene
    themselves in the sending or receiving of a communication. So, all the COMMAN
    functionalities that are not listed here are treated as features above in this document.

    Sub-functions can tackle the communication itself (the traffic) or the management of the
    communication (then they allow the data flow to be emitted with a determined quality of
    service). When they deal with the traffic itself, it can be IP or non-IP traffic, Outgoing or
    Incoming traffic, as summarised in the table below.

                                                Out-going     In-coming
                                  IP traffic        OI             II
                              Non-IP traffic        ON            IN
                               Management           M             M


                                Figure 29: Types of communications


       Here is the list of the sub-functions undertaken by COMMAN:


    6.1.1.       System Access related sub-functions
                                                                               Used by   Belonging to

   Filter non-authorised data service requests : Reject connection requests    II M
                                                                                         COMMAN
    to inappropriate ports.                                                               controller
                                                                                          COMMAN
   Check acceptability of incoming request : See if it is OK to accept the               controller \
    call. Factors are: Is the call from a „safe‟ number?, Is there a roaming     M       IP Store and
                                                                                           forward
    charge?                                                                                 service
   Check authenticity of incoming request : Check that the user connecting
    is allowed to connect. Typically for data services such as telnet and        M
                                                                                         COMMAN
    FTP, possibly also email. This is likely to be a check for both a valid               controller
    user and password and that the user is allowed to use the service.
   Check Authority : Determine if a user has a higher authority than            M
                                                                                         COMMAN
    another, and or, that they have the authority to perform an action.                   controller



                           Figure 30: System access related sub-functions




    TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                Page 74
    COMMAN / D4.1 Functional Specifications

    6.1.2.       Bearer management related sub-functions

                                                                                  Used by    Belonging to
                                                                                              COMMAN
   Detect incoming call : Monitor bearers for an incoming call                    II IN M      bearer
                                                                                               handler
   Bearer selection :Select the best bearer to use. Factors include: : Service
                                                                                              COMMAN
    to be used (Web, email etc) : Size of transmission (if email) : Location         M
                                                                                               controller
    being connected to (if interactive), Minimum call charge
   Check bearer availability : Check that the bearer is physically capable of                COMMAN
    connecting a call, e.g. the phone has a signal. And then also check that if      M          bearer
                                                                                               handler
    the bearer is in use.
                                                                                              COMMAN
   Connection termination : Terminate a connection on a selected bearer           OI II M      bearer
                                                                                               handler
   Connect to bearer(s) : Perform the call negotiation with the bearer                       COMMAN
                                                                                  OI ON M       bearer
    equipment.                                                                                 handler


                        Figure 31: Bearer management related sub-functions




    6.1.3.       Network monitoring and management related sub-functions
                                                                                  Used by    Belonging to

   Determine onboard host : Examine port to determine correct server to          II IN M
                                                                                             COMMAN
    route to, if IP is that of the SDN                                                        controller
                                                                                                User
   Establish connection to onboard host : Confirm host is available and is         II M
                                                                                             Application /
    ready to accept data.                                                                    COMMAN
                                                                                              controller
                                                                                                User
                                                                                             Application /
   Identify host(s) available : Check that servers are accepting connections       II M
                                                                                             COMMAN
                                                                                              controller
                                                                                             COMMAN
   Format data for onboard host : Convert to standard IP packets                   IN
                                                                                              controller
   Recording : record in the events log the date, time, length, type, bearer,
                                                                                             COMMAN
    cost, … of an incoming or outgoing call. This sub-function also records          M
                                                                                              controller
    the content of the messages sent and not only connection parameters.
                                                                                             COMMAN
   Connect call to appropriate IP service : For the use of direct Email             M
                                                                                             controller \
    server, Telnet and FTP connections so that they are correctly dealt with.                 IP online
                                                                                               service
   Connect non-IP to appropriate destination : Connect FAX and voice to                     COMMAN
                                                                                     M          bearer
    appropriate equipment and/or location                                                      handler
   Connect onboard e-mail server to server ashore : Establish a connection                  IP Store and
    from the ship server to the shore server, either by an appropriate already     OI M        forward
                                                                                                service
    connected bearer or a new connection.
   Detect outgoing call request : Monitor applications (browsers, email          OI ON M
                                                                                               IP online
    clients, FTP and Telnet) for connection requests.                                           service



                        Figure 32: Network monitoring related sub-functions




    TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                    Page 75
    COMMAN / D4.1 Functional Specifications


    6.1.4.       QoS management related sub-functions
                                                                                            Belonging to
                                                                                  Used by
                                                                                                 User
   Request appropriate connectivity: Depending on type of service being                    Application /
                                                                                    M       IP Store and
    utilised, request the appropriate bandwidth bearer.                                        forward
                                                                                                service
   Determine QoS parameters: The user determines the COMMAN                                     User
                                                                                            Application /
    Delivery Requirements according to some parameters (maximum call               OI M
                                                                                             COMMAN
    cost, deadline for transmission, etc…).                                                   controller
   Obtain CDR : Obtain the CDR for email from the user (either through                      COMMAN
                                                                                              controller
    use of extra headers in email, or if not present by dialogue with the user     OI M
    to determine requirements).

                          Figure 33: QoS management related sub-functions




    6.1.5.       Store and forward related sub-functions
                                                                                  Used by   Belonging to
                                                                                            COMMAN
  Queue request/Prioritise calls: Does what it says.                               M
                                                                                             controller
1. Download mail in accordance with urgency and cost criteria: Examine
   email on server, group into categories in accordance with the criteria of                IP Store and
                                                                                    OI        forward
   the connection type (scheduled or immediate) , the time, the size,                          service
   download appropriate groups.
                                                                                                  User
2. Data flow (incoming data) : Receive data and pass to appropriate end            OI II
                                                                                            Application
   system checking for validity of received packets.                                         / IP Online
                                                                                                service
                                                                                            IP Store and
3. Poll host mail server and send queued mail                                      OI M        forward
                                                                                                Service
                                                                                                  User
                                                                                            Application \
                                                                                              IP online
4. Data transfer (outgoing data)                                                  OI ON        service \
                                                                                             COMMAN
                                                                                                 bearer
                                                                                                handler
                                                                                                  User
   Virus sweep : Invoke virus software to check data in email queue or                     Application /
                                                                                    M       IP Store and
    workstation/server received files.                                                         forward
                                                                                                service


                         Figure 34: Store and Forward related sub-functions




    6.1.6.       Service related sub-functions
                                                                                  Used by   Belonging to

   Identify call service type (IP/non-IP) : On collection of a call, determine             COMMAN
                                                                                  II IN M      bearer
    what type it is, data or voice.                                                           handler
                                                                                            COMMAN
   Calculate call cost : Calculate the cost of the call just completed. If         M
                                                                                             controller


    TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                   Page 76
    COMMAN / D4.1 Functional Specifications

    email or passive web connection then calculate the cost per item using
    the average data throughput,
   Call cost estimation : estimate the cost of the call before it happens
                                                                                        COMMAN
    according to its type, expected volume of data. Sub-function generally      M
                                                                                         controller
    included in the bearer selection process.
   Record call cost in the telecommunications costs database or in events      M
                                                                                        COMMAN
    log                                                                                  controller
                                                                              ON, OI,   COMMAN
   Real time calculation and display of cost                                   M        controller
   Identify user call characteristics : The system determines the type of              COMMAN
                                                                               OI M        bearer
    call, the originator, the requestor, the destination, etc…                            handler



                              Figure 35: Service related sub-functions




    6.1.7.       Non IP related sub-functions
    These sub-functions are used for non-IP bearers (Inmarsat C, AIS).

                                                                              Used by   Belonging to

   Non IP data reception : Receive data from a Non IP system and extract       IN        NON-IP
    information
   Transfer information received from AIS (or other non-IP bearer) to
    onboard host : Format information for end user and forward data            IN II      NON-IP
    packets to the correct onboard host with indication that data came from
    AIS.
   Receive time, position, course and speed data : Take in PCSH data for       M         NON-IP
    passing through the AIS
   Non IP data transmission: Format information and send data to a Non         ON        NON-IP
    IP system
   Receive data for transmission over Non IP system from onboard host :        ON        NON-IP
    Receive data from onboard IP host and queue for transmission.
   Format data to a non IP (AIS) standard                                    ON OI       NON-IP




                        Figure 36: Non IP management related sub-functions




    TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                               Page 77
COMMAN / D4.1 Functional Specifications


6.2        Links between the sub-functions

6.2.1.          IP communications detailed


There are four types of IP communications :
 Message outgoing: send e-mail for instance
 Message incoming: receive e-mail for instance
 Online outgoing: online communication initiated by the COMMAN system, Computer
   Supported Co-operative Work for instance
 Online incoming, online communication initiated by a remote server




The following table summarises the different type of IP-communications.


                                      Outgoing                Incoming
Offline IP (store and forward)        E-mail, Fax3            Email, Fax
Online IP                             HTTP, telnet, FTP, TCP, telnet, HTTP, FTP, TCP,
                                      UDP,                    UDP,

                             Figure 37: Types of IP communications


The handling of outgoing and incoming traffic must be handled separately. Outgoing calls are
regulated on the basis of a user profile, and incoming calls must be authorised and set up to
the right service handler onboard

Now, for each type of IP communication identified, we will describe the communications as
sequence of sub-functions. This will be a key point to describe how the communications are
handled and what service the system must provide.

As we will see later, there is no significant difference, from the point of view of the
COMMAN system, between the Offline and Online traffics management.



6.2.1.1.             Outgoing Offline IP communication

First, the request for sending the message and then the sending of information itself. This
second phase does not necessarily follow immediately the first phase; it can occur later (often,
during the evening or in the night for non-urgent communications).




3
    The Fax service can be seen as a combined service. Both IP and non-IP.

TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                 Page 78
COMMAN / D4.1 Functional Specifications

Request for sending the message:

 COMMAN Sub-               Parameters                              Action
     function
Detect Outgoing                                         Create/Edit Message Content.
call
Check authority      -   Set of rights            Allow or not the message sending request.
Identify        call -   type of call              The system determines the type of call,
characteristics      -   originator                   the originator, the requestor, the
                     -   requestor                            destination, etc…
                     -   destination, etc…
Determine      QoS -     urgency                     The user will have to determine the
parameters -         -   privacy                  COMMAN Delivery Parameter, that is to
                     -   authentication           say: maximum cost, deadline for sending,
                                                             choice of bearers.
Obtain CDR         -     urgency                         Obtain the CDR for offline
                   -     privacy                              communication
                   -     authentication
Call          cost -     bearer,                   Estimate the cost, according to the CDR
estimation         -     schedule
                   -     estimated duration
Queue request - -        priority level              After the negotiation, the message is
Prioritisation of -      bearer                    queued before the sending according to
the call                                              the priority level defined. Several
                                                  information are defined for the message :
                                                    bearer chosen, planed time of sending,
                                                                     etc…
Recording                                         The information concerning the message
                                                      are stored like in a casual mailer.


Sending of the message : This process is supported by the system so as to empty the queue of
the system. Consequently, this phase will be very similar for every offline IP communication.

    COMMAN Sub-               Parameters                              action
       function
     Check Bearer          Bearer‟s response       All the available bearers are listed to define
      availability                                  if the bearer planed to support the sending
                                                            of the message is available.
   Check the priority     Priority level in the        Before the sending of the message, the
      level of the               queue                system checks that the message has the
       message                                       highest level of priority in the queue and
                                                         that the parameters of sending are
                                                                      confirmed.
    Bearer selection      pre-selected bearer      This sub-function is executed according to
                                                      the bearer chosen for the sending of the
                                                       message and to prepare the sending of
                                                                     information.
   Connect to bearer                                The connection is established between the
                                                             system and the addressee.
   Connect onboard          Server‟s address       Establish a connection from the ship server,
   e-mail server to                                              to the shore server
    server ashore.
    Data transfer                                            The data are transferred

TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                  Page 79
COMMAN / D4.1 Functional Specifications

      Real time display     Cost rate                   Real time calculation and display of cost
           of cost            Duration of the call
        Connection            End of the message      The connection is closed if the message has
        termination                                   been sent totally and if no message requires
                                                                 a sending in the queue.
     Calculate call cost           - cost rate          Thanks to the price list of all the bearers
                                   - duration             stored by the system, the cost of the
                                                              communication is calculated.
          Recording              Statistical and      Statistical and management parameters are
                                 management            stored such as the cost, the duration, etc…
                                  parameters



6.2.1.2.                Incoming Offline IP communication

Message Reception
To be able to control the transmission of inbound messages via potentially costly bearers it is
assumed necessary to have IMAP like functionality for fetching message lists from "on-
shore" mail servers to the COMMAN SDN, and then further download messages using POP-3
like functionality.

(This concept can be used in both cases: incoming message or email push initiated from the
shore.)

       COMMAN Sub-               Parameters                            action
            function
    Detect incoming call
    Check acceptability                              Check that the incoming call is allowed.
    of call

    Connect to bearer                                The connection is established between the
                                                     system and the addressee.

    Poll host mail server    Host mail address  Fetch Message List using IMAP
                                                    protocol.4
    Download mail in accordance with urgency and cost criteria:
         Schedule for Message List              If OK
         Fetching                               then set Message List Transmission Status
                                                    to Completed
                                                -- otherwise leave it on queue for a new
                                                    attempt…
                                                Append Message Transmission data to
                                                    Message List Transmission Attempts.
         Select           Message Id.           Get Id of Message where Delivery
         Message                                    Requirements are satisfied.
         (to fetch)
         Fetch Message Message Id.              Fetch Message using POP-3 protocol.5



4
 IMAP/IP-packets transmitted to LAN are routed via Bearer Connection. The COMMAN
Message Transmission (Scheduler Level) receives the IMAP Message list transmitted to the
LAN as a reply from the on-shore mail server.

TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                   Page 80
COMMAN / D4.1 Functional Specifications

    Connection              Conn.Id.              If (no other connections via Bearer)
    termination                                   then Shut down Bearer Connection.
    Virus sweep                                   Invoke virus software to check data in
                                                  email queue or workstation/server
                                                  received files.
    Record      Message Message Id.               If OK
    Transmission data   Transmission data         then set Message Transmission Status to
                                                      Completed
                                                  -- otherwise leave it on queue for a new
                                                      attempt…
                                                  Append Message Transmission data to
                                                      Message Transmission Attempts.



6.2.1.3.                Outgoing Online communication

      COMMAN Sub-               Parameters                    COMMAN action
         function
    Outgoing       call                           The onboard modem requests the opening
    request                                           of a connection.
    Check authority     -     Set of rights             Allow or not the message sending
                                                                     request.
    Identify        call type of call             The system determines the type of call,
    characteristics      originator                   the originator, the requestor, the
                         requestor                    destination, etc… All those parameters
                         destination                  have to be listed.
    Determine       QoS Urgency                   The user will have to determine several
    parameters           Privacy                  parameters such as : Urgency (different
                         Authentication           levels will have to be defined; by instance
                                                  Low, Medium, High), Privacy (idem),
                                                  Authentication (this can be requested for
                                                  safety-critical communications), … All
                                                  this will enable the determination of the
                                                  QoS requested that will then be
                                                  negotiated.
    Obtain CDR            - urgency                         Obtain the CDR for offline
                          - privacy                              communication
                          - authentication
    Call             cost - bearer,                Estimate the cost, according to the CDR
    estimation            - schedule
                          - estimated duration
    Check          bearer List of bearers         Bearer availability : All the available
    availability                                  bearers are listed to define if the bearer
                                                  planed to support communication is
                                                  available.
    Request                QoS parameters
    appropriate
    connectivity
    Connect to bearer      ISP connection Point   A PPP connection is opened between the

5
  POP-3/IP-packets transmitted to LAN are routed via Bearer Connection. The COMMAN
Message Transmission (Scheduler Level) is NOT concerned with IP-packets after the OK to
send message state has been reached.

TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                 Page 81
COMMAN / D4.1 Functional Specifications

                                                     system and the addressee.
 Check authenticity Id                            Mandatory for Intranet access (the
 of incoming request Password                        checking is done by the ashore server
                     Host Address                    but the onboard system will have to
                                                     support authentication applications).
 Data transfer                                    The IP packets are transferred and the
                                                     virus are checked and destroyed if
                                                     necessary.
 Real time display of Cost rate                   Real time calculation and display of cost
 cost                 Duration of the call
 Connection           End of message              The PPP connection is closed if the
 termination                                          message has been sent totally and if no
                                                      message requires a sending in the
                                                      queue.
 Calculate call cost     Cost rate                Thanks to the price list of all the bearers
                         Duration of the call         stored by the system, the cost of the
                                                      communication is calculated.
 Recording               Statistical          and Statistical and management parameters
                         management                   are stored such as the cost, the
                         parameters                   duration, etc…


6.2.1.4.            Incoming online

   COMMAN Sub-            Parameters                           COMMAN action
       function
 Detect     incoming Bearers list                 Monitor bearer for an incoming call
 call
 Check acceptability                              Check that the incoming call is allowed.
 of call

 Identify call serviceType                  of On collection of a call, determine if it is
 type                    communication             data or voice
 Check acceptability  Safety of the originator Is the call from a safe number ?
 of incoming request  number
 Check authenticity   Id                       Mandatory for Intranet access (the
 of incoming request  Password                     checking is done by the ashore server
                                                   but the onboard system will have to
                                                   support authentication applications).
 Establish            Access conditions to Confirm host is available and ready to
 connection        to    the host                  accept data
 onboard host
 Data transfer                                   The data are transferred and the virus are
                                                     checked and destroyed if necessary.
 Connection              End of message          The connection is closed if the message
 termination                                         has been sent totally and if no message
                                                     requires a sending in the queue.
 Virus sweep                                     Invoke virus software to check data in
                                                 email queue or workstation/server
                                                 received files.
 Recording               Statistical         and Statistical and management parameters
                         management                  are stored such as the duration, etc…
                         parameters


TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                  Page 82
COMMAN / D4.1 Functional Specifications


6.2.2.       Non-IP communications detailed
6.2.2.1.           Outgoing call

Contrary to IP communications, the distinction between on-line and off-line traffic is not
relevant to present the detailed functionalities of the COMMAN System. Indeed, the
COMMAN SDN only manages data communications. The service that will be provided for
non-IP communications will be restricted to:

   Reservation of communication periods (scheduling).
   Opening and closing of connections.
   Cost calculation

Consequently, whether the communication is online or offline, it will not have any impact on
the system features.


Scheduling
Determine      QoS -      urgency                   The user will have to determine the
parameters – Call -       privacy                COMMAN Delivery Parameter, that is to
cost estimation    -      authentication         say: maximum cost, deadline for sending,
                                                              choice of bearers.
Queue       request- -    priority level            After the negotiation, the message is
Prioritisation of -       bearer                  queued before the sending according to
the call -                                           the priority level defined. Several
                                                 information are defined for the message :
                                                   bearer chosen, planed time of sending,
                                                                    etc…


Connection opening – Message sending
 Connect to bearer                              A connection is opened between the
                                                  system and the addressee.
 Data transfer
 Connection              End of message         The connection is closed
 termination


Cost calculation
 Real time display of Cost rate                 thanks to the price list of all the bearers
 cost                 Time elapsed                 stored by the system, the cost of the
                                                   communication is calculated in real
                                                   time




6.2.2.2.           Incoming call

In this situation the COMMAN Single Data Node does not provide a specific service except
the service provided by a PABX. This is out of the scope of COMMAN that focuses on data
communications but we assume here that a PABX exists onboard.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                               Page 83
COMMAN / D4.1 Functional Specifications



7 - Management sub-functions detailed

7.1        The different management areas

Telecommunication tasks are heavy users of bandwidth and of access to bearers. As said
before, the objective of the COMMAN system is to enable a rationalisation and a
simplification of the communication tasks that are under the responsibility of the crew.

So, the COMMAN system will have to support the different types of information flows in
both way (from the shore to the ship and from the ship to the shore). As a consequence, the
management of all the communications will be the core of the service provided by the Single
Data Node. We can already list all the management issues that the COMMAN system will
have to cope with:

     Bearer management: Those features concern the choice of the bearers, the beginning and
      ending of the call.

     Network management: The network management is not different from the casual network
      management of a LAN.

     Management of store-and-forward applications: For instance, email is a specific
      application since it is supported by a store-and-forward process. Consequently, it will
      have some very specific requirements on the system (need of queuing, storing, etc…).

     Database management : The COMMAN system will contain a database that will store all
      required information. The description of the structure and of its content will also be a key
      point of the specification.

There are numerous database management features (access-functions). Too numerous to list
here, but generally retrieve/store/modify on all entities defined in the COMMAN data model.
As we have defined that a sub-function aims at supporting a specific service necessary for the
communication, no specific sub-function is dedicated to database management.

     Service management: The service management will be mainly dedicated to determining
      the types of service requested and to support the billing of the communications.

     System access management: Accounts will be mandatory so as to assign specific rights to
      every user. The management of those accounts (creation, modification, suppression) will
      be a specific topic that is indispensable to support the communication processes.

     QoS/CDR management: The Quality Of Service/COMMAN Delivery requirements are
      parameters that will have to be managed and that have been specified in this document.
      Now, we have to precise that a message could be sent or a connection could be opened
      requesting an immediate sending or requesting a scheduled sending. This parameter will
      not be included in the QoS parameter.

     Time Synchronisation management: Synchronise time on all hosts in the network, and if
      necessary with other equipment and bearers. Time synchronisation will be realised using
      the NTPv3 (Network Time Protocol version 3) according to RFC 1305 (Request For
      Comment). Time synchronisation in PISCES will be based on NTP, too.
      The Network Time Protocol (NTP) is used to synchronize the time of a computer client or
      server to another server or reference time source, such as a radio or satellite receiver or

TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                   Page 84
COMMAN / D4.1 Functional Specifications

      modem. It provides client accuracies typically within a millisecond on LANs and up to a
      few tens of milliseconds on WANs relative to a primary server synchronised to
      Coordinated Universal Time (UTC) via a Global Positioning Service (GPS) receiver, for
      example. Typical NTP configurations utilise multiple redundant servers and diverse
      network paths, in order to achieve high accuracy and reliability. Some configurations
      include cryptographic authentication to prevent accidental or malicious protocol attacks.


A list of sub-functions has been previously established so as to detail how the
communications are handled by the system. Most of them deal in fact with management, the
others only concern the formatting and the transmission of data.
The sub-functions dealing with management can be sorted according to the categories defined
above. The focus of this part will be to detail more precisely the sub-functions dealing with
management and the corresponding requirements for the system.




7.2       Detail of the “System Access” sub-functions

7.2.1.         Check authenticity of incoming request

This is only really a function worth mentioning. Any FTP or TELNET server will have the
required functionality of username/password checking. An incoming call might however
introduce an added level of security to ensure that the user calling is allowed to establish a
dial up connection with the ship.


Input parameters or data
Login
Password

Output
Accept or reject incoming request


Case incoming request
For n<3 // Only 3 attempts are tolerated
       Receive Login + Password
       If Login is valid // Check in the Account database
              If Password is valid // Check in the Account database
                      Accept incoming request
              Else
                      Refuse incoming request
              End if
       Else
              Refuse incoming request
     End If
Next n

Log the event


TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                 Page 85
COMMAN / D4.1 Functional Specifications




7.2.2.       Check acceptability of incoming request

The service checks if it is possible to accept an incoming call according to 2 factors: the
roaming charges and the origin of the caller (is the call from a „safe‟ number). The SDN can
be configured so that no call where a roaming charge is to be incurred will be accepted. The
incoming call will also be accepted if it is from a known number.

It is assumed that the Caller ID service, while not always available, can be used to screen
connections. Configuration may be that we have 1 line for all types of data, and so have to
answer all calls, or one line for data (IP) and one line for FAX and Voice. The assumption
being that we know who will call for a data connection but that too many people to control
can fax or call the ship.

All faxes and voice communications should be received if they don‟t engage roaming charge.


Input parameters or data
callerID

Output
Authorisation or not


If caller ID service available from Bearer
        Log callers number
End if
If bearer carries a roaming charge at current network
        Refuse call
End if
If one line for voice and data
        Connect call
        Detect call type
        when data:
               If caller ID valid
                       If in the database of safe numbers
                               accept call
                               route to IP service
                       Else
                               reject call
                               Create security log entry for call
                       End if
               Else
                       accept call
                       route to IP service
               End
        When FAX:
               If no roaming charges
                        Accept call
                        Route to FAX service

TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                              Page 86
COMMAN / D4.1 Functional Specifications

                Else
                      Reject call
              End If
         When voice:
              If no roaming charges
                      Accept call
                      Ring appropriate phone
              Else
                      Reject call
              End If
Else
         If line is data
                  If caller ID valid
                          If in the database of safe numbers
                                  connect call
                                  accept call
                                  route to IP service
                          else
                                  refuse call
                          end if
                  else
                          connect call
                          route to IP service
                  end if
         else if line is FAX/Voice
                          If no roaming charges
                                   Accept call
                                   connect call
                                  detect call type:
                                         when FAX:
                                         route to FAX service
                                         when Voice:
                                         ring appropriate phone
                          else
                                  reject call
                          End If
end if




7.2.3.        Filter non-authorised data service requests

This sub-function only allows access from positively authorised IP addresses which are
maintained in the database.


Output
Filtration



TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                        Page 87
COMMAN / D4.1 Functional Specifications

If connection is from dangerous IP                      // list of dangerous IP is stored in the
database
       Do not connect
       Alert user
Else
       Connect
End if




7.2.4.        Check Authority

This sub-function checks that the user is allowed to send information.




7.3      Detail of the “Bearer” sub-functions

7.3.1.        Detect incoming call

The service provided by this sub-function is to monitor the available bearers for any incoming
call.

The bearer process shown below is not part of the server itself but rather the Bearer Interfaces
subsystem. It is shown here only to provide a basis for understanding the handling of
incoming calls in the COMMAN Server.


                                              Bearer Process
                                                                                Connected
                                              Connection closed           l_send/receive_IP |
                       Waiting for call                                  l_send/receiveNonIP
                                                 /close call
                                                                               (In this state
                                                                          communication of the
                                                                            allowed types are
                                           Connection rejected                 transmitted.)
                Call detected
                                               /close call

                                Call rejected                    Connection accepted(id,type)
                                 /close call

                      Validating caller
                      l_Get caller id; Call accepted(id) Validating Connection
                      C_Validate(id)                     l_Get Connection type;
                                                        C_ValidateConn(id,type)




                                          Figure 38: Bearer process




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                           Page 88
COMMAN / D4.1 Functional Specifications

The COMMAN Server has to handle the following calls/messages from the Bearer:
ValidateCaller(id) to validate that the caller id is allowed to call into the COMMAN SDN.
ValidateConnection(id,type) to validate that the connection type (IP, FAX, voice) is allowed
for this caller.
When the connection is accepted the bearer transfers the allowed connection types. (In the
case of a phone (e.g. GSM phone) bearer this would be either IP on a "modem" connection,
fax on a fax connection, or voice on a voice connection.)

   ValidateCaller(id, bearer, time, position) - Optional: check id (e.g. phone number) of
    caller vs. registered callers in the COMMAN Mgmt. DB. Call acceptance also depends on
    bearer, time (of the day), and (geographic) position.
   ValidateConnection(id,type, bearer, time, position) -        Optional: check with the
    COMMAN Mgmt. DB that the caller is allowed to establish connections of this type.
    Communication acceptance also depends on bearer, time (of the day), and (geographic)
    position.
   Send_IP - check that the IP source and destination addresses are allowed addresses for the
    established connection (as registered in the connection database for the current
    connections). The IP packets are sent onto the LAN, and consumed by the destination.
    LogIllegal source and/or destination addresses in event log.





7.3.2.        Bearer selection

The service provided by this sub-function is to select the most proper bearer according to 3
different factors: Service to be used (Web, email etc), Size of transmission (if email) and the
minimum call charge.

Moreover, voice communications will be instigated via the system (even if it is transparent to
the user). All services offer comparable quality for voice so nothing other cost is a deciding
factor. FAX has two possible send modes: to shore based computer for transmission at much
reduced cost; individual transmission of a FAX to a location.


To finish, when sending email immediately the cost of the call will be paid for by the
instigator, and the utilisation of possibly wasted time connected for sending of other emails is
encouraged.


Input Parameters or data
Service – The type of service being used (voice, IP, Email, Fax, proprietary)
QoS – Simple factor of BW or Cost

Output
List of bearers ordered by cost


„check bearer availability‟ to get bearer list
Case service
      When IP communication:
             If scheduled delivery
                     Select bearer according to CDR parameters
             Else If immediate

TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                 Page 89
COMMAN / D4.1 Functional Specifications

                        Calculate cost for bearer chosen
                        If (cost for bearer) < minimum charge then calculate
                        messages from queue to best use connection time.
                                      Select messages from queue until (total
                                      cost for bearer) < minimum charge
                                      Est. Total cost to send message = minimum
                                      charge
                               else          // all the time is used up so we shall
                                             just send the message
                                      est. total cost to send message = cost to
                                      send message
                        end if



7.3.3.        Check bearer availability

This sub-function checks that the bearer is physically capable of connecting a call, i.e. the
phone has a signal. And then also checks that the bearer is not in use.

Input parameters or data
List of bearers
Bearer signal strength

Output
A list of bearers that are capable of making a connection and their status (i.e. in use or not in
use)


For each bearer check and mark status
      Bearer in use?
            Mark as in use and in-service
            Determine service type and owner
            next
      Bearer signal strength > minimum?
            Mark as in-service
Return bearer list from those in-service




7.3.4.        Connect to bearer(s)

Perform the call negotiation with the bearer equipment assuming that every connection using
a bearer must have a number to dial. In the case of broadcast communication, the use of this
sub-function is simply not relevant. Some defined error method will be used for this error
prone task, such as throwing errors

Input Parameters or data
Bearer to use – name of a bearer
Number to connect to – The number to dial or, if HF, the Frequency range to try.


TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                  Page 90
COMMAN / D4.1 Functional Specifications

Output
Connection to the bearer


Case bearer
      When HF:
            For x > min_freq and x < max_freq
                    Send out connection request
                    If reply received
                            Mark quality and frequency
            End for
            If replies received
                    Return best quality connection (i.e. frequency)
            // This can only be reached when a connection cannot be
            // established within the frequency range
            Throw an error as the HF connection cannot be established
      When others:
            Check signal // since the connection was checked, it may have
            gone
            // U/S
            For n < 4
                    Open line
                    Dial number
                    If engaged
                            Hang up
                            Inform user
                            Pause
                    Else
                            negotiate
                            Return the connection
                    End if
            End for
            Negotiate
            Return the connection




7.3.5.        Connection termination

Terminate a connection on a selected bearer. It is assumed that more than one user may be
using a bearer depending on the service and some super user or pecking order may mean that
connections can be terminated on an authority basis.

Here is resented the different levels of hierarchy:
   1. Sys admin
   2. Owner of connection
   3. user
   4. system




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                            Page 91
COMMAN / D4.1 Functional Specifications

Input Parameters or data
Requester – the user who is requesting the termination

Output
Connection termination


Confirm requester wants to terminate
If requester == sys admin then
       owner = requester
       // This is solely to take account of the fact that
       // the sys admin is king of the hill
       // but we have pretty good logic, and perhaps sys admin is a group
       // with inner hierarchy
end if
If users of the connection > 1 then //we have other users
       For each user
               If user < requester // authority wise
                       Notify user that connection is going to be terminated
                       Disconnect users process(es) from connection after x min
               Else
                       Generate billing for current time of call for current owner
                       Pass termination + ownership to him
                               // i.e. this is a semi-recursive function
                       Exit
               End if
Else
       Notify any processes using connection (i.e. email or FTP)
       Hang up call
       Calculate cost
End if




7.4      Detail of the “Network” sub-functions

7.4.1.        Detect outgoing call request

Monitor applications (browsers, FTP and Telnet) for connection requests. This is essentially a
replacement for the winsock so that applications that would have invoked that instead invoke
our bespoke method here. It is assumed that the system operates in a windows type
environment with some kind of API layer between the applications and the hardware devices.

On detection of request for a network connection outside of the LAN
Determine the type of the connection being requested, Voice, FAX, Email, IP
Use „bearer selection‟ to get a bearer list
Display bearer list to user for selection and confirmation.

This functionality is a standard routing functionality.



TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                Page 92
COMMAN / D4.1 Functional Specifications




7.4.2.        Determine onboard host

Examine port to determine correct server to route to, if IP is that of the SDN.

Output
Host IP address


For n<4
       Receive incoming address request
             If host exists
                     Host sends its MAC address
                     Conversion into IP address // the ARP protocol performs
                     this conversion
                     Send IP address
             End if
Next n




7.4.3.        Establish connection to onboard host

Confirm host is available and is ready to accept data.

Output
Connection established


For each service
      Ensure service running by connecting
      If connect is successful
             Mark as working
      Else
             Mark as down
             Alert user
      End if
End for




7.4.4.        Identify host(s) available

This sub-function checks that servers are accepting connections. A management process that
routinely checks that the host that should be running are.

Input


TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                            Page 93
COMMAN / D4.1 Functional Specifications

List of host that should be operating

Output
Available host(s)


For each host
      Make system connection
      If connection fails
             Flag main user on failure
      End if
End for
Generate system log for results.




7.4.5.        Connect onboard e-mail server to server ashore

This sub-function establishes a connection from the ship email server to the shore server,
either by an appropriate already connected bearer or a new connection. It is assumed that if a
bust bearer is chosen then if it is not IP the user should be kicked.

Input parameters
The Bearer to use

Output
Connection


If the bearer is busy
        If connection is not IP
               // need an authority check here, perhaps another sub-function
        Warn owner of the connection that they are about to be terminated
               Pause
        Terminate connection
        Establish connection to shore site
End if
Return the connection
Else
        Establish connection to shore site
        Return the connection
End if




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                Page 94
COMMAN / D4.1 Functional Specifications

7.4.6.        Connect non-IP to appropriate destination

Connect FAX, AIS and voice to appropriate equipment and/or location. It is assumed that
FAX can be either received by a FAX machine or a suitable FAX/Modem equipped server
and voice may be routed to an automated switch board where the extension is dialled.

Input Parameters
Service - Type of service (FAX, Voice)

Output
Connection


Case service:
      When FAX:
            If send to server
                   Route to server
                   Notify main user that fax has arrived
            Else
                   Send to Fax machine
      When AIS:
            Connect to AIS system
      When Voice:
            Connect to automated switchboard
            Play message “If you know the number required please dial
now”
            Wait for number
            If no number dialled or number not in PBX list
                   Connect to main user
            Else
                   Connect to PBX number
            End if




7.4.7.        Connect call to appropriate IP service

This sub-function will be mainly dedicated to the use of direct Email server, Telnet and FTP
connections so that they are correctly dealt with. For the every-day life of the use of the
Single Data Node, people may not know the IP of the server on the ship that they wish to
connect to but are aware of the IP of the SDN and the service they want.

Input parameters
Ports of the servers

Output
Connection


Establish IP link with dial up
if port requested does not match IP of server

TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                              Page 95
COMMAN / D4.1 Functional Specifications

         forward to server
else
         let pass
end if




7.4.8.        Format data for onboard host

This sub-function acts as an intermediary between the Non IP (AIS) and the user. It
undertakes the necessary translation between the data formats required by the non IP (AIS)
system and that used in the user interface. The exact nature of this sub-function will be
determined when the relationship of Non IP and COMMAN and the way in which COMMAN
will handle Non IP data has been refined.



7.4.9.        Recording

This sub-function is responsible for the recording of all the events, especially the call costs.
All this will be stored in the COMMAN database.




7.5      Detail of the “QoS” sub-functions

7.5.1.        Request appropriate connectivity

This sub-function establishes a connection between the user and selected/offered bearer. The
identification of the bearers and their associated predicted costs is provided by a separate sub-
function.



7.5.2.        Negotiate QoS that can be provided

The SDN and end application agree the QoS that will be provided to support the requested
data exchange. The immediate sending allowed for the administrator is also taken in charge
by the sub-function; in this situation, it becomes a recursive sub-function.

Input parameters
Message to send or connection to open

Output
CDR parameters


For each bearer Display CDR :Cost, Bandwidth, Transmission Time, Time of
availability


TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                  Page 96
COMMAN / D4.1 Functional Specifications

User sorts each bearer between bearers satisfying Maximum call cost and
Maximum time of availability // Other parameters can be used to minimise
the range of choice of bearers.
If user == administrator and immediate sending requested the
        Administrator choose bearer, time of delivery
        Delay scheduled messages or connections
        Warn users concerned
        Negotiate again QoS
End if
User gives his identity and password for billing
Store QoS requested



7.5.3.       Obtain CDR
Obtain the CDR from the user (either through use of extra headers in email, or if not present
by dialogue with the user to determine requirements).

Assumptions
That the header fields of the message will be used to both send and store the CDR in most
cases but that the SDN must prompt the user to fill out a CDR in some cases.
That the CDRs mainly define what queue, i.e. delivery schedule, that the message should be
stored in.

On receipt of email check header fields
If header fields for CDR not present then
       Find user agent IP address
       Invoke CDR dialogue at user agent IP
       Wait for return of CDR from user agent
       //User may decide to not bother
       If user agent returns abort then
                Dispose of the message and end
       End if
       Enter CDR into header fields in email
End if
Store email in appropriate queue according to CDR in header fields




7.6      Detail of the “Store and forward” sub-functions

7.6.1.       Queue request/Prioritise calls

This sub-function enables to queue messages that doesn‟t require immediate delivery. It is
assumed that the QoS has been already negotiated.

This sub-function compares the priority level of the message to be queued with the level of
priority of the messages queued, in the decreasing order of priority.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                               Page 97
COMMAN / D4.1 Functional Specifications

Input parameters
New message(with priority/CDR)
 queue (of messages with priorities/CDRs)

Output
queue


Insert new message according to priority/CDR



7.6.2.       Download mail in accordance with urgency and cost criteria


The emails sent to an onboard address are stored by a server ashore and then, downloaded on
request of the server onboard.

Output
Emails downloaded


Open IP connection
Connect to server ashore
Fetch Message List
       Select Messages to fetch // chosen by the administrator
      Fetch Messages selected
Close IP connection




7.6.3.       Poll host mail server and send queued mails

This sub-function manages the sending of the messages stored on the different queues
corresponding to the available bearers. It takes in charge two different functions:

   When a message has to be sent, or a connection has to be opened, it activates the sending
    of message sequence of sub-functions or the opening of connection sequence of sub-
    functions.
   When there is a delay in the scheduling or an inadequacy between the bearers availability
    planing and the available bearers, it informs the corresponding users and suggest them to
    schedule again their communications.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                               Page 98
COMMAN / D4.1 Functional Specifications

7.7         Detail of the “Service” sub-functions

7.7.1.          Identify call service type (IP/non-IP)

On request for a call, determine what type it is, data or voice. It is imagined that this would be
part of an overall windsock replacement. To be more concrete, this sub-function identifies the
application calling for a connection

Output
Service type


Case application
      When browser client | FTP client | Telnet client :
            Return IP
      When FAX client:
            Return FAX
      When Voice client:
            Return voice



7.7.2.          Calculate call cost

Calculate the cost of the call just completed. If email or passive web connection then calculate
the cost per item using the average data throughput. This is a function called after a call has
been completed.


Input Parameters
Type of call (Email, Fax to location, Voice, Immediate Email, Non IP, IP)
Transmission log for completed call

Output
Call cost


From transmission log find the duration connected and bearer rate
Calculate cost of call with information
If cost of call < minimum charge then
        Cost of call = minimum charge
End if
When Email:
        From transmission log find the total amount of data sent
        From transmission log find the total amount of data received
        Average transmission rate = (data sent + data received) / duration of
call
        For each message sent
                Calculate the time taken
                Calculate the cost from the time taken and average transmission
rate
                Generate billing information for email

TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                   Page 99
COMMAN / D4.1 Functional Specifications

     End for
When Fax to location | voice | Immediate email | Non IP | IP |:
      Generate billing information for call cost



7.7.3.        Identify user call characteristics

This sub-function takes in charge the registration of the requested call characteristics and also
the actual call characteristics; those data can slightly change between what was estimated and
what has been used (cost, transmission time, QoS).




7.7.4.        Call cost estimation

This sub-function identifies the bearers that could support the user request for connectivity. It
then will estimate the cost of using each of the bearers and present the estimate to the user for
selection of the bearer to use. The process will make the estimate based on factors which
include volume of information, type of service (e.g. browsing or VTC) , call set up cost,
minimum call cost and time related charges.



7.7.5.        Real time calculation and display of cost

This sub-function works as previous sub-function except that the time really elapsed is one of
the factor on which the estimation is based.



7.7.6.        Record call cost

Following completion of a call the actual costs are calculated. This will use bearer specific
cost information (e.g. set up charge, per minute cost) and knowledge of the call characteristics
(e.g. destination called, duration) to calculate the cost which is then recorded in the system
database for accounting purposes.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                 Page 100
COMMAN / D4.1 Functional Specifications



8 - Open Issues

8.1      Databases

On a system such as the COMMAN system, a huge database is mandatory to support all the
information necessary for the use of the communication manager. In fact, we can distinguish
two different types of data. First, the administrative data that are used for the communication
management and the “useful” data, that is to say information directly useable.

On a general point of view, it is desirable that all the users can access to most of the data
stored in the database however, a strict control of the updates of its content has to be
performed. We recommend to chose the simplest and safest solution. Only the administrator
of the COMMAN SDN should have the rights to change the content of the database. This will
ensure a best reliability of the information stored. The administrator will have the right to
modify all the parameters and data except the cost of communications and the records of calls.

Following, we have listed the different types of data stored on the Single Data Node. For each
of those categories, all the parameters and data can‟t be listed since it would be an endless
enumeration; nevertheless, we will describe as precisely as possible the different kind of data
stored in each category.


8.1.1.        Messages database

This sub-database is probably the most important one since it stores all the messages
exchanges and the relevant information. As most of the casual applications, the database will
enable the registration of :
 The messages sent
 The messages received
 The messages deleted
 The message currently queued


To be more specific, for each message, several information will be available, such as :
 The sender
 The addressees
 The time of sending
 The importance level
 The confidentiality level


Concerning the queue, as said before, it is stored in this database. The system accesses to this
database and updates it when a new message is queued or when a message queued has been
sent.




8.1.2.        Management database

The management database stores all the data useful for the communication management and
for the system management. The most important categories concern system access
management and bearer management.


TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                Page 101
COMMAN / D4.1 Functional Specifications




8.1.2.1.            System access management

It is obvious that the system access management is a key point of the security and of the
control of the SDN. Consequently, the database has to store relevant information that will
enable the system access management.

More concretely, this database will be useful:
        To insure a good security level.
        To keep an historic of all the events (on a low level point of view: connections
           and on a higher point of view: events).
        To monitor the use of the bearers by the different users.
        To enable a precise billing of the communications.



Concerning the more specific problem of rights. All the users (onboard or ashore) will be
declared and their rights will be defined. We recommend that the administrator has all the
rights (read, write, execute) and all the other users would have only some limited rights on
reading (database content) and execute (communications).


   All the IP addresses, allowed to access to the SDN, will be stored by the system.
   All the users with their corresponding rights will be registered in the database. It means
    that only the user registered will have the right to access directly or remotely to the Single
    Data Node. To be more concrete, a user will be allowed to connect to the COMMAN
    SDN if he is registered as a user and if its IP address is also allowed by the system.
   Each connection (IP or non-IP) will be registered specifying all the necessary information
    such as the user, the destination, the duration, etc…
   Then, directly linked to the previous data, the storage of each invoice will be supplied.
   More generally, all the events will be stored in this database. They will be classified will
    all the casual corresponding parameters (time, user, type of event, etc…).



8.1.2.2.            Bearers management

The bearer management constitutes also an important point of the information that have to be
stored since the bearer management deals with two different layers : the connection layer (all
the information useful for enabling efficient connections are required) and the scheduling
layer because the connections to bearers generate costs that must be controlled and minimised
if possible.


   The cost schedule of the different bearers will be stored. This will be a key data that will
    be used for the Scheduler. Of course, the cost for each bearer will be detailed according to
    the different period of the day. Those information are likely to be updated regularly since
    those costs can change.
   The cost location will also be necessary because the cost also vary according to the
    location. This database will specify the costs according to the different areas of the globe.
   Then, the bearer configuration will be necessary to determine the configuration of the
    bearers available to the COMMAN server. For instance, the transmission rate will be
    explicitly stored here.


TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                  Page 102
COMMAN / D4.1 Functional Specifications

   The availability Schedule of the bearers will also be useful to define when each bearer is
    available. This will be a key information for the scheduling of the communications that
    will be provided thanks to precise and regularly updated sailing plans. We assume that the
    COMMAN system will have at one‟s disposal a database that will store all the bearers
    available at each location and the system will update this database every day, in
    comparing the bearers stored in the database with the ones it sees at any moment. If the
    passage plans are maintained by ships staff and/or direct GPS input, then accurate
    predictions can be made of when bearers will become available.




8.1.3.       Entity-Relationship Model

The E-R model is shown as sub-sets of the total E-R model, each subset depicting some
essential functionality.
Only attributes and relationships relevant for the different subsets are shown.



8.1.3.1.           Request for Establishment and Use of Connection




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                              Page 103
COMMAN / D4.1 Functional Specifications


                                                                           is
                                                                                             Bearer
                                                                         1..n
                                                                                -Equipment Id : string
                           have 1                                               -Bearer Class Id : id
                                                                                -Bandwidth : kps
                                                                                -WithinRange : boolean
                        Bearer Class                                            -SignalStrength : dB
satisfies                                                            used by    -InUse : boolean
                                                                                -CurrentConnectionType : string
    1..n    -Bearer Class Id : id                                          1
            -Performance : QoS/ToS attributes


      used by 1


              1..n uses
                                           1
                    ISP Connection         uses                             ISP

                   -Connection Id : id                              -ISP Id : id
                   -ISP Id : id                                     -Name : string
                                           to                1
                   -Bearer Class : id                               -ISP address : string
                                           0..n             has
               for 1                                                        Legend (example):
                                                                                       ISP has 0..n Connections (to us)
                                                                                       A connection is to 1 ISP



                   1 via
                                           used by                1..n
                   Active Connection       0..n               uses        User Account

                   -Connection Id : id                establishes
                   -ISP Id : id            0..n
                                                                    1
                                           established by                       1 requests




              1          Connection Requirement              1

    satisfied by     -Performance : QoS/ToS attributes       requested by




               Figure 39                 E-R – Request, Establishment, and Use of Connection

Request for Connection
1. A request for a Connection is done for a User Account.
2. A negotiation is performed to find a Bearer Class that satisfies the Connection
   requirements.
3. A Bearer of the selected Bearer Class with available capacity (including free) is selected.
4. The Bearer Connection is established (dialup to IS address)
5. A Network (ISP) Connection is established on the Bearer (using PPP)
6. The Network (ISP) Connection is associated with the ISP.
7. The Network (ISP) Connection is registered as an Active Connection established by the
   requesting User Account.



TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                                            Page 104
COMMAN / D4.1 Functional Specifications

Use Connection
1. A User Account starts an Application.
2. The Application produces IP-packets (for the Active Connection).



8.1.3.2.            Users (Accounts) and Groups




                           User Account                                            UserGroup
                                               0..n                 includes
                         -User Id : id                                         -GroupId : id
                         -ISP Id : id          belongs to               1..n   -Adm.right : id
     allowedCOnnection   -User Name : string                                   -Comm.right : id
                         -Password : string




                                                                                       ISP

                                                                               -ISP Id : id
                                                                               -Name : string
                                                                               -ISP address : string


                  1..n                                                         1

                           UserConnection          via

                         -ISP : id
                         -CnnectionType : string




                             Figure 40             E-R – Users and Groups


A User Account belongs to on or more User Groups with defined Administrative and
Communication Rights.
A User Account is allowed Connection on 1 or more User Connections, each via one specific
ISP.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                            Page 105
COMMAN / D4.1 Functional Specifications

8.1.3.3.               Bearer Availability Forecast



                                                             CostPeriod
              Bearer
                                                        -id : id
                                                        -start : Time
       -Equipment Id : string
                                                        -end : Time
       -Bearer Class Id : id
                                                        -cost : EUR

                     has   1
                                                      1..n   belongs to




                           Figure 41    E-R - Bearer Availibility Forecast

A Bearer is associated with 1 or more forecasted Cost Periods describing availability and cost
of usage for the current vessel route.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                              Page 106
COMMAN / D4.1 Functional Specifications

8.1.3.4.             Transmission Forecast



                                                                                        Bearer

            possibleTime 1
                                for

            Transmission        0..n                                                              1 used in

                                for
                                                              0..n   for
                                0..n
                                                                 TransmissionForecast

                                                               -Bearer : id                0..n
                                                               -Start : Time
                                                               -End : Time                 uses
                                                               -EstimatedBandWidth : kps
                                                               -EstimatedCost : EUR




                                                   0..1 performed in
                                0..1

             Message            transmitted in         OnLineSession

       -Id : id                            requires   -Type : sessiontype
       -MailServrMsgID : long   requires




                                1                 1


                             CDR - COMMAN Delivery Requirement




                           Figure 42             E-R - Transmission Forecast


Each Message and OnLine Session will be attempted transmitted/performed in 1 or more
Transmissions. A Transmission may take place at 0 or more possible Times as described in a
Transmission Forecast. Each Transmission Forecast uses one specific Bearer. (The Bearer
Availability Forecast, not shown here, is used to find the possible Transmission Forecasts).




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                               Page 107
COMMAN / D4.1 Functional Specifications

8.1.3.5.                Communication Accounting


                          via 0..n                                               1 used for

                                     by
              Transmission                                                              Bearer
                                     0..n
           -Id : id
           -ResultOK : boolean
           -BearerUsed : id          for
           -Start : Time
           -End : Time               0..n
           -Volume : long
           -TransmittingUser : id
           -ActualTime : seconds                                     1 has performed
                                     for
           -ActualCost : EUR
                                     0..n
                                                                         User Account




                                                     0..1 performed in
                                0..1

                Message         transmitted in          OnLineSession




                           Figure 43             E-R - Communication Accounting


All Transmissions (successful or not) are registered and associated with a Message or OnLine
Session, the User Account, and the Bearer used.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                           Page 108
COMMAN / D4.1 Functional Specifications

8.1.3.6.               COMMAN Delivery Requirements

This is the COMMAN extended QoS parameters (CDR – COMMAN Delivery
Requirements). CDRs are used for all types of outbound communication, and may be used to
restrict inbound communications.



         CDR - COMMAN Delivery Requirement

         -Priority : %
         -EarliestDeliveryTime : Time
         -LatestDeliveryTime : Time
         -MinBandWidth : kps
         -MaxTransmissionCost : EUR




                       Figure 44:       E-R – COMMAN Delivery requirement




8.1.4.          General data

During the communications, a lot of identification information is exchanged repeatedly that
can be attached to the messages as an automatic header or as an attached document. This
information covers :
 Ship identification
 Cargo Identification
 Crew identification
 Journey Identification


This information will have to be stored in the database shared by the applications. Annex 9.2
displays the information exchanged for each type of communication.



8.2        Security

Note : This part discusses issues rather than solutions. The security aspects of COMMAN
will be better defined in the further phases of the project. Indeed, if the threats remain the
same on the whole, the way they can attack a system and the means of protection may have
rapidly evolved one year from now.


8.2.1.          The security needs
It is necessary that some kind of security statements be undertaken for the COMMAN SDN
because it connects to ship critical systems and commercially sensitive data.
It is thought that if we start by defining the data, connections, users and attackers this will
help to consider what functionality is demanded of the security system and the security sub-
functions.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                               Page 109
COMMAN / D4.1 Functional Specifications

                    Data                                            Sensitivity
Ships position                                    Commercially sensitive
Ships cargo                                       Commercially sensitive
ETA                                               Commercially sensitive
ETD                                               Commercially sensitive
Emails                                            Commercially sensitive
                                                  Personally sensitive
Accounts                                          Management sensitive
Configuration                                     Management sensitive

The types of attacks that the COMMAN ships systems are likely to face are:
 Hacking for data from system (email or in the database/system files) resulting in
   commercial espionage
 Hacking to the ships system (ECDIS or engine control) resulting in industrial sabotage
 Denial of service attacks resulting in commercial sabotage.


These attacks can come from:
 Users on the ship
 Users at the shore network
 Passengers on the ship
 External to the shore network persons



This can represented on a matrix:

  Type of attack           To obtain data           To attack system        To deny service
USER                                             Likelihood and numbers
User on the ship         High but low       in    Low and low in          Low and low in
                         number                   number6                 number7
Users at the shore       High but medium    in    Medium but low in       Medium and medium
network                  number                   number8                 in number
Passengers on the        High and high      in    High and high in        Medium and high in
ship                     number                   number9                 number
External to the shore    High and high      in    Medium and medium       High but medium in
network          (i.e.   number                   in number10             number
anonymous        web
attack)


The tasks being performed by the system can be assessed to see who they might be attacked
from and what level of protection the should be afforded.
Level of security is:
(C)ommercial implications

6
  It is assumed that most people would be cautious about risking themselves by attacking the
ships systems while aboard.
7
   It is assumed that resources are simply difficult to obtain aboard ship to mount these kinds
of attacks and they are also very noticeable.
8
    It is assumed that people with a direct connection to the company might have more
reservations about attacking safety critical systems.
9
    It is assumed that passengers might do so as they have less respect for the maritime
environment that they are operating in.
10
    Most hackers on the internet aim to gather data (or merely crack the system) the number of
malicious attacks are low.

TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                               Page 110
COMMAN / D4.1 Functional Specifications

(S)aftey implications
(N)o implications


          Outgoing Communications                     Level of
                                                      security
Ship tracking                                            C
Declare entrance into the VTS area                       C
Announce hazardous goods
Distant survey                                           C
Remote Damage Survey                                     C
Remote Surveillance of Safety Critical                   S
Operations
Ice patrol reports                                       N
Sending the ETA                                          C
Sending the ETD                                          C
Send sailing plan                                        C
Sending of load maps plan                                C
AMVER reporting                                          S
Cargo handling, loading, discharging                     C
Cargo management                                         C
Slop discharge                                           N
Garbage-cargo handling                                   N
Access to tourist information                            N
Announce arrival                                         N
Logistics machine                                        C
Logistics husbandry, supplies                            C
Message to the agent                                     C
Money order                                              C
Catering for crew and passengers                         N
Immigration authority                                    N
Agriculture authority                                    N
Medical authority                                        N
Sending of the list of crew, the licences, …             C
Office facilities                                        N
Ice messages                                             N
Ice warnings                                             N
Mayday/PAN/medical Service                               N
Fire fighting, safety                                    S
SAR                                                      N
Get real-time position information from vessels          C


 Incoming Communication           Level of security
Make ECDIS update                        S
Weather forecasts                        N
Entertainment                            N
General information about the            N
port
Access to tourist information            N
Generic                incoming
communications :

TR4006/D4.1/EUTELIS/6/8/99/version 1.3                           Page 111
     COMMAN / D4.1 Functional Specifications

        Incoming e-mail                   N
        Incoming fax                      N
        Incoming telex                    N
        Incoming ...                      N


 Bi-directional Communications Level of
                               Security
Import/ Export of ISM code        C
relevant messages or forms
Customs                           C
Medical service                   N
Shore based pilotage             CS
Shore based radar assistance      S
Port entry guide                  S
Ship-ship communication           S
Phone boxes                       N
Personal Communications           N
Virtual Round Tables             CS
Distant learning and general      N
education
Remote maintenance               CS
Web access                        N
Remote access to databases       CS
Secured payments                 CS
Remote network management        CS
Remote access to COMMAN          CS
system




     TR4006/D4.1/EUTELIS/6/8/99/version 1.3    Page 112
COMMAN / D4.1 Functional Specifications




                                                                                                               Compa
                                                                                                               ny
                                                                                                               Shore
                                                                                                               networ
                                                                                                               kISP
    Crew

                                                                        COMMAN                                 VTS
                                                                          SDN                                  service
                                            Firewall                                                           s
   Passengers                                                                                          BEARE
                                                                                                               Fax
                                                                                                       RS

                                                                                                               Voice


                                                                                                               Ships


                            Ship
                            contr                              Light blue is security needed but low
                            ol                                 Orange is security needed high
                            syste                              Yellow is security needed but medium
                                                               high
                            ms
                                                               Purple is critical area




                                          Figure 45 : Level of security in the COMMAN system




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                                         Page 113
COMMAN / D4.1 Functional Specifications




8.2.2.        Requirements for the COMMAN firewall

8.2.2.1.            General considerations
A firewall is a set of related programs, located at the network gateway server, that protects the
resources of the private network from users from other networks. Basically, a firewall, working
closely with a router program, filters all network packets to determine whether to forward them
toward their destination. There are a number of firewall screening methods. A simple one is to
screen requests to make sure they come from acceptable (previously identified) domain names
and IP addresses.

Conceptually, there are two types of firewalls
   1. Network Level
   2. Application Level

However latest technologies are blurring the distinction.


Network level firewalls generally make their decisions based on the source, destination
addresses and ports in individual IP packets. A simple router is the "traditional" network level
firewall, since it is not able to make particularly sophisticated decisions about what a packet is
actually talking to or where it actually came from. Modern network level firewalls have become
increasingly sophisticated, and now maintain internal information about the state of connections
passing through them, the contents of some of the data streams, and so on. An important
distinction about many network level firewalls is that they route traffic directly though them, so
to use one you usually need to have a validly assigned IP address block. Network level firewalls
tend to be very fast and tend to be very transparent to users.

Application level firewalls generally are hosts running proxy servers, which permit no traffic
directly between networks, and which perform elaborate logging and auditing of traffic passing
through them. Since the proxy applications are software components running on the firewall, it
is a good place to do lots of logging and access control. Having an application in the way in
some cases may impact performance and may make the firewall less transparent. Modern
application level firewalls are often fully transparent. Application level firewalls tend to provide
more detailed audit reports and tend to enforce more conservative security models than network
level firewalls.

The Future of firewalls lies someplace between network level firewalls and application level
firewalls. It is likely that network level firewalls will become increasingly "aware" of the
information going through them, and application level firewalls will become increasingly "low
level" and transparent. The end result will be a fast packet-screening system that logs and audits
data as it passes through. Increasingly, firewalls (network and application layer) incorporate
encryption so that they may protect traffic passing between them over the Internet. Firewalls
with end-to-end encryption can be used by organizations with multiple points of Internet
connectivity to use the Internet as a "private backbone" without worrying about their data or
passwords being sniffed.


8.2.2.2.            Requirements for the COMMAN firewall

     The firewall will be able to support a ``deny all services except those specifically
      permitted'' design policy, even if that is not the policy used.


TR4006/D4.1/EUTELIS/6/8/99/version 1.3
                                     Page 115
COMMAN / D4.1 Functional Specifications



     The firewall will be flexible; it will be able to accommodate new services and needs if
        the security policy of the organization changes.
     The firewall will contain advanced authentication measures or will contain the hooks for
        installing advanced authentication measures.
     The firewall will employ filtering techniques to permit or deny services to specified host
        systems as needed.
     The IP filtering language will be flexible, user-friendly to program, and will filter on as
        many attributes as possible, including source and destination IP address, protocol type,
        source and destination TCP/UDP port, and inbound and outbound interface.
     The firewall will use proxy services for services such as FTP and TELNET, so that
        advanced authentication measures can be employed and centralized at the firewall. If
        services such as NNTP, X, http, or gopher are required, the firewall will contain the
        corresponding proxy services.
     The firewall will contain the ability to centralize SMTP access, to reduce direct SMTP
        connections between site and remote systems. This results in centralized handling of
        site e-mail.
     The firewall will contain mechanisms for logging traffic and suspicious activity, and
        will contain mechanisms for log reduction so that logs are readable and understandable.
     If the firewall requires an operating system such as UNIX, a secured version of the
        operating system will be part of the firewall, with other security tools as necessary to
        ensure firewall host integrity.
The firewall and any corresponding operating system will be updated with patches and other
bug fixes in a timely manner.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3
                                     Page 116
COMMAN / D4.1 Functional Specifications




9 - Illustration of the functionality

To finish this presentation of the different features provided by the COMMAN Single Data
Node, it is useful to try to illustrate them in real situations. Here are presented two scenarios that
were submitted to potential users (phase 5 of the methodology). Those scenarios present
sequences of events and the corresponding features that the system will support to solve each
problem.

Those two scenarios have been amended by the users contacted. Consequently, it means that the
working of the COMMAN system has been evaluated through its functionality and the users
have had a good feedback about it. Indeed, those scenarios give a more precise idea of the real
service that will be provided.


The first scenario concerns an incident involving a collision between a ro-ro passenger ferry and
a cargo vessel. The second scenario concerns a more casual that involves a cruise ship.



9.1       1st scenario: The collision


Context

1. The incident involves the transit of a Dutch ro-ro passenger ferry and its subsequent
   collision with a Greek cargo vessel. The collision has been caused by poor navigation
   judgement combined with a steering problem in the cargo vessel.

2. The passenger ferry is carrying some 450 passengers, 90 crew and a mixture of goods
   vehicles and private cars. The cargo vessel is carrying 8 crew and is loaded with a mixed
   cargo which includes hazardous goods (a small number of containers on deck contain a
   variety of inert manufactured goods and a small number of drums, also in the container
   space contain weedkiller). The Greek Master of the cargo vessel speaks minimal English.

3. Conditions at the time of the incident are poor but stable. Visibility is 150yds with a north
   westerly 25kt wind and driving. Tides are at springs and that is a south westerly set at
   1.6kts. It is 2am on a Sunday morning in winter and the air temperature is approximately
   2C. The sea state is 5.

4. The location of the incident is 30nm offshore from a busy port in the Southern North Sea.
   This is outside the VTS area and on the edge of VHF range.

5. There are four communication bearers available for ship-shore communication. Once
   GMDSS is used, three of those four become unavailable for use.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3
                                     Page 117
COMMAN / D4.1 Functional Specifications



Events

1.   The passenger ferry, currently 30nm offshore is transiting towards port. The following
     activities are ongoing:

     a) Credit card transactions in the duty free shopping area as passengers make their final
          purchases before arrival.
     b) Phone calls made by passengers and crew to families ashore to inform them of their
          arrival time.
     c) Internet access by crew to gather port information and weather data.
     d) Email communication between ferry and port.

2.      The ferry is about to overtake a cargo vessel also heading for the port. A sandbank
     limits the space available for overtaking.

3.      The Master of the ferry notices unpredictable movements on the part of the cargo vessel
     and plans to change course to avoid an incident.

4.   However, before this plan can be put into effect, the Master of the cargo vessel sends a
     distress call via GMDSS on Channel 70. He reports a steering problem to the Coastguard
     Operations room and requests urgent tug assistance.

5.   The Coastguard Operations Officer requests further information from the cargo vessel
     relating to the distress call i.e. cargo manifest, crew and whether there are other vessels in
     the immediate vicinity.

6.   The cargo vessel begins to swing into the path of the ferry, which is already passing close
     by and is unable to divert its course sufficiently to avoid a collision with the cargo vessel
     which is out of control.

7.   The Master of the passenger ferry reports a distress call via GMDSS on Channel 70. He
     states a collision has occurred with the cargo vessel. The two vessels become locked
     together. No casualties are reported at this time.

8.   The Masters of the two vessels contact their respective owners to inform them of the
     incident. The Master of the passenger ferry immediately informs the emergency services
     and requests tug assistance from ashore. The Master of the cargo vessel requests advice
     from the owner on what action to take. After some delay the cargo ship owner advises the
     Master to inform the emergency services.

9.   The Coastguard Operations Officer requests further information from the passenger ferry
     relating to the distress call i.e. passenger manifest, crew and so on.

10. All other staff in the Coastguard Operations room are alerted, an Incident Room is set up
    on-site and the National Contingency Plan initiated.

11. The Operations Staff assess the implications of the incident.

12. All Coastguard staff on-call are called in for duty.

13. The emergency radio channel is nominated and all vessels instructed to listen in and assist
    where necessary.


TR4006/D4.1/EUTELIS/6/8/99/version 1.3
                                     Page 118
COMMAN / D4.1 Functional Specifications



14. The Coastguard Operations staff contact all organisations according to their National
    Incident Plan. These would include the Emergency Services, Environmental organisation,
    Marine Pollution organisation, hospitals, local and national authorities, media (as
    necessary). They would also inform adjacent countries (i.e. France, Belgium, Netherlands)
    as appropriate on the understanding that some International co-ordination may be required.
    Military rescue centres may be requested to be on standby for SAR assistance.

15. The Emergency Services send liaison officers to the Incident Room to assist with the
    control of the incident.

16. The Coastguard Operations team maintains contact with the two vessels involved by radio
    to obtain frequent situation reports.

17. The two vessels maintain frequent stability calculations on the state of their vessels and
    make predictions on compartment flooding. For the cargo vessel this is done on-board and
    for the passenger ferry this is done ashore.

18. Reports on the operational state of the vessels are sent back to the Incident Room and
    remote diagnostic checks carried out where necessary. These reports are also sent to the
    vessel owners/agents.

19. Communications overload is induced by a large number of passengers on the ferry using
    GSM mobile phones and the phones on board the ferry to contact their families.

20. The Master of the cargo vessels notices that one of the drums containing weedkiller on
    board the cargo vessel is damaged. Sea water has got into the drum and a mix of the two is
    currently leaking out into the water, thus creating a significant hazard.

21. The Master of the cargo ship contacts the ship owner to ask for advice on the damaged
    drum. After some delay the ship owner advises the Master to inform the emergency
    services.

22. The Coastguard is informed of the leakage of weedkiller into the water by the cargo vessel
    and in turn informs the fire brigade.

23. One of the crew aboard the cargo vessel becomes caught in a rope and suffers leg and arm
    injuries as a result. Advice as to the treatment of the casualties is requested by the vessel
    and provided from ashore.

24. The appointed on-scene officer in charge flies to the incident site via helicopter in order to
    report the situation directly back to the Operations room via radio. Representatives from
    each of the emergency services will join the on-scene officer. It may be necessary for on-
    scene controllers to access detailed technical information regarding the vessels for the
    purpose of fire-fighting etc.

25. When on-call staff arrive at the Coastguard Operations room, they are instructed to assist in
    manning all lines of communication, calling up other craft to assist, controlling the safe
    movement of other vessels in the vicinity.

26. The Masters of the two vessels are responsible for the evacuation of crew and passengers
    on their own vessels. They liaise with the on-scene officer in charge to achieve this.
    Evacuation takes place mainly by civilian helicopters (UK, French, Belgian, Dutch SAR)


TR4006/D4.1/EUTELIS/6/8/99/version 1.3
                                     Page 119
COMMAN / D4.1 Functional Specifications



      and military helicopters. Other vessels in the vicinity are also required to assist by
      deploying lifeboats.

27. The movement and accommodation of evacuees is controlled as per the Contingency Plan.
    Constant communication is still required between the Operations room and the emergency
    services. Everybody must be accounted for.

28. An appointed spokesman is responsible for making press statements throughout the
    incident through a media centre located outside the immediate vicinity of the Incident
    Room. The airspace around the site of the incident is becoming increasingly busy with both
    rescue and media helicopters, and air traffic frequencies are congested, making airspace
    control a problem.



9.2       2nd scenario: The cruise

Context

1. The cruise involves a liner belonging to a french (?) shipping company, making an x days
   journey through the Greek islands.
2. The liner is carrying x passengers, x crew.
3. The size of the liner ?


(All these details must pass the test of realism. This will be detailed later, when the cruise
company, that will be interviewed, will be known)




Events

Departure of the cruise

1. Sending the ETD : The ship is still mooring and is about to start and the captain sends via
   VHF the Estimated Time of Departure to the agent in the port to confirm the time of
   departure.

2. Weather forecasts : The captain wants to ask about the weather to prepare his sailing plan.
   So, he requests by GSM the agent to have the latest information about the weather.

3. Sending the sailing plan : Sailing plans are sent as well because the maritime company
   wants to be informed of the precise route of the ship. This file is transferred to the agent in
   the port via e-mail.

4. Shore based pilotage : The ship is gone from the port and to navigate in the area close to
   the port, a pilot ashore gives him advises in real time. To do so, a VHF connection is
   established between the boat leaving the port and the pilotage station.

5. Declare entrance into VTS area : The ship enters quickly into a new VTS area and sends a
   message by telex to the VTS to inform it of its presence and provide casual information :
   port of departure, port of arrival, name of the ship and nationality.

TR4006/D4.1/EUTELIS/6/8/99/version 1.3
                                     Page 120
COMMAN / D4.1 Functional Specifications




During the cruise
   Before the call

6. Phone boxes : People want to inform their relatives that they have taken on board and that
   everything goes well. Phone boxes offering a credit card billing are available and everyone
   can have access to them. Several options are available (access to terrestrial networks or to
   satellite networks) but since the cruise goes along the Greek coast, the communications are
   supported by GSM networks.

7. Payment at the Duty-Free shop : As on most ships, a duty-free shop is available to buy
   several goods at low rate. But the passengers come from several different countries so every
   currency can not be accepted. That‟s why payment with credit card is recommended. During
   every transaction, the bank account of the customer is checked to be sure that the payment
   can really be done.

8. ECDIS update : The captain, so as to navigate in a more secure way, uses ECDIS charts.
   As every week, he connects the COMMAN Single Data Node to its company‟s server and
   requests for a download of the update of those charts. Since this transfer is very expensive,
   the download is executed when the cost of the communication is lower (during the night by
   instance).

9. Food order : The restaurant of the ship only serve high quality food, fresh products can‟t be
   kept onboard for a long time; that‟s why fresh food is loaded at each call during the cruise.
   Consequently, the purser sends a request by e-mail to the agent in the next port of call to
   order some food that will be loaded during the next call.

10. Office facilities : Some of the passengers are businessmen that need to be in contact with
    their office. That‟s why a fax and a PC with Internet connection is available; the billing is
    done on the personal invoice of each passenger.

11. Health matter : During the travel, one person suddenly complains of a violent pain in the
    belly. He is taken into the doctor that diagnoses an appendicitis. To be sure, he organises a
    Netmeeting with an hospital ashore to confirm his diagnosis. During this meeting, the
    hospital confirms the diagnosis and that the appendicitis is very acute; so an immediate
    evacuation is required.

12. Evacuation :. The captain contacts by phone the Coast Guards to inform them that a
    passenger needs to be evacuated urgently; he transmits all the necessary information
    including the position of the ship. The evacuation of the passenger is organised by
    helicopter because the ship is too far away from the coasts. At the helicopter draw near, a
    direct telephone connection is established between the captain and the helicopter to organise
    the evacuation procedures.

13. Tourist database access : So as to prepare the next call that will last 2 days, the passengers
    want to be informed of the tourist information. They can access to a local database that
    registers and displays via a Web interface, all the information concerning tourism for the
    region. Hotel‟s bedroom booking is also possible from this access.

14. Ship tracking : During all the cruise, the ship transfers by email to the company its own
    position every 4 hours. However, the company, that wants to be informed of the arrival of

TR4006/D4.1/EUTELIS/6/8/99/version 1.3
                                     Page 121
COMMAN / D4.1 Functional Specifications



    the ship in the port of call, makes a request for the position of the ship. Immediately, the
    captain sends by e-mail its current position.


15. Call in a foreign country : The call is made in a foreign country so several mandatory
    procedures are followed. To limit the time of wait of the passengers in the port, the captain
    sends by telex the most important information : the manifest, the list and identities of
    passengers, the list of vaccinations.
    After the call

16. Entrance into VTS area : The ship leaves the port after the call and enters in a new VTS
    area without knowing its existence. The VTS master asks the ship to identify itself. The
    captain then contact him by VHF if possible to provide him the casual information.

17. Bad weather : After receiving the latest weather forecasts by fax, the captain requests his
    company to send him by email a satellite picture to have precise information. After
    receiving the satellite picture, the captain decides to modify the route of the ship.
    Consequently, information are sent to the agent in the next port of call : sailing plan, ETA.

18. Ship passing around : As a consequence of the change of route, the captain has chosen to
    go along an island which is very frequented place. Sailing along the island, the ship pass
    other ships. With the help of AIS, the captain can localise his ship the other ships in real
    time; to avoid any misunderstanding and to agree on passing manoeuvres, the captain
    contacts directly the other close ships via VHF.

19. Mechanical breakdown : After this event, the ship puts to sea to follow the new planed
    route. During this period, the engine of the ship breaks down and the ship stops. The
    mechanic tries to repair the engine but he does not succeed so he contacts by phone the
    mechanical engineer to have advises. So as to be more efficient, the mechanic onboard
    opens a Whiteboarding session and a Netmeeting session to try to provide a distant repair.
    Finally, the engineer and the mechanic achieve to repair the engine and the ship can set off
    again. Due to this delay, the captain sends again the ETA by email to the agent in the next
    port. The mechanic orders by telex the mechanical parts to the agent in the port.

20. Personal communications : The ship has been delayed a lot due to the weather conditions
    and to this mechanical problem, so some members of the crew wish to inform their relatives
    of this delay. They use onboard phones on which they have personal accounts that allow
    them to phone with a fixed dedicated credit for each of them.

21. Supply check with the agent : The ship master exchanges faxes or e-mail with the agent to
    recapitulate the ship needs in food and other goods and the time of delivery.

22. Change of passengers for the next cruise : The ship master receives by fax a message
    indicating that two new passengers are expected for the next cruise. The captain updates his
    onboard database and the captain accesses remotely to the company database to check that
    he has now the same list of passengers than the list of the company.

23. Announce arrival : The cruise is about to finish so the captain announces to the agent by
    email the arrival of the ship in the port of arrival.

24. Port entry guide : VHF communication between the local pilot, the port agent and the
    harbour VTS to guide the ship during its approach and berthing manoeuvre.


TR4006/D4.1/EUTELIS/6/8/99/version 1.3
                                     Page 122
COMMAN / D4.1 Functional Specifications




TR4006/D4.1/EUTELIS/6/8/99/version 1.3
                                     Page 123
COMMAN / D4.1 Functional Specifications




10 - Glossary

AIS             Automatic Identification Systems (AIS) use radio transponders permanently
                installed or carried on board specified vessels to broadcast important data such
                as: vessel identification, GPS/DGPS position, course, speed, navigation status,
                dimensions, or cargo. Combined with a shipboard display capability, AIS
                presents critical navigation and vessel traffic information to the bridge team.


Application     1. A telematics system or service as installed and operating in a real-life
                environment.
                2. In information technology, the term application is a shorter form of
                application program. An application program is a program designed to
                perform a specific function directly for the user or, in some cases, for another
                application program. Examples of applications include word processors,
                database programs, Web browsers, development tools, drawing, paint, and
                image editing programs, and communication programs.


Bearer        The telecommunication service that provides the capability of transmission of
              signals between access points.

CDR           COMMAN Delivery Requirements – extended QoS

Communication tasks tasks undertaken on a ship that imply a communication with the shore
            or with another ship. Nowadays they are often performed with current means
            (fax, voice…), but COMMAN can have an impact on the way they are
            undertaken.

Connection     An established link between tow or more peer level entities.

DECT          DECT (Digital Enhanced Cordless Telecommunications) is a digital wireless
              telephone technology that is expected to make cordless phones much more
              common in both businesses and homes in the future. Formerly called the Digital
              European Cordless Telecommunications standard because it was developed by
              European companies, DECT's new name reflects its global acceptance. Like
              another important wireless standard, GSM, DECT uses time division multiple
              access (TDMA) to transmit radio signals to phones. Whereas GSM is optimized
              for mobile travel over large areas, DECT is designed especially for a smaller
              area with a large number of users, such as in cities and corporate complexes. A
              user can have a telephone equipped for both GSM and DECT (this is known as
              a dual-mode phone) and they can operate seamlessly.

ECDIS         Electronic Chart Display System.

Feature        an elementary characteristic. We generally use the term “feature” to design a
              capability of COMMAN that, contrary to sub-functions, doesn‟t intervene in the
              sending or receiving of a communication.



TR4006/D4.1/EUTELIS/6/8/99/version 1.3
                                     Page 124
COMMAN / D4.1 Functional Specifications



Functionality The capabilities or behaviours of a program, part of a program or system, seen
              as the sum of its features. Roughly, "the things it can do".

GSM                     GSM (Global System for Mobile communication) is a digital mobile
               telephone system that is widely used in Europe and other parts of the world.
               GSM uses a variation of time division multiple access (TDMA) and is the most
               widely used of the three digital wireless telephone technologies (TDMA, GSM,
               and CDMA). GSM digitizes and compresses data, then sends it down a channel
               with two other streams of user data, each in its own time slot. It operates at
               either the 900 MHz or 1800 MHz frequency band.


GEO            Geostationary Earth Orbit.

IMT 2000       IMT-2000.is an initiative of the International Telecommunication Union to
               provide wireless access to the global telecommunication infrastructure through
               both satellite and terrestrial systems, serving fixed and mobile users in public
               and private networks. It is being developed on the basis of the 'family of
               systems' concept, defined as a federation of systems providing.IMT-
               2000.service capabilities to users of all family members in a global roaming
               offering.


IP             The Internet Protocol (IP) is the method or protocol by which data is sent from
               one computer to another on the Internet. Each computer (known as a host) on
               the Internet has at least one address that uniquely identifies it from all other
               computers on the Internet. When one sends or receives data (for example, an e-
               mail note or a Web page), the message gets divided into packets. Each of these
               packets contains both the sender's Internet address and the receiver's address.
               Any packet is sent first to a gateway computer that understands a small part of
               the Internet. The gateway computer reads the destination address and forwards
               the packet to an adjacent gateway that in turn reads the destination address and
               so forth across the Internet until one gateway recognizes the packet as belonging
               to a computer within its immediate neighborhood or domain. That gateway then
               forwards the packet directly to the computer whose address is specified.
               Because a message is divided into a number of packets, each packet can, if
               necessary, be sent by a different route across the Internet. Packets can arrive in a
               different order than the order they were sent in. The Internet Protocol just
               delivers them. It's up to another protocol, the Transmission Control Protocol
               (TCP) to put them back in the right order.


ISC            Integrated Ship Control

LEO            Low earth orbit. Satellite systems with orbits anywhere from 250 to several
               hundred miles high.

Minimum charge minimum incompressible cost of a call. For instance, on some bearers, the
            first minute of the call is due, even if it lasts less than a minute.

QoS            Quality of Service. On the Internet and in other networks, QoS (Quality of
               Service) is the idea that transmission rates, error rates, and other characteristics
               can be measured, improved, and, to some extent, guaranteed in advance. QoS is

TR4006/D4.1/EUTELIS/6/8/99/version 1.3
                                     Page 125
COMMAN / D4.1 Functional Specifications



               of particular concern for the continuous transmission of high-bandwidth video
               and multimedia information. Transmitting this kind of content dependably is
               difficult in public networks using ordinary "best effort" protocols.


SDN            stands for Single Data Node. It means that COMMAN is a “single point of
               access” to all data communication services.

Sub-function elementary part of a communication. Any communication can be decomposed
             in sub-functions performed by the COMMAN system. Sub-functions can handle
             the communication itself (the traffic) or the management of the communication
             (then they allow the data flow to be emitted with a determined quality of
             service).

TETRA          Trans-European Trunked Radio (TETRA) is an open European standard for
               digital radio - designed primarily to meet the requirements of the emergency
               services. It is designed as a professional radio system and as such compliments
               the facilities offered by radio telephony systems such as GSM.


UMTS                    Universal Mobile Telecommunications Service is a third generation
               mobile communication system currently being developed in Europe. It will
               enable terminal mobility and fixed network personal mobility to converged. It
               will also have the capacity to extend to the customer those services and features,
               requiring less than about 2Mb/s, that would otherwise be provided by the fixed
               network.


VHF           Very High Frequency (30-300 MHz)




TR4006/D4.1/EUTELIS/6/8/99/version 1.3
                                     Page 126
COMMAN / D4.1 Functional Specifications




                                11 - ANNEXES




TR4006/D4.1/EUTELIS/6/8/99/version 1.3
                                     Page 127
COMMAN / D4.1 Functional Specifications




I. Use of scenarios to assess the functional specifications

A. Introduction
To end this presentation of the different features provided by the COMMAN Single Data Node,
it is useful to try to illustrate them in real situations. Here are presented two scenarios that were
submitted to potential users (phase 5 of the methodology). Those scenarios present sequences of
events and the corresponding features that the system will support to solve each problem. They
have been developed to assess the use of the COMMAN SDN under different circumstances
onboard different types of vessel.

Those two scenarios have been amended by the users contacted. Consequently, it means that the
working of the COMMAN system has been evaluated through its functionalities and the users
have had a good feedback about it. Indeed, those scenarios give a more precise idea of the real
service that will be provided.

The first scenario concerns an incident involving a collision between a ro-ro passenger ferry and
a cargo vessel. The second scenario concerns a routine passage of a cruise liner.



B. Summary of method
The general method that has been adopted is as follows:
        -   Develop scenario
        -   Obtain user validation of the scenario
        -   Assess the completeness of the functional specification back against the scenarios
        -   Report on the assessment
        -   As necessary, revise the functional specification and reassess it against the scenario.
            (Note the revision of the functional specification is the responsibility of a different
            phase of WP4).


The scenarios are divided into a number of events where the players undertake some form of
activity. These may provide general information about what is happening, define an activity to
be undertaken by a person or a defined requirement to exchange information. It is the latter of
these which is of greatest interest to this process.
The requirement to exchange information may (generally) be voice or data. If it is voice the
COMMAN involvement is limited to providing access to the appropriate bearer and recording
the costs. If the exchange is data, then the real assessment process begins and the functional
specification will provide evidence of the provision of the capability needed to support the
exchange.
During the assessment process assumptions were made regarding the use of the system.
Examples where the method of usage was considered include:
        -   Credit card transactions – is a dialup link used for every transaction (like many
            shops) or are they grouped up and undertaken at intervals?



TR4006/D4.1/EUTELIS/6/8/99/version 1.3
                                     Page 128
COMMAN / D4.1 Functional Specifications



            -   How is the use of bearers for GMDSS going to managed – which of the events
                imply use of bearers within the context of GMDSS?
            -   What end system functionality is assumed? e.g. a PC with video interface, picture
                viewers, VTC software etc.



C. Detailed Assessment Method
The sequence of activities for the review of the functional specification using the scenario is:
i.          Identify those events that COMMAN functionality needs to support.
ii.         Refine the events, through sub-events and activities to define the capabilities required.
iii.        Document any procedural/usage assumptions that have been made.
iv.         Prepare a matrix of applications/sub-functions (from the functional specification) on
            one axis and events/sub-events/activities (from above).
v.          Place ticks (  ) in the matrix where events are supported by applications/sub-functions
vi.         Identify any sub-functions that are unused in the scenario:
       confirm that they are used in the other scenario, if not:
       assess the need for the sub-function, or
       revise the scenario(s) to exercise the particular sub-function, or
       accept that the sub-function will not be validated.
vii.        Walk through each event/sub-event/activity to ensure/assess:
       all required sub-functions are identified, and
       that the descriptions of the sub-functions meet the requirements of the scenario
       the impact of system loading (normal/peak)
viii.       Walk through as above, but imposing „what if … ‟ conditions to test for contingency
            responses.
ix.         Cross check sub-functions to ensure that the requirements imposed by each of the
            events do not impose contradictory or incompatible requirements.



D. Scenario 1 : The Collision

Incident involving a collision between a ro-ro passenger ferry and a cargo vessel

Context
1. The incident involves the transit of a Dutch ro-ro passenger ferry and its subsequent
   collision with a Greek cargo vessel. The collision has been caused by poor navigation
   judgement combined with a steering problem in the cargo vessel.

2. The passenger ferry is carrying some 450 passengers, 90 crew and a mixture of goods
   vehicles and private cars. The cargo vessel is carrying 8 crew and is loaded with a mixed
   cargo which includes hazardous goods (a small number of containers on deck contain a


TR4006/D4.1/EUTELIS/6/8/99/version 1.3
                                     Page 129
COMMAN / D4.1 Functional Specifications



    variety of inert manufactured goods and a small number of drums, also in the container
    space contain weedkiller). The Greek Master of the cargo vessel speaks minimal English.

3. Conditions at the time of the incident are poor but stable. Visibility is 150yds with a north
   westerly 25kt wind and driving. Tides are at springs and that is a south westerly set at
   1.6kts. It is 2am on a Sunday morning in winter and the air temperature is approximately
   2C. The sea state is 5.

5. The location of the incident is 30nm offshore from a busy port in the Southern North Sea.
   This is outside the VTS area and on the edge of VHF range.

5. There are four communication bearers available for ship-shore communication. Once
   GMDSS is used, three of those four become unavailable for use.



Utility

1. Possible implications for COMMAN:
      Bearer selection, prioritisation and least-cost routing
      Data service prioritisation
      Conflict between data and voice communications by radio
      E.mail store and forward
      FTP real-time data
      Limitations of using a single bearer
      Engineering diagnostic reporting (may be voice, whiteboarding, e.mail attachments or
      FTP)
      Telemedicine/medical advice service (may be voice, e.mail attachments or FTP)
      Pictorial SITREPS (may be e.mail attachments or FTP)
      Use of firewalls
      Other security issues
      Connection with airspace control frequencies

2. Other aspects of the context:

    a) Exercises the National and International Contingency Plans.

b) Exercises the ability of the Coastguard to manage and co-ordinate an incident.

    c) Exercises liaison as follows:
         Emergency Service*  Emergency Service
         Emergency Service  Coastguard Operations
         Emergency Service  Ship
         Coastguard Operations  Ship
         Coastguard Operations (UK)  Coastguard Operations (France, Belgium,
         Netherlands as appropriate)
         Coastguard Operations  other organisations as required by the Contingency Plan

        *The Emergency Services in this instance are defined as Fire Brigade, Ambulance and
Police. The Coastguard is identified separately.


Events

TR4006/D4.1/EUTELIS/6/8/99/version 1.3
                                     Page 130
COMMAN / D4.1 Functional Specifications




2.   The passenger ferry, currently 30nm offshore is transiting towards port. The following
     activities are ongoing:

     e) Credit card transactions in the duty free shopping area as passengers make their final
          purchases before arrival.
     f) Phone calls made by passengers and crew to families ashore to inform them of their
          arrival time.
     g) Internet access by crew to gather port information and weather data.
     h) E.mail communication between ferry and port.

4.      The ferry is about to overtake a cargo vessel also heading for the port. A sandbank
     limits the space available for overtaking.

5.      The Master of the ferry notices unpredictable movements on the part of the cargo vessel
     and plans to change course to avoid an incident.

4.   However, before this plan can be put into effect, the Master of the cargo vessel sends a
     distress call via GMDSS on Channel 70. He reports a steering problem to the Coastguard
     Operations room and requests urgent tug assistance.

5.   The Coastguard Operations Officer requests further information from the cargo vessel
     relating to the distress call i.e.cargo manifest, crew and whether there are other vessels in
     the immediate vicinity.

6.   The cargo vessel begins to swing into the path of the ferry, which is already passing close
     by and is unable to divert its course sufficiently to avoid a collision with the cargo vessel
     which is out of control.

7.   The Master of the passenger ferry reports a distress call via GMDSS on Channel 70. He
     states a collision has occurred with the cargo vessel. The two vessels become locked
     together. No casualties are reported at this time.

8.   The Masters of the two vessels contact their respective owners to inform them of the
     incident. The Master of the passenger ferry immediately informs the emergency services
     and requests tug assistance from ashore. The Master of the cargo vessel requests advice
     from the owner on what action to take. After some delay the cargo ship owner advises the
     Master to inform the emergency services.

9.   The Coastguard Operations Officer requests further information from the passenger ferry
     relating to the distress call i.e.passenger manifest, crew and so on.

10. All other staff in the Coastguard Operations room are alerted, an Incident Room is set up
    on-site and the National Contingency Plan initiated.

11. The Operations Staff assess the implications of the incident.

12. All Coastguard staff on-call are called in for duty.

13. The emergency radio channel is nominated and all vessels instructed to listen in and assist
    where necessary.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3
                                     Page 131
COMMAN / D4.1 Functional Specifications



14. The Coastguard Operations staff contact all organisations according to their National
    Incident Plan. These would include the Emergency Services, Environmental organisation,
    Marine Pollution organisation, hospitals, local and national authorities, media (as
    necessary). They would also inform adjacent countries (i.e.France, Belgium, Netherlands)
    as appropriate on the understanding that some International coordination may be required.
    Military rescue centres may be requested to be on standby for SAR assistance.

15. The Emergency Services send liaison officers to the Incident Room to assist with the
    control of the incident.

16. The Coastguard Operations team maintains contact with the two vessels involved by radio
    to obtain frequent situation reports.

17. The two vessels maintain frequent stability calculations on the state of their vessels and
    make predictions on compartment flooding. For the cargo vessel this is done on-board and
    for the passenger ferry this is done ashore.

18. Reports on the operational state of the vessels are sent back to the Incident Room and
    remote diagnostic checks carried out where necessary. These reports are also sent to the
    vessel owners/agents.

19. Communications overload is induced by a large number of passengers on the ferry using
    GSM mobile phones and the phones on board the ferry to contact their families.

23. The Master of the cargo vessels notices that one of the drums containing weedkiller on
    board the cargo vessel is damaged. Sea water has got into the drum and a mix of the two is
    currently leaking out into the water, thus creating a significant hazard.

24. The Master of the cargo ship contacts the ship owner to ask for advice on the damaged
    drum. After some delay the ship owner advises the Master to inform the emergency
    services.

25. The Coastguard is informed of the leakage of weedkiller into the water by the cargo vessel
    and in turn informs the fire brigade.

23. One of the crew aboard the cargo vessel becomes caught in a rope and suffers leg and arm
    injuries as a result. Advice as to the treatment of the casualties is requested by the vessel
    and provided from ashore.

24. The appointed on-scene officer in charge flies to the incident site via helicopter in order to
    report the situation directly back to the Operations room via radio. Representatives from
    each of the emergency services will join the on-scene officer. It may be necessary for on-
    scene controllers to access detailed technical information regarding the vessels for the
    purpose of fire-fighting etc.

25. When on-call staff arrive at the Coastguard Operations room, they are instructed to assist in
    manning all lines of communication, calling up other craft to assist, controlling the safe
    movement of other vessels in the vicinity.

26. The Masters of the two vessels are responsible for the evacuation of crew and passengers
    on their own vessels. They liaise with the on-scene officer in charge to achieve this.
    Evacuation takes place mainly by civilian helicopters (UK, French, Belgian, Dutch SAR)


TR4006/D4.1/EUTELIS/6/8/99/version 1.3
                                     Page 132
COMMAN / D4.1 Functional Specifications



    and military helicopters. Other vessels in the vicinity are also required to assist by
    deploying lifeboats.

27. The movement and accommodation of evacuees is controlled as per the Contingency Plan.
    Constant communication is still required between the Operations room and the emergency
    services. Everybody must be accounted for.

28. An appointed spokesman is responsible for making press statements throughout the
    incident through a media centre located outside the immediate vicinity of the Incident
    Room. The airspace around the site of the incident is becoming increasingly busy with both
    rescue and media helicopters, and air traffic frequencies are congested, making airspace
    control a problem.



E. Scenario 2: The cruise

Context

  The cruise involves a liner belonging to an italian shipping company, making an 7 days
   journey through the Greek islands.
1. The liner is carrying 1400 passengers and 600 crew members.
2. Liner‟s gross tonnage : 58600 t


Possible implications for COMMAN:
 Bearer selection, prioritisation and least-cost routing
 Data service prioritisation
 E.mail store and forward
 FTP real-time data
 Limitations of using a single bearer
 Engineering diagnostic reporting
 Telemedicine/medical advice service
 Modification of procedures for commercial communications
 Credit card transactions
 Increased diversity of the communication services offered to the passengers
 Optimisation of the communications management in order to reduce the costs.



Events

Departure of the cruise

1. Weather forecasts : The captain wants to ask about the weather to prepare his sailing plan.
   So, he requests by GSM the agent to have the latest information about the weather. Then a
   satellite map is broadcast.

2. Sending the sailing plan : Sailing plans are sent as well because the maritime company
   wants to be informed of the precise route of the ship. This file is transferred to the agent in
   the port via e-mail.



TR4006/D4.1/EUTELIS/6/8/99/version 1.3
                                     Page 133
COMMAN / D4.1 Functional Specifications



3. Shore based pilotage : The ship is gone from the port and to navigate in the area close to
   the port, a pilot ashore gives him advises in real time. To do so, a VHF connection is
   established between the boat leaving the port and the pilotage station.

4. Declare entrance into VTS area : The ship enters quickly into a new VTS area and sends a
   message by telex to the VTS to inform it of its presence and provide casual information :
   port of departure, port of arrival, name of the ship and nationality.



During the cruise
   Before the call

5. Phone boxes : People want to inform their relatives that they have taken on board and that
   everything goes well. Phone boxes offering a credit card billing are available in each cabin
   and everyone can have access to them. Several options are available (access to terrestrial
   networks or to satellite networks) but since the cruise goes along the Greek coast, the
   communications are supported by GSM networks.

6. Payment at the Duty-Free shop : As on most ships, a duty-free shop is available to buy
   several goods at low rate. But the passengers come from several different countries so every
   currency can not be accepted. That‟s why payment with credit card is recommended. On
   boarding, every passenger gives a print of his credit card. During the following night, the
   ship checks with the banks that there are no stolen cards and that the accounts are in the
   black. All the transaction are stored and undertaken at the arrival of the ship.

7. ECDIS update : The captain, so as to navigate in a more secure way, uses ECDIS charts.
   As every week, he connects the COMMAN Single Data Node to its company‟s server and
   requests for a download of the update of those charts. Since this transfer is very expensive,
   the download is executed when the cost of the communication is lower (during the night by
   instance).

8. Food order : The restaurant of the ship only serve high quality food, fresh products can‟t be
   kept onboard for a long time; that‟s why, in case of failure of the stocking system, fresh
   food is loaded at each call during the cruise. Consequently, the purser sends a request by e-
   mail to the agent in the next port of call to order some food that will be loaded during the
   next call.

9. Office facilities : Some of the passengers are businessmen that need to be in contact with
   their office. That‟s why a fax and a PC with Internet connection is available; the billing is
   done on the personal invoice of each passenger.

10. Health matter : During the travel, one person suddenly complains of a violent pain in the
    belly. He is taken into the doctor that diagnoses an appendicitis. To be sure, he organises a
    Netmeeting with an hospital ashore to confirm his diagnosis. During this meeting, the
    hospital confirms the diagnosis and that the appendicitis is very acute; so an immediate
    evacuation is required.

11. Evacuation :. The captain contacts by phone the Coast Guards to inform them that a
    passenger needs to be evacuated urgently; he transmits all the necessary information
    including the position of the ship. The evacuation of the passenger is organised by
    helicopter because the ship is too far away from the coasts. At the helicopter draw near, a


TR4006/D4.1/EUTELIS/6/8/99/version 1.3
                                     Page 134
COMMAN / D4.1 Functional Specifications



    direct telephone connection is established between the captain and the helicopter to organise
    the evacuation procedures.

12. Ship tracking : During all the cruise, the ship transfers by email to the company its own
    position (known thanks to GPS) every 4 hours. However, the company, that wants to be
    informed of the arrival of the ship in the port of call, makes a request for the position of the
    ship. Immediately, the captain sends by e-mail its current position. (In case of need the ship
    can also transmit its position in real-time every quarter).

13. Call in a foreign country : The call is made in a foreign country so several mandatory
    procedures (clearance) are followed. To limit the time of wait of the passengers in the port,
    the captain sends by fax the most important information : the manifest, the list and identities
    of passengers, the list of vaccinations.


    After the call

14. Entrance into VTS area : The ship leaves the port after the call and enters in a new VTS
    area without knowing its existence. The VTS master asks the ship to identify itself. The
    captain then contact him by VHF if possible to provide him the casual information.

15. Bad weather : After receiving the latest weather forecasts by fax, the captain requests his
    company to send him by email a satellite picture to have precise information. After
    receiving the satellite picture, the captain decides to modify the route of the ship.
    Consequently, information are sent to the agent in the next port of call : sailing plan, ETA.

16. Ship passing around : As a consequence of the change of route, the captain has chosen to
    go along an island which is very frequented place. Sailing along the island, the ship pass
    other ships. With the help of AIS, the captain can localise his ship the other ships in real
    time; to avoid any misunderstanding and to agree on passing manoeuvres, the captain
    contacts directly the other close ships via VHF.

17. Mechanical breakdown : After this event, the ship puts to sea to follow the new planed
    route. During this period, the engine of the ship breaks down and the ship stops. The
    mechanic tries to repair the engine but he does not succeed so he contacts by phone the
    mechanical engineer to have advises. So as to be more efficient, the mechanic onboard
    opens a Whiteboarding session and a Netmeeting session to try to provide a distant repair.
    Finally, the engineer and the mechanic achieve to repair the engine and the ship can set off
    again. Due to this delay, the captain sends again the ETA by email to the agent in the next
    port. The mechanic orders by telex the mechanical parts to the agent in the port.

18. Personal communications : The ship has been delayed a lot due to the weather conditions
    and to this mechanical problem, so some members of the crew wish to inform their relatives
    of this delay. They use onboard phones on which they have personal accounts that allow
    them to phone with a fixed dedicated credit for each of them.

19. Change of passengers for the next cruise : The ship master receives by mail a message
    indicating that two new passengers are expected for the next cruise and an updated list of
    passengers as an attached document.

20. Announce arrival : The cruise is about to finish so the captain announces to the agent by
    email the arrival of the ship in the port of arrival.


TR4006/D4.1/EUTELIS/6/8/99/version 1.3
                                     Page 135
COMMAN / D4.1 Functional Specifications



21. Port entry guide : VHF communication between the local pilot, the port agent and the
    harbor VTS to guide the ship during its approach and berthing maneuver.




F. Assessment results

1. Activity (from scenario 1) VS Applications
Table 1 attempts to relate the events in Scenario 1 to the use of applications. This has been done
on the basis of assessing what applications/methods could viably be used to perform the action,
not what is the current operating procedure or capability. Included in this is the communication
and management sub-systems so that some of the grey areas can be cleared up. In most cases the
two sub-systems are utilised by implication, but for some cases the direct indication that these
sub-systems are used is needed.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3
                                     Page 136
COMMAN / D4.1 Functional Specifications




                                                              Operational Events                                                                                               Non-Operational Events
                              Distress      Sit    Casualty     Remote       Compartment        Stability     General     Port   Email   General     Email   Port   Credit card    GSM      Personal   Weath   Ships       Cargo    Passenger
            Applicati         calls         reps   Advice       Diagnostic   flood prediction   calcs         messaging   info           messaging   1       info   transactions   overlo   calls      er      technical   manife   manifest
                              4, 5, 7, 9,   16,    23           18           17                 17                                       1                   1      1              ad       1, 19      1       data        st       5, 9
            ons                             24.,                                                                                                                                   19                          24          5
            Email                                                                                                                                                                                    
            Internet      /                                                                                                                                                                             
            Intranet
            Access
            FTP                                                                                                                                                                                                   
            Telnet                                                                                                                                                                                            
            Whiteboardin                                                                                                                                                                                       
            g
            Netmeeting                                                                                                                                                                                        
    DATA




            IRC                                                                                                                                                                                            
            Still imagery                                                                                                                                                                                       
            Remote                                                                                                                                                                                         
            Database
            Access
            AIS                                                                                                                                                                                                   
            Video                                                                                                                                                                                              
            Imagery
            Positional                                                                                                                                                                                      
            Information
            VHF                                                                                                                                                                                         
    Voice




            Telephone                                                                                                                                                                                 

            FAX                                                                                                                                                                                       
            Comm sub-                                                                                                                                                                                       
            system
            Management                                                                                                                                                                                         
            sub-system
                                                                                                            Table 1: Activity vs. Applications (Numbers under Events relate to the scenario description event numbers)




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                                                                                                                                                                 Page 137
COMMAN / D4.1 Functional Specifications



This matrix shows that every activity could be carried out and also that every application could
server a purpose in carrying out an activity.
While a tick indicates that an application is used in the activity the extent to which an
application is used varies. An example is with stability calculations where positional
information is checked, this means that the positional information could be of use while
performing the stability calculations, perhaps to identify the ship or perhaps to reference against
the sea state when offering advice from the calculations.




2. Activity (from scenario 2) VS Applications
Table 2 attempts, as above for scenario 2, to relate the events in Scenario 2 to the use of
    applications.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3
                                     Page 139
COMMAN / D4.1 Functional Specifications




                              Evacuation 11   Casualty Advice   Remote Diagnostic   General messaging   Port info   Credit card transactions   Personal calls   Weather   ECDIS update   Ship-ship   Ship tracking   Office facilities   Passenger manifest
            Applicati                               10                 17              2, 8, 15, 19     3, 4, 14,              6                   5, 18         1, 15         7            16            12                9                   13
                                                                                                         20, 21
            ons
            Email                                                                                                                                                                                                         
            Internet      /                                                                                                                                                                                                    
            Intranet
            Access
            FTP                                                                                                                                                                                                                    
            Telnet                                                                                                                                                                                                                 
            Whiteboardin                                                                                                                                                                                                          
            g
            Netmeeting                                                                                                                                                                                                          
    DATA




            IRC                                                                                                                                                                                                               
            Still imagery                                                                                                                                                                                                       
            Remote                                                                                                                                                                                                            
            Database
            Access
            AIS                                                                                                                                                                                                                     
            Video                                                                                                                                                                                                                 
            Imagery
            Positional                                                                                                                                                                                                            
            Information
            VHF                                                                                                                                                                                                            
    Voice




            Telephone                                                                                                                                                                                                    

            FAX                                                                                                                                                                                                            
            Comm sub-                                                                                                                                                                                                        
            system
            Management                                                                                                                                                                                                            
            sub-system
                                                Table 2: Activity vs. Applications (Numbers under Events relate to the scenario description event numbers)




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                                                                                                                                                                    Page 140
COMMAN / D4.1 Functional Specifications




3. Application types VS Sub functions
Table 3 lists the way the use of applications relates to the activation of sub-functions. Split off
from this is a Communication Sub-system and Management sub-system for sub-functions that
do not sit clearly within the use of an application, particularly in the case of incoming
communications. Table 4 lists the sub-functions against number for reference.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3
                                     Page 141
  COMMAN / D4.1 Functional Specifications



Sub     E-mail   Internet   /   FTP   Telnet   White-     Net-       IRC     Still imagery   Remote      AIS   Video     Positio-nal   Voice   Fax    Comm sub-    Mangment
fnctn            Intranet                      boarding   meeting                            Data-base         Imagery   Info                         system       Sub-system
No.              Access                                                                      Access
1                                                                                                                                             
2                                                                                                                                          
3                                                                                                                                                  
4                                                                                                                                                      
5                                                                                                                                           
6                                                                                                                                        
7                                                                                                                                                      
8                                                                                                                                                      
9                                                                                                                                                      
10                                                                                                                                                     
11                                                                                                                                                     
12                                                                                                                                                      
13                                                                                                                                                 
14                                                                                                                                                      
15                                                                                                                                                 
16                                                                                                                                                   
17                                                                                                                                                     
18                                                                                                                                        
19                                                                                                                                                     
20                                                                                                                                                  
21                                                                                                                                                     
22                                                                                                                                                     
23                                                                                                                                                     
24                                                                                                                                                     
25                                                                                                                                                     
26                                                                                                                                                     
27                                                                                                                                                      
28                                                                                                                                                  
29                                                                                                                                                      
30                                                                                                                                                     
31                                                                                                                                                    
32                                                                                                                                                    
33                                                                                                                                                    
34                                                                                                                                                     
35                                                                                                                                                     
36                                                                                                                                                     

                                                                    Table 3: Applications vs. Sub-Functions




  TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                                                                                          Page 142
COMMAN / D4.1 Functional Specifications



  SF No     Name and Description                                                       Used by
  1         Filter non-authorised data service requests : Reject connection            II M
            requests to inappropriate ports.
  2         Check acceptability of incoming request : See if it is OK to accept the    M
            call. Factors are: Is the call from a „safe‟ number?, Is there a roaming
            charge?
  3         Check authenticity of incoming request : Check that the user               M
            connecting is allowed to connect. Typically for data services such as
            telnet and FTP, possibly also email. This is likely to be a check for
            both a valid user and password and that the user is allowed to use the
            service.
  4         Check Authority : Determine if a user has a higher authority than
            another, and or, that they have the authority to perform an action.
  5         Detect incoming call : Monitor bearers for an incoming call                II IN M
  6         Bearer selection :Select the best bearer to use. Factors include: :        M
            Service to be used (Web, email etc) : Size of transmission (if email) :
            Location being connected to (if interactive), Minimum call charge
  7         Check bearer availability : Check that the bearer is physically capable    M
            of connecting a call, e.g. the phone has a signal. And then also check
            that if the bearer is in use.
  8         Connection termination : Terminate a connection on a selected bearer       OI II M
  9         Connect to bearer(s) : Perform the call negotiation with the bearer        OI ON M
            equipment.
  10        Determine onboard host : Examine port to determine correct server to       II IN M
            route to, if IP is that of the SDN
  11        Establish connection to onboard host : Confirm host is available and       II M
            is ready to accept data.
  12        Identify host(s) available : Check that servers are accepting              II M
            connections
  13        Format data for onboard host : Convert to standard IP packets              IN
  14        Recording : record in the events log the date, time, length, type,         M
            bearer, cost, … of an incoming or outgoing call
  15        Connect call to appropriate IP service : For the use of direct Email       M
            server, Telnet and FTP connections so that they are correctly dealt
            with.
  16        Connect non-IP to appropriate destination : Connect FAX and voice          M
            to appropriate equipment and/or location
  17        Connect onboard e-mail server to server ashore : Establish a               OI M
            connection from the ship server to the shore server, either by an
            appropriate already connected bearer or a new connection.
  18        Detect outgoing call request : Monitor applications (browsers, email       OI ON M
            clients, FTP and Telnet) for connection requests.
  19        Request appropriate connectivity : Depending on type of service            M
            being utilised, request the appropriate bandwidth bearer
  20        Negotiate QoS that should be provided : The SDN and end                    OI M
            application agree the QoS that will be provided to support the
            requested data exchange.
  21        Queue request/Prioritise calls : Does what it says.                        M
  22        Download mail in accordance with urgency and cost criteria:                OI
            Examine email on server, group into categories in accordance with
            the criteria of the connection type (scheduled or immediate) , the
            time, the size, download appropriate groups.

TR4006/D4.1/EUTELIS/6/8/99/version 1.3
                                     Page 143
COMMAN / D4.1 Functional Specifications



  SF No      Name and Description                                                      Used by
  23         Data flow and virus sweep (incoming data) : Receive data and pass to      OI II
             appropriate end system checking for validity of received packets.
             Sweep incoming files through FTP, HTTP and Email for viruses.
  24         Poll host mail server and send queued mail                                OI M
  25         Data transfer (outgoing data)                                             OI ON
  26         Identify call service type (IP/non-IP) : On collection of a call,         II IN M
             determine what type it is, data or voice.
  27         Calculate call cost : Calculate the cost of the call just completed. If   M
             email or passive web connection then calculate the cost per item using
             the average data throughput,
  28         Call cost estimation : estimate the cost of the call before it happens    M
             according to its type, expected volume of data. Sub-function generally
             included in the bearer selection process.
  29         Record call cost in the telecommunications costs database or in events    M
             log
  30         Identify user call characteristics : The system determines the type of    OI M
             call, the originator, the requestor, the destination, etc…
  31         NON IP data reception : Receive data from a NON IP system and             IN
             extract information
  32         Transfer information received from AIS (or other non-IP bearer) to        IN II
             onboard host : Format information for end user and forward data
             packets to the correct onboard host with indication that data came
             from AIS.
  33         Receive time, position, course and speed data : Take in PCSH data for     M
             passing through the AIS
  34         Non IP data transmission: Format information and send data to a Non       ON
             IP system
  35         Receive data for transmission over Non IP system from onboard host        ON
             : Receive data from onboard IP host and queue for transmission.
  36         Format data to a non IP (AIS) standard                                    ON OI
                             Table 4: Sub-function numbering scheme
Table 3 shows that all the sub-functions are used and are sufficient to supply the basic
requirement, however new sub-functions may need to be added to take account of needed
additional functionality, i.e. realtime display of cost for a call.
It was decided to concentrate on the voice, fax and secured payment activities for this scenario
and these were related back to the flowcharts produced in WP3. Tables 5 and 6 illustrate the
mapping between the tasks in the flowchart with the sub-functions.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3
                                     Page 144
COMMAN / D4.1 Functional Specifications




                                                                       Sub Functions Used
                       Voice                                           (number and name)




                                                                18 Detect outgoing call request
                 pick up the receiv er




                                                              30 Identify user call characteristics
                 choose the serv ice                                19 Request appropriate
                 (VHF, telephone...)
                                                                          connectivity
                                                                  7 Check bearer availability
                                                                    28 call cost estimation
                                                                       6 bearer selection
                                                                    9 Connect to bearer(s)
                       dial-up
                  or use a directory




                                                                          Perform call
                                                                 (Need for new sub-function to
                         talk                                      display cost in real time as
                                                                          accumulates)




                SDN display s the time
                elapsed and the cost                           Call cost estimation (28) displayed
                                                                          while ongoing



                                                                     8 Connection termination
                      Hang-up                                              14 recording
                                                                       27 calculate call cost
                                                                     29 record call cost in the
                                                                telecommunications cost database
                                                                          or in events log
                                       Table 5: Voice task analysis




TR4006/D4.1/EUTELIS/6/8/99/version 1.3
                                     Page 145
COMMAN / D4.1 Functional Specifications




                                                                                            Sub Functions Used
                                                                                            (number and name)
                             Secured Payments




                         Launch the payment                                                 Actions at terminal
                       application or sub-function



                                                                                      18 Detect outgoing call request
                       Insertion of the Credit Card
                        (or pre paid card), or enter
                          the credit card number

                                                                                   19 Request appropriate connectivity
                                                                                     21 Queue request/prioritse calls
                             Connect to the                                              28 call cost estimation
                              bank server                                              7 check bearer availability
                                                                                           6 bearer selection
                                                                                         9 connect to bearer(s)
                                                                                       None needed on SDN level
                             Control of bank
                                account                                               (Communication with Bank)


                                                                                        8 Connection termination
                                 Payment                          End of the
                                                        No
                                  allow ed                         process



                                    yes


                                                                                       None needed on SDN level
         Display on the screen : cost and payment authorisation                      (User confirmation of purchase)



                                                                                         8 Connection termination
                              Acceptance to                   End of the                        14 recording
                                                       No
                                  pay                          process                     27 calculate call cost
                                                                               29 record call cost in the telecommunications
                                                                                      costs database or in events log
                                    Yes



                                  Billing




                                          Table 6: Secured Payment analysis




TR4006/D4.1/EUTELIS/6/8/99/version 1.3
                                     Page 146
COMMAN / D4.1 Functional Specifications



    Table 5 details the sub-functions that voice and FAX (and comms/management sub-
     systems) utilise. These were separated out and compared to see if they were all used. This is
     shown in Table 7.


              2       5    6     7     8     9     14     16    18    19    26       27   28   29    30
    Voice                             
    Fax                               
                  Table 7: Sub functions identified used in the Voice/FAX process:


    Sub-functions 2, 5, 16 and 26 are not checked in table 7 as they are for the reception of an
     incoming call. It is certain that these would be exercised by the incoming call and some of
     the functions currently checked (such as bearer selection) would no longer be used.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3
                                     Page 147
COMMAN / D4.1 Functional Specifications




G. Conclusions

1. Functionalities to add or refine
While the assessment has determined that all the sub-functions are used and that these support
the functionality of the system, areas of extra functionality have been identified through
discussion.
1. A main area of weakness is in the bearer management, where additional functionality is
   required to fully cover likely situations. These are:
       - Non-Availability   of bearers;
       - System   hysteresis when in difficult, changing reception environments;


2. There is also a need to consider bearer management and scheduling in response to need
   rather than just cost.
3. Additional functionality is needed within the scheduling management to take account of
   opportunistic connections to satisfy least cost sending (for example when crossing into an
   area of GSM reception, taking advantage and sending the stored email rather than waiting
   for the next scheduled connection time when it would cost more) and utilising a constraint
   based approach to re-schedule the queued calls without bothering all users and enabling a
   more flexible transmission policy.
    These two areas relate to general COMMAN CDR and QoS requirements where concern is
    expressed about:
           -   Practicality of users specifying maximum transmission cost;
           -   Individual users selecting bearers to send email, rather than a scheduled service
    The assessment has highlighted that system usage and task policies need to be further
    refined before any more functionality short falls can be positively identified.



2. Interfaces issues
4. On a liner, the main source of data is the company‟s server. It also can be the Internet access
   of the ship. 2 to 4 times a day, a connection is established between the ship and the server at
   off peak rate and all the data stored, including e-mail, is sent. The ship also retrieves all the
   data that the company (different departments of the company) has placed on the server in a
   dedicated folder.
    This shows the need to further define the automation capacities of the COMMAN system
    (linked to store and forward) and their articulation with the automation capacities of COTS
    applications. A browser or any client application, can be programmed to accomplish this
    task of automatic retrieval. How will it deal with COMMAN‟s constraints (access to bearers
    denied) ? Is it possible to refine the communication between these applications and
    COMMAN in order to avoid repeated error messages ?


5. Passengers have telephones in their cabin. However all the outgoing calls are made through
   the radio operator. COMMAN can improve the operator‟s work and help to provide the
   customers with a better service. In the long term, thanks to cost estimation for instance,
   COMMAN can help to provide additional services to the customers. The user interface must


TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                 Page 148
COMMAN / D4.1 Functional Specifications



    lighten the work of intermediary of the radio operator, if not allow customers a direct access
    to communication services. The definition of the interface of COMMAN and the PBX needs
    to be refined.



3. Payment procedure
6. On a liner, passengers pay with a special personal card (with a PIN) that they receive at the
   beginning of the journey. The communications with the banks happen only twice : at the
   departure to check the validity of their credit card and before the arrival to check the state of
   their bank account. The communication with the banks use faxes for the moment but we can
   foresee that they will use data transfer soon. However this procedure will probably remain,
   as it allows a management of the passengers accounts with limited communications with the
   banks.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                 Page 149
COMMAN / D4.1 Functional Specifications




II. General data exchanged during the communications

Here is, for each type of communication, the information exchanged

                                                                  Information stored
                  Outgoing call                      Ship        Cargo         Crew       Journey
                                                  identificati Identificati identificati Identificati
                                                      on           on           on           on
Ship tracking                                         X
Declare entrance into the VTS area                    X            X                         X
Announce hazardous goods                              X            X
Distant survey                                        X
Remote Damage Survey                                  X
Remote Surveillance of Safety Critical Operations     X
Ice patrol reports                                    X                                      X
Sending the ETA                                       X                                      X
Sending the ETD                                       X                                      X
Send sailing plan                                     X                                      X
Sending of load maps plan                             X
AMVER reporting                                       X                                      X
Cargo handling, loading, discharging                  X
Cargo management                                      X
Slop discharge                                        X
Garbage-cargo handling                                X
Access to tourist information
Announce arrival                                      X
Logistics machine                                     X
Logistics husbandry, supplies                         X
Message to the agent                                  X
Money order                                           X
Catering for crew and passengers                      X
Immigration authority                                 X
Agriculture authority                                 X
Medical authority                                     X
Sending of the list of crew, the licences, …          X
Office facilities                                     X
Ice messages                                          X
Ice warnings                                          X
Mayday/PAN/medical Service                            X
Fire fighting, safety                                 X
SAR                                                   X
Get real-time position information from vessels       X



                   Figure 46: Information exchanged during outgoing calls




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                             Page 150
    COMMAN / D4.1 Functional Specifications




          Incoming Call               Ship             Cargo              Crew            Journey
                                  identification    Identification    identification    Identification
    Make ECDIS update
    Weather forecasts
    Entertainment
    General information about
    the port
    Access       to      tourist
                                 No information transmitted except in case of acknowledgement of receipt
    information
    Generic incoming calls :
        Incoming e-mail
        Incoming fax
        Incoming telex
        Incoming ...


                       Figure 47: Information exchanged during incoming calls




  Bi-directional Communications            Ship            Cargo           Crew         Journey
                                       identification   Identification identification Identification
Import/ Export of ISM code relevant          X                X
messages or forms
Customs                                      X                 X              X               X
Medical service                              X                                X               X
Shore based pilotage                         X                 X                              X
Shore based radar assistance                 X                                                X
Port entry guide                             X                 X                              X
Ship-ship communication                      X                                                X
Phone boxes                                  X
Personal Communications                      X
Virtual Round Tables                         X
Distant learning and general education       X
Remote maintenance                           X                 X                              X
Web access
Remote access to databases                   X
Secured payments                             X
Remote network management                    X
Remote access to COMMAN system               X



               Figure 48: Information exchanged during bi-directional communications




    TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                             Page 151
COMMAN / D4.1 Functional Specifications




III. Interviews

A. DELMAS Company Interview

Le Havre, 02/03/99


Captain Raymond, Safety and Quality Manager – Fleet Communications and
Information Systems at the DELMAS Company.

We asked Captain Raymond to comment the tasks list produced during phase 1 of the
WP4.

As fleet communications and information systems manager, Captain Raymond has a
good vision of what are the communication tasks under the responsibility of the
captain and of the crew. Moreover, this interview of Captain Raymond was also
interesting because of his global vision of the problems that was useful to identify all
the perspectives on which we should focus our priorities.


Beside the tasks, they insisted on the following points :
 Fax is often used by the crew because it is a very easy-to-use tool compared to
   TELEX. However, the cost of Fax is extremely higher than the cost of TELEX. So,
   an objective of the COMMAN system should be to make easier every
   communication tasks and to limit the telecommunication bill of the companies.

   For every data communications, an acknowledgement of receipt will have to be
    send to make sure that all the information sent is received.


The task list:

Before leaving port
1. The ETD is generally transmitted to the agent in the port before the departure of
   the ship. This can be communicated in person or transmitted via a GSM phone.
   The ETA and the next call is also transmitted.

2. Concerning the sailing plans, Captain Raymond also thinks that it is unrealistic to
   transmit them before the departure; this could become mandatory in the future but
   it is too restricting to transmit them now. A lot of parameters can change the road
   initially planed so it is not desirable to include this option in the COMMAN
   features.

At departure
3. Declare entrance into VTS area:
The ships know when they enter in a new VTS area (maps of the VTS area exist). So,
when they enter a new area, they declare the entrance and send the following
information :
 Name of the ship (code)
 The course, the speed




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                               Page 152
COMMAN / D4.1 Functional Specifications



    The destination
    The last port of call
    Name of the captain
    Types of cargo (if there are dangerous cargo : weight of cargo for each category)


4.    Shore based pilotage : it happens only in case of very bad weather (especially
     fog). The pilot inform the captain of which course and which speed he should
     adopt; the captain decides if he follows or not those advises. The frequency of
     update for the course and the speed is from 10 seconds to 1 minute and an half.
     Positions of the other ships are also transmitted. For such an tasks, ECDIS charts
     are highly desired.


In narrow and deep waters
5. Weather forecasts : the use of electronic charts could be an improvement but not
    crucial. The actual needs are to have more precise information (i.e. height of the
    waves) and to have the opportunity to have at one‟s disposal short term and long
    term forecasts.

6. ECDIS update : For the moment, ECDIS charts are static information describing
   very precisely the environment; the ships which are sailing are not identified on
   those charts. The hydrographic service can make the update of the ECDIS charts.
   Concerning DELMAS, the updates are done every 3 months because paper maps
   also exist on board; without any paper maps, the updates should be done every
   week.

7. AMVER reporting : This reporting is centralised by an American institution. A
   ship can identify itself and send its position, its speed, its course once a day; the e-
   mail is a good solution for this task.

8. Own positioning : This positioning is made thanks to GPS and could be improved
   with DGPS. In deep waters, the positioning is done once an hour; near the coast, it
   is done every 20 minutes and even every 5 minutes in specific cases.

9. The ETA includes the draught and a description of the freight (weight and number
   of containers that will be unloaded at the next call).


Reaching port
10. Port entry guide : a map exists on paper and should be digitalised and the update
    should also be taken into account.

11. Announce of hazardous goods : This communication is done with the agent or
    directly with the port. The captain has to declare detailed information about the
    cargo. Especially, he will declare the weight of each class of cargo detailing the
    quantities that will be unload and in transit.


Emergencies

12. SAR : Procedures defined by the OMI and included in GMDSS.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                   Page 153
COMMAN / D4.1 Functional Specifications



13. Piracy : Distant survey ashore is unrealistic because of the cost of video
    transmission.

14. Urgent messages : Communication with the authorities of the closest country
    (NAVTEX – SAFETYNET).


Remote maintenance
15. Ship tracking : The speed, the course and the position of the ship is send by the
    captain to the company every 4 hours.

16. Generally speaking, the ship arranges a phone meeting with a technician of the
    company and they agree to send the spare part to the next port. Video can be used
    in case of damage that the chief mechanic is not able to repair. In any case, a file
    including all the orders of mechanical parts is sent; this file is generally important
    (few MO).


Cargo handling
17. Cargo handling, loading, management : very huge files (MO) are sent by the
    company itself to the agent in the port. Two types of files are send : loading files
    and discharging files including a lot of information. So, those communications are
    out of the scope of COMMAN.


Miscellaneous
18. Digitalised images rather than video should be used onboard for tele-medecine.

19. The crew should have to one‟s disposal phones for personal communications. It
    means that the crew should not use telecommunication tools of the deck for
    personal communication. The most proper way should be to enable personal
    communications from phones in the cabins of the crew or in phone boxes. Since
    they are separate phones, it would be really easier for the billing.




B. “Port Autonome du Havre” Piloting Station Interview

Le Havre, 23/02/99

M. Bellec, President of the Piloting Station,
M X., colleague of M. Bellec

We asked M. Bellec and his colleague to comment the tasks list produced during phase
1 of the WP4.
Their position give them a good vision of the navigation communications exchanged at
departure and arrival to the port, but they have general knowledge of deep waters or
commercial communications but not always up-to-date.

Beside the tasks, they insisted on the following points:
 legal issues : telex remains in use because the device archives a copy of every
   message received, and a telex can be accepted as a proof by a court. The ability to


TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                 Page 154
COMMAN / D4.1 Functional Specifications



    archive the messages is an important feature for any possible communication
    device.

   What would be useful : transponder on boats and a device giving a picture of
    the traffic. Currently the system in use is “Norcontrol”: a screen where appear
    radar echoes and electronic “stickers” indicating the names and main
    characteristics (name, size, draught, course, speed). These stickers are filled by
    hand, on a PC, after VHF-transmitted (voice) information. Those charts are only
    available at the piloting office but not yet on the ships.


The task list:

Before leaving port
20. before the departure, there are a lot of commercial or weather communications. For
    instance, reserve the dockers in the destination port, according to the ETA : in this
    case, cellular phone is almost always used.

21. the ETD is sent by the agent and not by the captain, even if it is communicated to
    the agent by the captain.

22. send sailing plan : There are rarely sailing plans. It may exist a plan agreed
    between the captain and the company, but generally speaking, there is only one
    route. And when there are several possibilities (Suez Canal versus Good Hope
    Cape), the choice is made a long time before by the company. The only case when
    there is a sailing plan is when the ship transports dangerous freight, follows coastal
    routes, signals to semaphors, etc. The sailing plan exists then because of legal and
    safety issues : the company‟s agreement on the route is needed.

At departure
23. while leaving the port, there are incessant VHF communications about the position
    of other moving ships. These communications are ship to port communications but
    also ship to ship communications during the manoeuvres, often between pilots
    themselves.

24. Declare entrance into VTS area :
     - at Le Havre, this declaration is automatically made by the lookout, who
          watches entrances and departures and the area near the port thanks to a
          “Norcontrol” screen where appear radar echoes and electronic “stickers”
          indicating the names and main characteristics (name, size, draught, course,
          speed). Sometimes the VTS is also informed by the pilot, who carries a
          portable VHF.
     - At Rouen, the ship signals itself to the VTS, using the port‟s channel on
          VHF. Information exchanged : name of the boat, leaving the port.


Incidental remark : on the pilot’s launch, there is the same “Norcontrol” screen (PC
monitor with radar echoes of the port area) as in the lookout office, but the pilot
doesn’t take it with him on board of the ship

25. Shore based pilotage : it happens only in case of very bad weather (especially
    fog). The pilot has to be included in the speakers. In this case, the pilot who is
    ashore gives advises to the captain but not orders; only the captain takes the


TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                 Page 155
COMMAN / D4.1 Functional Specifications



    responsibility of the handling of the ship. The information supplied to the captain
    are the speed, the course and the position of the ships. Moreover, similar
    information are also provided about the other ships in the same area.


In narrow waters
26. Communications in narrow waters : VTS broadcasts information (damaged buoy
    or lighthouse), very local weather reports. Ships also make weather observations
    they send to the weather stations. The proceedings followed observations have to
    be clarified.

27. Communications in deep waters : nothing special except the obligation to keep a
    watch on the channel 16 of VHF, which is the security channel. And other
    commercial watches (weather).
Ship-ship communications : if a ship is within radar range, then it is within VHF range.
Information exchanged is mostly identification/safety related. Fishermen do a lot of
chattering.


In deep waters
28. Weather forecast : they think ships don‟t need rough satellite pictures. They want
    interpreted weather maps, which they already receive by fax. They also have a
    “ribbon machine” (what is it ?) which continuously receive forecasts in text and
    print them on a ribbon of paper.

29. The ETA includes the draught and a description of the freight.


Reaching port
30. Reaching port
 There is a VHF communication between the captain and the port to decide of the
    number of tugs needed. Ordering the tugs can‟t be automated : it is a technical
    estimation made together by the captain and the port.
 There are commercial information that are exchanged through the pilot about the
    number of dockers present for unloading, the side of the ship that will be along the
    quay.
 The pilot must inform the port of the anomalies he may detect.


31. Port entry guide : a map exists on paper and sometimes there are digital world
    maps including the ports.


Emergencies
32. There are 3 levels of alert message :
 Mayday (3 times) : life endangered
 PAN (3 times) : worry, without news of a ship
 Security message : notification of bad weather or drifting object


33. In case of fire on a ship in very busy areas, there may be plans established by the
    local authorities, e.g. the Channel Plan (“Manche-plan”) in case of fire on a ferry.
    See the Préfecture maritime de Cherbourg for more details.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                               Page 156
COMMAN / D4.1 Functional Specifications




Remote maintenance
34. Generally speaking, the ship arranges a phone meeting with a technician of the
    company and they agree to send the spare part to the next port.


Cargo handling
35. The loading plan is sent to the next port of call by the company agent. Captain are
    sometimes not responsible of the loading : some companies employ ship-planners
    in charge of loading and sending the loading plan.


Communication with authorities
36. Some formalities (declaration of diseases) are sometimes accomplished by VHF
    before the arrival, but most of the time all the formalities are done at the same time
    at the arrival : the crew list and the passport numbers (immigration), customs
    officers want to see things with their own eyes.


Miscellaneous
37. There is no physician on board, except on liners.

38. Before the arrival, the captain asks for local currency for the crew to the company.



Other “interesting but out of context” things
   There is a perceptible delay (because of the refresh rate, we think) between the radar charts
    and the reality. That is why shore based pilotage is in fact shore-assisted pilotage. No one
    ashore (even VTS or harbourmaster) can give orders to the captain, because no one has a
    better perception of the ship‟s position, speed and inertia than the captain. Only a pilot, who
    is on board and whose legal responsibility is clearly defined, can give instructions to the
    captain.

   There is no normalisation in ship communication equipment or crew formation. The world
    fleet is extremely heterogeneous and many ships arriving in European ports are under flag of
    convenience.



C. Interviews at ISSUS and SUSAN related to WP3 and 4

The following persons contributed to interviews related to WP3 and WP4. The interviews were
conducted at ISSUS in the period 15th March to 10th April 1999.

Capt. G. Schmidt, lecturer on communication topics and instructor for 'Long Range Certificate
[LRC]' at ISSUS, contributed to technical characteristics related to communication tasks.

Prof. Capt. D. Lemburg, Scientific Director at SUSAN (Shiphandling and Simulation facility)
conducted several informal interviews with 6 trainees at SUSAN. Those trainees were selected
according to their respective areas of competence as master or 1st or mate on seagoing vessels.
To cover for regional diversity, each interlocutor held long standing experience in Atlantic,


TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                 Page 157
COMMAN / D4.1 Functional Specifications



Pacific and other foreign areas in a variety of vessels, ranging from crude carriers over container
vessels to research- and passenger vessels. The initial disposition of questioning according to
'phases of a journey' was introduced by Prof. Lemburg.

Capt. H. von Morgenstern, Technical Director and instructor at SUSAN, provided additional
information on safety-related communication tasks.

Dipl.-Phys. Jörg Thiesing, Research Engineer at ISSUS, conducted serveral additional
interviews with persons mentioned above. He sampled all direct results and structured them
according to the 'phases of a journey'-approach.




                            IV. PEER REVIEW REPORT




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                Page 158
COMMAN / D4.1 Functional Specifications




                                 COMMAN

                    Communication Manager System for
                    Data Exchange for Ship Operations

                         Telematics Application Programme
                                  Transport Sector
                                Project No TR4006




                        PEER REVIEW REPORT


                         Functional Specifications
                                Deliverable 4.1




                                      Issued by

                                Karl-Christian Ehrke
                       STN ATLAS Marine Electronics GmbH
                         Behringstr. 120, D-22763 Hamburg
                           +49-40-8825-2868, fax -4125
                               ehrke.kc@stn-atlas.de




                           Date of Review: 15th July 1999
                             Update: 3rd August 1999



TR4006/D4.1/EUTELIS/6/8/99/version 1.3                      Page 159
COMMAN / D4.1 Functional Specifications



1 The Peer Review Process

The deliverable was produced by the task 4.1 group lead by Pierre Geslot and Yann Depoys
from EUTELIS.

The review comprised the 125-pages main document. It was carried out by Karl-Christian Ehrke
from STN ATLAS Marine Electronics GmbH.

The task objectives were to specify the services offered by the single data node developed during
the COMMAN project.

Version 1.1 of the deliverable was issued on 8th June 1999, and distributed for review on 7th
July, which is about three months delayed compared to the schedule from 25th June 1998. The
final update was issued with the same date and distributed on 15th July.


2 Comments on Deliverable

2.1 Response to the user needs

This deliverable is not used by end-users, but by the subsequent task teams, which shall
implement the radio server. In this context, the contents fits quite well and provides a good
guideline for the next project phase, which is the development of the system architecture.

2.2 Correspondence to project objectives

Exactly in line with project objectives

2.3 Depth and extent of coverage

The deliverable provides a good overview about the required services and functionality of the
planned radio server system.

It describes in detail the subfunctions of the different management areas like accounts, bearer,
network, QoS, store and forward, database, service and time synchronisation.

2.4 Relevance

The detailed description of subfunctions with flowcharts as well as pseudocode can be directly
used for the subsequent implementation phases. The work is of high relevance.

2.6 Clarity of presentation and achievements

Chapters 1 to 4 with introduction, objectives, methodology and framework, and the task
overview are clearly structured and provide a good basis for the understanding of the subsequent
detailed specifications.

In chapter 4.1 - requirements on page 28/29, the emergencies are mentioned as one task of the
radio server. This aspect has been discussed previously in WP 3.1 with the result, that no
emergency functions should be implemented on the radio server due to safety, back-up and




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                               Page 160
COMMAN / D4.1 Functional Specifications



authority requirements. On page 41 under section 5.1.5 this aspect is confirmed, but it should be
made clear troughout the whole document.

Chapter 5 describes the functionality of the system. Derived from a list of tasks for outgoing and
another one for incoming communication the necessary communication services like “send
ETD” or “Send ETA” are specified. This is a useful starting point.

In 5.2 there is a mixture of application and communication specific functions. The focus of the
whole description seems to be a little bit too much application oriented. Functions might not be
generic enough, to cover a full range of different and future applications.

In 7.2 the real communication sub-functions like “check bearer availability” and “connect to
bearer” are described. The method of pseudocode is used. This is a very good method of
structuring dynamic processes without any complicated tool.

In chapter 8 the functional architecture is described, it is represented by a three layer model with
user level, service/scheduler level and service/connection level. It can be used to group the
required functions level-wise for optimum functionality.

In chapter 9 the functionality of the COMMAN single data node is illustrated by two scenarios.
The first one is a collision, the second one a cruise. Both demonstrate very well the wide
application range of the system. For some events, like “Sending the ETD” (page 113), the
functionality is already detailed enough, for others, like “Health matter” (page 114), the reader
would like to see more relationship to the services, described before.

2.7 Typographic and other comments

none

3 Summary

Summarising the review result, it can be stated, that this document presents a very good basis for
the subsequent implementation phases.




TR4006/D4.1/EUTELIS/6/8/99/version 1.3                                                 Page 161

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:9
posted:3/19/2011
language:English
pages:161