R0145 VTS 간 정보교환 형식(IVEF) 서비스 (요약·한영 대역)

IALA RECOMMENDATION (NORMATIVE)
R0145 (V-145)
THE INTER-VTS EXCHANGE FORMAT (IVEF) SERVICE

Edition 1.1
June 2011
urn:mrn:iala:pub:r0145:ed1.1

International Association of Marine Aids to Navigation and Lighthouse Authorities
10, rue des Gaudines – 78100 Saint Germain en Laye, France

Revisions to this document are to be noted in the table prior to the issue of a revised document.

THE COUNCIL

RECALLING that one of the aims of the Association is to foster safe, economic and efficient movement of vessels and the protection of the marine environment through the improvement and harmonisation of aids to navigation, vessel traffic services and other means world-wide;

RECOGNIZING that the e-Navigation architecture will assist in the development and maintenance of application interactions between ship and shore and shore to shore, in the following fields:

• shore-based technical e-Navigation services;
• technical means for communication;
• data modelling and referential data;
• Human-Machine Interface presentations;

RECOGNIZING ALSO the responsibilities of IALA National Members regarding national and international e-Navigation applications:

• that the shore-based e-Navigation systems of National Members are embedded into local, regional, national, supra-national and global topologies of systems;
• that there are data/information flow chains within the local, regional, national, supra-national and global topologies of systems which support local, regional, national, supra-national and global e-Navigation applications;
• that requirements regarding quality parameters, such as accuracy, reliability, continuity, confidentiality, and others, will need to be taken into account when designing elements of the common shore-based e-Navigation system architecture;

RECOGNIZING FURTHER that the Inter-VTS Exchange Format (IVEF) service, as laid out in this Recommendation, will assist in the efficient deployment of services to the mariner and to the maritime community by:

• allowing shore-based systems of National Member and other appropriate Authorities and Entities to participate in harmonised data exchange;
• easing the integration of components;
• improving the efficiency in organisational terms by exploiting commonalities;
• harmonising data exchange to systems of other shore-based stakeholders (local, regional, national and global);
• taking into account the value, timeliness and sensitivity of data;

NOTING that

• IALA Recommendation R0140 (e-NAV-140) on ‘The e-Navigation Architecture – the Initial Shore-based Perspective’ [1];
• IMO’s strategic plan regarding e-Navigation [2];
• that IMO expressed an interest in the contribution of IALA to the work on e-Navigation [3];

ADOPTS the Guidelines on the Inter-VTS Exchange Format (IVEF) Service set out in the annex to this Recommendation; and,

RECOMMENDS that National Members and other appropriate Authorities and Entities, introducing an IVEF Service into their shore infrastructure, take into account the principles as set out in the Guidelines on the Inter-VTS Exchange Format (IVEF) Service.

ANNEX A THE INTER-VTS EXCHANGE FORMAT (IVEF) SERVICE

1. 1 INTRODUCTION
2. 2 THE IVEF SERVICE AS DESCRIBED BY OTHER IALA RECOMMENDATIONS
3. 3 SERVICE MODEL OF THE IVEF SERVICE
   3.1 Overview
   3.2 Capabilities of the IVEF Service for the Shore-based e-Navigation System (3.2.1 Introduction; 3.2.2 Basic IVEF Services (BIS); 3.2.3 General Use Cases)
   3.3 Data Model of the IVEF Service (3.3.1 Introduction; 3.3.2 The Place of the IVEF Service in the e-Navigation Architecture)
   3.4 Interaction Model of the IVEF Service (3.4.1 Context; 3.4.2 Service Negotiation; 3.4.3 Part I: Primary service use cases of the BIS; 3.4.4 Part II: Secondary service use cases of the BIS)
   3.5 Security Model of the IVEF Service
   3.6 Interfacing Model of the IVEF Service
   3.7 Quality Parameters of the IVEF Service
   3.8 Test model of the IVEF Service (3.8.1 Well-formed messages; 3.8.2 Valid messages; 3.8.3 Valid data; 3.8.4 Interaction behaviour)
   3.9 Administration Model of the IVEF Service
4. 4 REFERENCES
5. 5 DEFINITIONS
6. 6 ABBREVIATIONS

APPENDIX 1 DATA DEFINITION
1 ELEMENT DEFINITIONS
2 ATTRIBUTE DEFINITIONS

List of Tables: Table 1 Interface Messages

List of Figures: Figure 1 The IVEF Service in operation; Figure 2 The IVEF Service Client/Server Model; Figure 3 The IVEF Service Model; Figure 4 IVEF Service Primary Use Case; Figure 5 The Place of the IVEF Service within the e-Navigation architecture; Figure 6 Client-server relationships of the IVEF Service with other shore-based e-Navigation service (see reference [1], Figure 5); Figure 7 The Communications Stack; Figure 8 Overview of the primary service use cases of the IVEF Service; Figure 9 The DATA Service Component; Figure 10 The Session Service Component; Figure 11 The Status Service Component; Figure 12 The ISO/OSI Reference Model; Figure 13 Domains of Interest, Responsibility and Co-operation; Figure 14 IVEF Service using a Common Authority; Figure 15 Login/Logout Activity Graph

The IVEF Service is intended to provide a common framework for the exchange of vessel traffic image¹ information between shore-based e-Navigation systems, such as VTS systems, e-Navigation stakeholders and relevant external parties.

Figure 1 shows such a situation, where VTS centres share information about the common operational area and also to relevant other users and authorities.

Figure 1 The IVEF Service in operation

The IVEF Service is client/server-based. Clients make a connection to a server, running the IVEF Service and receive traffic image data according to their specific preferences and authorisations (Figure 2). Different clients may specify different data requirements, such as the area of interest, the update frequency and the particular traffic objects that are relevant to them. Based on the client credentials, the IVEF Service will enforce restrictions on the data that is being served to the client. These restrictions can be specified by the data provider.

Figure 2 The IVEF Service Client/Server Model

¹ See section 6 - Definitions.

The IVEF Service is a gateway service, as contained in the general description of the common shore-based system architecture in the ‘IALA Recommendation on Shore-based e-Navigation System Architecture’ [see reference [1]]. Such a gateway service is specialised in data exchange shore-to-shore. It interfaces to other e-Navigation systems and to external systems of ‘third parties’. These systems may request the IVEF service to forward relevant data to them. A IVEF service can interface shore-based systems locally, nationally, regionally, and globally.

The IVEF Service specification is organised according to the (draft) ‘IALA Recommendation on Generic e-Navigation Service Engineering Model Template’ [1] as depicted in Figure 3.

Figure 3 The IVEF Service Model

The specification contains exactly those elements that are relevant for a full description of the service. The following is a brief description of these elements:

Basic IVEF Services: capabilities of the IVEF Service and its functional interface statements.

Data Model: the abstract descriptions of the data provided by the IVEF Service at its Basic IVEF Services to shore-based e-Navigation systems and external systems. It defines the data types and data objects of the IVEF Service.

Interaction Model: the dynamics of the interaction of individual components of the IVEF Service (data flow and protocol).

Interfacing Model: the data encoding and interface protocols between the provider of the IVEF Service and the clients, requesting data from the service.

Security Model: control of access to the IVEF Service (filtering and access rights).

Quality Parameters: performance and reliability considerations of the IVEF Service.

Test Model: test and validation of the IVEF service.

Administration Model: the technical administration and maintenance aspects of the IVEF Service.

A full description of all these aspects follows in the remainder of this document.

3.2.1 Introduction

The IVEF Service is an optional part of a shore-based e-Navigation system. Its basic purpose is to provide a vessel traffic image to related vessel traffic service systems, to e-Navigation stakeholders and to relevant external parties. Any IVEF Service provides, at least, the so-called Basic IVEF Services (BIS). A particular characteristic of the IVEF Service is that these services are only rendered on request of another e-Navigation system or of an external system, i.e. the IVEF Service follows the client/server model as already described in the introduction of this specification (Figure 3).

3.2.2 Basic IVEF Services (BIS)

There is only one basic IVEF service, which is

Vessel Traffic Image Data Exchange Service – deliver vessel traffic situation data, according to a specific service profile. Such a service profile determines e.g. the data items delivered, the area of interest and the update rate.

The IVEF Service is part of the e-Navigation Client/Server-based architecture. A general way of describing communication architectures is via the ISO/OSI reference model [3], which describes communication between applications through a layered model. Each higher-level layer in this model increases the level of abstraction. The communication between client and server is described here at the so-called ‘application layer’ in the reference model. The implementation of the lower layers is not discussed here. It is only suggested to use a secured and reliable link between the client and server.

3.2.3 General Use Cases

Figure 4 IVEF Service Primary Use Case

3.3.1 Introduction

The Data Model of the IVEF Service will be part of the IALA Universal Maritime Data Model (IALA UMDM), as described in [1]. It provides the well-structured and abstract (functional) description of the data that is exchanged through the IVEF Service.

The Data Model itself does not contain data encoding information which is required to create an actual implementation of the service. Separating the data encoding from the Data Model of the IVEF Service provides flexibility in selecting an encoding technique as deemed appropriate by the competent authority. A portfolio of suitable encoding techniques for data objects of the IVEF Service is given in section 3.6 on the Interfacing Model.

3.3.2 The Place of the IVEF Service in the e-Navigation Architecture

Figure 5 illustrates the place of the IVEF Service in the e-Navigation architecture as described by IALA Recommendation on the e-Navigation Architecture – the Shore Perspective [1]. It clearly identifies the co-operative nature of the shore-based IVEF Service. Note that the IVEF Service shares the dependencies of the e-Navigation architecture.

Figure 5 The Place of the IVEF Service within the e-Navigation architecture

There may be many client-server-relationships, since the ‘gateway services’ of the shore-based e-Navigation system may be requested by other e-Navigation services within that system, there can be identified. These client-server-relationships can be combined into a hierarchy within the shore-based e-Navigation system (see Figure 6, which is derived from reference [1], Figure 5).

Figure 6 Client-server relationships of the IVEF Service with other shore-based e-Navigation service (see reference [1], Figure 5)

Diagram labels: Shore-based e-Navigation system; IVEF Service; VTS 1; VTS; Application 2; Application 3; Application 4; Sensor Data; Wireless Communication; Integrated Bridge; Ship’s sensors; Shipboard Applications.

3.4.1 Context

IVEF Service Interfaces are point-to-point connections between e-Navigation Gateways. One Gateway acts as an information source whereas the other Gateway acts as an information sink.

Note that the IVEF Service by itself has no provisions for data compression and encryption. IVEF describes the data exchange format between e-Navigation applications; it relies on transport layers underneath to convert between physical, electrical and network interfaces. Additional transport layers may add data compression and encryption, depending on the system requirements (see Figure 7).

Figure 7 The Communications Stack

Diagram labels: eNav Gateway Information Source (IVEF Service) – Compression e.g. ZLIB – Encryption e.g. TLS/SSL – Transport e.g. TCP/IP – Decryption – Decompression – eNav Gateway Information Sink (IVEF Client).

The justification for this approach is the fact that these transport layers are already well-defined and standardised. Furthermore, standard compression and encryption algorithms are readily available.

Recommended layers (at this time) are TCP/IP for transport, TLS [5] or SSL [5] for encryption and ZLIB [7] for compression.

3.4.2 Service Negotiation

The IVEF interface is a service based protocol. This means that the data exchange between the parties is not pre-defined, but rather the result of a negotiation between the information provider and the information consumer.

3.4.2.1 Introduction

When a client (an e-Navigation Gateway acting as an information sink) wants to connect to server (an e-Navigation Gateway acting as an information source), it has to initiate the service by authenticating. To do this, the client sends a Login message to the server, the server validates the login requests and if correct, it sends a LoginResponse message. The server initiates the default service for that particular user. An example of a service is:

‘using an interval of 10 seconds, output all position information and voyage information about all vessels that are within in the following area (x,y) – (x1,y1) – (x2, y2) – (x3,y3)²

After the client is logged on, the server starts outputting the traffic image that matches the specification in the service.

The client can also send a ServiceRequest to terminate or change the active service. Services can be defined with different transmission characteristics, which allows a server push or client pull of the information, or a combination.

² Note that x, x1, x2 and x3 shall be specified in Longitude co-ordinates and that y, y1, y2 and y3 shall be specified as Latitude co-ordinates.

3.4.2.2 Service parameters

A service is defined by a number of parameters:

1. Object Selection, which objects should be sent?
   a Area based;
   b Filter based on the object properties (e.g. ship length > 50 m).
2. Item Selection, which information elements should be sent?
   a Track Information;
   b Vessel Information;
   c Voyage Information.
3. Transmission Selection, when should it be sent?
   a Single Occurrence (Pull);
   b Periodic, with specified update rate (Push);
   c A-Periodic, synchronous with update (Push).

A filter, based on object properties is a logical expression consisting of object property terms. These terms may be combined by the logical operators ‘or’, ‘and’ or ‘exclusive or’ in increasing order of precedence. An object property term may be negated by preceding it with ‘not’.

Object property terms may contain the standard numerical predicates ‘=’, ‘!=’, ‘>’, ‘>=’, ‘<’ and ‘<=’. In case of string-valued object properties, the predicates ‘=’, ‘!=’ and the wildcards ‘*’ and ‘?’ are supported, where ‘*’ means any sequence of characters, including the empty sequence and ‘?’ means any single character.

Filters are validated against the known object properties and the set of rules above. Invalid filters will be rejected.

3.4.2.3 Information flow dynamics

The interface supports the following messages; the contents and meaning of the messages mentioned below are covered in section 3.4.3.1

Table 1 Interface Messages

3.4.2.4 Timing and priorities

Control Information Messages have a higher priority than Real-Time Messages. This means that in an overload situation, Object Data Messages may be dropped in favour of Control Information Messages.

The service must start with a login message. The server will terminate the connection on transport layer when any other message is received, in order to prevent a possible Denial-of-Service (DoS) by mis-configured or malicious clients. If a service is interrupted at transport level, both server- and client sides will terminate the session and the client must login again to regain access to the service.

Messages, sent as a response to another message (LoginResponse, ServiceRequestReponse and Pong), must be responded to within agreed-upon period (e.g. 4 seconds). If the response message is not received within a specified timeout period, the sender may retry sending the message before terminating the service.

Ping messages must be sent when the sender has no other means⁴ to detect whether the receiver is still connected. The Ping message must be sent after an agreed-upon period of inactivity.

³ e.g. in an overload situation the server may drop messages, in this situation the Service Status message is sent to the client to make him aware of lost information.

⁴ Depending on the transport layer (e.g. SCTP), and receiver activity, the sender may detect the connection state of the receiver automatically. In this case the Ping message is not required.

The primary service use cases all have in common, that they are justified by at least one interaction with a ‘requesting service’ within the common e-Navigation system architecture: The ‘requesting service’ is any other service of the common shore-based e-Navigation system architecture making a request (logon) to the BIS in the previous chapter.

Figure 8 Overview of the primary service use cases of the IVEF Service

Note: The dotted lines indicate an inheritance relationship.

The complete list of external BIS Components and their categories is given below:

BIS Components:

• STATUS Service Status
• DATA Object Data
• SESSION Session Management

BIS Transmission Category

• SO Single occurrence (non-real-time)
• PER Periodic, with a specified update rate (real-time)
• A-PER: A-periodic, synchronous with the received track update (real-time)
• OC On change, updates are sent as data elements change

BIS Basic Service Data Elements:

• LOGIN: Authentication request
• LOGIN_RESP: Authentication response
• LOGOUT: Service termination notification
• SERV_REQ: Service request (category, area)
• SERV_RESP: Service response
• SERV_STAT: Service Status
• PING: Alive request
• PONG: Alive response
• TRACK: Track data
• VESSEL: Vessel data
• VOYAGE: Voyage data

3.4.3.1.1 Service Model

Figure 9 The DATA Service Component

3.4.3.1.2 Description

The DATA service component provides the following information:

1. Object track information; generally dynamic information about an object such as present position and speed.
2. Optionally Object vessel data; more or less pertinent information about an object such as call sign, IMO number and object dimensions.
3. Optionally Voyage data; such as Destination and ETA.

Service Data Structure
See APPENDIX 1.

3.4.3.1.3 VESSEL: Vessel Data

Use
The vessel information is used to identify and classify ships.

Risks
The vessel information is obtained from several sources including manual entry onboard a ship or in a VTS system or from database systems. It is possible that this data may be incorrect.

Service Data Structure
See APPENDIX 1.

Operating Characteristics

1. The BIS shall start automatically upon logon confirmation.
2. The data will be sent depending on transmission category.

3.4.3.1.4 TRACK: Track Data

Use
The track data combined with the data derived from VESSEL and, optionally, VOYAGE represents the actual traffic image.

Risks
The track data that is exchanged is the result multi-sensor fusion of various sensors. Sensor data is inherently noisy and subject to all kinds of disturbances therefore the track represents the best effort representation of the true situation, but not necessary the true situation itself.

Service Data Structure
See APPENDIX 1.

Operational Characteristics

1. The BIS shall start automatically upon logon confirmation.
2. The data will be sent depending on transmission category.

3.4.3.1.5 VOYAGE: Voyage-related Data

Use
The voyage-related ship information is used to classify ships with regard to cargo, draught, destination and the route.

Risks

1. The voyage information is entered onboard a ship or in a VTS system and it is possible that this data may be incorrect.
2. Information on the type of cargo provides only the classification of dangerous goods (Carrying DG, HS, or MP, IMO hazard or pollutant category A, B, C, D). This may not be sufficient in case of SAR/Pollution prevention.

Service Data Structure
See APPENDIX 1.

Operational Characteristics

1. The BIS shall start automatically upon logon confirmation.
2. The data will be sent depending on transmission category.

3.4.3.2.1 Service Model

Figure 10 The Session Service Component

3.4.3.2.2 Description

The SESSION service component is responsible for set-up, termination and terms-of-service negotiation.

3.4.3.2.3 LOGIN/LOGIN_RESP/LOGOUT

Use

1. A session is started by issuing a login request with the appropriate account details.
2. The account details are verified and the service responds with a login response granting or denying access to the service.

A session can be terminated by issuing a logout request.

Risks
Secured communication should be considered on the transport layer. IVEF provides only authentication support. Encryption and non-repudiation must be established on transport layer using suitable technologies (VPN, https, ssl, direct lines…).

Service Data Structure
See APPENDIX 1.

3.4.3.2.4 SERVICE_REQ/ SERVICE _RESP

Use

1. A service request is used to negotiate the terms-of-service, i.e. data content, area of interest and frequency of delivery.
2. A service request is acknowledged by a service response. Once acknowledge it will replace the previous service request.

Risks

1. A service request could lead to a data link overload. The client is responsible for issuing the service request that matches the available resources.
2. The server could be overloaded by to many user requests. Proper mechanism should be applied.

Service Data Structure
See APPENDIX 1.

3.4.3.3.1 Service Model

Figure 11 The Status Service Component

3.4.3.3.2 Description

The STATUS service component provides service-related status information and maintains alive status.

3.4.3.3.3 PING/PONG/SERV_STAT

Use

1. PING / PONG are messages exchanged at regular time intervals to verify alive status of the data link.
2. SERV_STAT indicates the status of the server to the client (ok/not ok) with an optional description.

Risks
No risks.

Service Data Structure
See APPENDIX 1.

3.4.4.1 LOCAL ADAPTATION

Use
The TAGGED_ITEM message can be used for non-standard, additional data exchange.

Risks
Requires additional agreement between client side and server side.

Service Data Structure
See APPENDIX 1.

The security model concerns the following aspects of the service:

• Authentication – this concerns both clients of the service and providers of the service.
• Authorization – this concerns the clients of the service.
• Data protection – this concerns the data that is being exchanged.
• Physical security – this concerns access to the server- and client systems and the interconnecting network.

The security model of the Basic IVEF Service addresses only the first two items, i.e., authentication and authorisation. The latter two items are outside the scope of this document. For data protection, suitable encryption methods can be defined at communication link-level (see section 3.4) or by providing a, so-called, Virtual Private Network (VPN) for clients.

The IVEF service is usually strictly contained within a shore-based e-Navigation system. Hence, it is assumed that appropriate measures for safeguarding the physical security of the service have been taken at the system level.

The model that is chosen for authentication and authorisation is a simple one, based on a shared secret between client and server (such a shared secret is commonly referred to as ‘password’). There is no specific authentication of the server (although this can arranged e.g., by using SSL certificates) and knowledge of the shared secret is assumed to identify the client. Once the client has authenticated itself, a set of client-specific rules is enforced by the server to guarantee that only those data are sent to the client for which the client has been authorised (see also section 3.9).

Note that the security model of the IVEF service is, in fact, independent of the traffic image exchange service and can easily be replaced by a more elaborate security model (e.g., based on certificates) if required.

The IVEF Service refers to the Presentation and Application layers as defined by the Open Systems Interconnection (OSI) Reference Model [3].

Figure 12 The ISO/OSI Reference Model (1 – Physical Layer; 2 – Data Link Layer; 3 – Network Layer; 4 – Transport Layer; 5 – Session Layer; 6 – Presentation Layer; 7 – Application Layer)

The definition of the lower-level telecommunication support layers is beyond the scope of the IVEF Service definition. Transmission of an IVEF-coded vessel traffic image can make use of any available communication medium, for instance a packet-switched Wide Area Network (WAN) or a Local Area Network (LAN).

The specific lower-level telecommunication protocol layers should be agreed upon by all partners of the data exchange, taking into account requirements such as data rates, reliability, security and latency.

In order to ease the exchange of data between different systems (e.g. potential network interconnection) it is advisable to apply standard telecommunication protocols (e.g. TCP/IP).

The IVEF Service uses XML [3] as a Presentation Layer protocol and defines the structure of the data to be exchanged over the communication medium.

The quality parameters of the IVEF Service depend on the intended use of the service: is it a real-time service, suitable for Vessel Traffic Services, or a near-realtime or non-realtime monitoring service that is regularly updated?

An important assumption of the service is that the server and client systems operate with a common time reference. Therefore, it is recommended to use a time service that provides UTC time, e.g., based on GNSS or internet time servers (NTP), at both the server and client.

A possible application of the IVEF Service is the provision of monitoring data to a stakeholder, for example a ship owner that wants to have information on his fleet. In such a case, only the relevant data will be delivered; everything else will be filtered out. Also, the update rate will be fairly low, say in the order of a few messages per hour. Furthermore, neither availability of the service nor message delays are critical issues.

Figure 13 Domains of Interest, Responsibility and Co-operation

Although the IVEF Service is a one-way service (from server to client), a common operational scenario, where VTSs are involved, is a mutual service, where each VTS provides data to the other (Figure 1).

In such a scenario, three areas are considered

1. Domain of Interest (DoI) – the geographical area which is of interest to a particular VTS centre. In general, this is the total sensor coverage area.
2. Domain of Responsibility (DoR) – the area for which the VTS centre is mandated to provide their VTS service, i.e. an Information Service, Traffic Organisation Service or Navigational Assistance Service.
3. Domain of Cooperation (DoC) – a subarea within the cross-section of the DoIs of the two VTSs where special processing is done to guarantee continuity of position, speed and course of objects.

In order to use the concept of the DoC, additional functionality is required in both VTSs.

This additional functionality consists of:

• the capability of associating multiple tracks to a single object, i.e. in the DoC, both systems will have a track and these tracks must be correlated to the same physical object, for instance via matching position and speed, or some other method; and
• the capability of smoothing out differences between the correlated tracks for the same object. The recommended processing to guarantee continuity across the Domain of Cooperation is to use a weighted average of the track states (see Figure 13).

In such a scenario, there should be a mutual agreement between the VTSs involved about the quality of service. This agreement should address:

• availability and timeliness of the IVEF Service;
• emergency/breakdown procedures, if applicable; and
• integrity of the VTS data delivered. This also concerns possible filtering of the data, for instance for commercial reasons.

A more complicated use case is where there are multiple providers of an IVEF Service to a common authority (Figure 14). The common authority is responsible for further distribution of the data to recognised data users. This means that the common authority is also responsible for validation of these users. In this case, there will be agreements between the common authority and the IVEF Service providers, but also between the common authority and the recognised data users. Obviously, the quality aspects in these agreements may be quite different, depending on the intended use of the data.

Figure 14 IVEF Service using a Common Authority

3.8.1 Well-formed messages

Each IVEF Service Message must comply with the W3C XML specification [3]. This specification defines an XML document as a text, which is well-formed, i.e., it satisfies a list of syntax rules provided in the specification. The list of rules is fairly lengthy; the most important rules are:

• A message contains only properly encoded legal Unicode characters.
• None of the special syntax characters such as ‘<’ and ‘&’ appear except when performing their markup-delineation roles.
• The begin-, end-, and empty-element tags, which delimit the elements, are correctly nested, with none missing and none overlapping.
• The element tags are case-sensitive; the begin- and end tags must match exactly.
• There is a single ‘root’ element, which contains all the other elements.

3.8.2 Valid messages

In addition to being well-formed, an IVEF Service Message must also be valid. This means that data elements and attributes must comply with the definition as specified in APPENDIX 1. In addition, the values must adhere to minimum value, maximum value, length, precision etc., as specified in APPENDIX 1.

3.8.3 Valid data

All track numbers, at any given time instant, should be unique.

3.8.4 Interaction behaviour

A login should be answered by a login response as indicated in Figure 15. The same holds, modus modendi, for ping/pong and service req/service respectively.

Figure 15 Login/Logout Activity Graph

IVEF user: Send LoginRequest.xml message to IVEF server → (LoginRequest.xml) → IVEF Server: Process the login request → (LoginResponse.xml) → IVEF user: Update internal status → Logout from the server (Logout.xml).

The Administration Model describes the aspects of the service that can be configured by service provider. For the IVEF Service, this concerns the maintenance of the user database. The user database contains the shared secret for each user and the user authorisations, i.e.. the restrictions, that are enforced by the server, on the data that is provided to a particular user. Additionally, the user database may contain default services for each user. These default services may be adapted by the respective user or be left to the discreteness of the service provider.

Considering the complexity of the user database, the provision of a graphical Human-Machine Interface (HMI) is strongly recommended for this purpose.

1. [1] IALA Recommendation on the e-Navigation Architecture – the Shore Perspective, IALA Recommendation eNAV-101.
2. [2] Generic e-Navigation Service Engineering Model Template, (draft) IALA Recommendation eNAV-210, 2009.
3. [3] Open Systems Interconnection (OSI) Reference Model, International Standards Organization (ISO) Standard 7498-1, 1994.
4. [4] Extensible Markup Language (XML) 1.0 (Fifth Edition), W3C Recommendation 26 November 2008, http://www.w3.org/TR/2008/REC-xml-20081126/ .
5. [5] The Transport Layer Security (TLS) Protocol, Version 1.2, August 2008, http://www.ietf.org/rfc/rfc5246.txt .
6. [6] The SSL Protocol, Version 3.0, November, 1996, http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt .
7. [7] ZLIB Compressed Data Format Specification, Version 3.3, May 1996, http://www.ietf.org/rfc/rfc1950.txt .

Object – a vessel, wind turbines, off-shore platform, bridge, an Aid-to-Navigation or a helicopter (SAR).

Gateway Service – a generic type of service, as defined in [1].

Vessel Traffic Image – the consolidated information about vessels and their movements in a particular area of interest.⁵

⁵ This information may be presented in different ways according to the task at hand.

Message structure (summary of the element tree below):

MSG_IVEF
 ├─ Header (@MsgRefId, @Version)
 └─ Body
     ├─ LoginRequest | LoginResponse | Logout
     ├─ Ping | Pong | ServerStatus
     ├─ ServiceRequest
     │    ├─ Area ─ Pos
     │    ├─ Filter
     │    ├─ Item
     │    └─ Transmission
     ├─ ServiceRequestResponse
     └─ ObjectDatas
          └─ ObjectData
               ├─ TrackData ─ Pos, NavStatus
               ├─ VesselData ─ Construction ─ UnType
               │             └ Identifier ─ OtherId, OtherName
               ├─ VoyageData ─ Waypoint ─ Pos
               └─ TaggedItem

Annotations: Root MESSAGE
Children: Body, Header

Annotations: HEADER part of every message with version and uniqueness information
Used by: Element MSG_IVEF

Children: LoginRequest, LoginResponse, Logout, ObjectDatas, Ping, Pong, ServerStatus, ServiceRequest, ServiceRequestResponse

Annotations: DATA login message with details of the user
Used by: Element MSG_IVEF/Body

Annotations: DATA login response with acceptance or deny with optional reason
Used by: Element MSG_IVEF/Body

Annotations: DATA logout message, the server will drop the connection if logout is successfull
Used by: Element MSG_IVEF/Body

Children: ObjectData

Annotations: DATA regarding an object in the supliers domain, contains at least 1 one of the sub elements (TrackData, VesselData, VoyageData)
Used by: Element MSG_IVEF/Body/ObjectDatas
Children: TaggedItem, TrackData, VesselData, VoyageData

Annotations: DATA describing a position report of an object
Used by: Element ObjectData
Children: NavStatus, Pos

Annotations: DATA position measurement of the geometrical centre of the object or location
Used by: Elements Area, TrackData, VoyageData/Waypoint

Annotations: DATA regarding static elements of an object
Used by: Element ObjectData
Children: Construction, Identifier

Annotations: attributes of the object regarding the physical construction
Children: UnType

Annotations: Object type according to CODES FOR TYPES OF MEANS OF TRANSPORT Revision 2 (UNECE CEFACT Trade Facilitation Recommendation No. 28 edition 2007)

Annotations: (local) Identification of vessel
Children: OtherId, OtherName

Annotations: Other Id's for the track than the world wide international standard Identifiers, e.g. regional indentifiers like ENI
Used by: Element VesselData/Identifier

Annotations: Other names for the track than the English name
Used by: Element VesselData/Identifier

Annotations: DATA regarding a movement of a vessel servers domain
Used by: Element ObjectData
Children: Waypoint

Annotations: Waypoint belonging to the route of this voyage
Children: Pos

Annotations: Generic key/value pairs, can be used to pass information that is not (yet) in the standard, provided server and user agree upon interface. E.g. Blue sign indication for inland waterways, references to voyage or vesseldata (URL)
Used by: Element ObjectData

Annotations: DATA alive message
Used by: Element MSG_IVEF/Body

Annotations: DATA alive response
Used by: Element MSG_IVEF/Body

Annotations: DATA describing the status of the server (full/available)
Used by: Element MSG_IVEF/Body

Annotations: DATA describing the service a user requests
Used by: Element MSG_IVEF/Body
Children: Area, Filter, Item, Transmission

Annotations: Geographical location based on one or more polygons
Used by: Element ServiceRequest
Children: Pos

Annotations: DATA detailing the supliers response to the users service request
Used by: Element MSG_IVEF/Body

Each attribute is defined with its Annotations, Type, Facets and the element(s) by which it is used ("Used by"). Attributes with the same name but different owning elements are listed separately.