G1111-1 핵심 VTS 시스템·장비 요건 작성 (요약·한영 대역)

IALA GUIDELINE G1111-1
PRODUCING REQUIREMENTS FOR THE CORE VTS SYSTEM

Edition 1.0, December 2022
urn:mrn:iala:pub:g1111-1:ed1.0

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

1. Introduction
  1.1 G1111 definitions
2. User interface
  2.1 Introduction
    2.1.1 Section definitions
  2.2 Characteristics of user interface
  2.3 Operational requirements
    2.3.1 Traffic image · 2.3.2 Decision support · 2.3.3 Voice communication · 2.3.4 Radar · 2.3.5 AIS · 2.3.6 Environmental information · 2.3.7 Electro-optical sensors · 2.3.8 Radio direction finder · 2.3.9 Long range sensor systems · 2.3.10 Replay · 2.3.11 Internal monitoring · 2.3.12 External information exchange
  2.4 Specific design, configuration, installation and maintenance considerations
    2.4.1 Physical layout · 2.4.2 Screen layout
3. Decision support
  3.1 Introduction
    3.1.1 Section definitions
  3.2 Characteristics of decision support tools
  3.3 Operational requirements
    3.3.1 Route management · 3.3.2 Traffic management · 3.3.3 Monitoring and protection of assets · 3.3.4 Environment and fairway monitoring · 3.3.5 Incident response · 3.3.6 Anomaly detection · 3.3.7 Collision avoidance · 3.3.8 Anchor watch · 3.3.9 Grounding avoidance · 3.3.10 Air draught clearance · 3.3.11 Area related · 3.3.12 Speed limitations
  3.4 Specific design and installation considerations
4. Data processing
  4.1 Introduction
    4.1.1 Section definitions
  4.2 Traffic image creation
    4.2.1 Sensors data processing · 4.2.2 Tracking and data fusion · 4.2.3 Traffic image performance parameters
  4.3 Ship visit and VTS data management
  4.4 Recording and archiving
5. External data exchange and information sharing
  5.1 Introduction · 5.2 E-navigation · 5.3 IHO/IALA data modelling domains · 5.4 Characteristics of external information exchange in VTS
  5.5 Data management considerations
    5.5.1 Data validity · 5.5.2 Access to information · 5.5.3 Data security and confidentiality · 5.5.4 Legal limitations · 5.5.5 Data integrity · 5.5.6 Communication links
6. Definitions
7. Abbreviations
8. References

List of Tables: Table 1 System tracking performance parameters · Table 2 Tracking performance criteria · Table 3 Typical information exchange between VTS and vessel · Table 4 Typical information exchange between VTS and shore-based entities
List of Figures: Figure 1 Graphical display of S-100 standard

This document addresses the core VTS system and needs to be read together with the other G1111 guidelines as listed below:

• G1111 Establishing Functional and Performance Requirements for VTS systems and Equipment
• G1111-1 Producing Requirements for the Core VTS system (this Guideline)
• G1111-2 Producing Requirements for Voice Communications
• G1111-3 Producing Requirements for RADAR systems
• G1111-4 Producing Requirements for AIS
• G1111-5 Producing Requirements for Environment Monitoring systems
• G1111-6 Producing Requirements for Electro Optical systems
• G1111-7 Producing Requirements for Radio Direction Finder systems
• G1111-8 Producing Requirements for Long Range Sensor systems
• G1111-9 Producing Framework for Acceptance of VTS systems

VTS systems are developing new capabilities and functionality as technology advances and as VTS requirements evolve. The new IMO Resolution A.1158(32) Guidelines for Vessel Traffic Services promotes more interaction between VTS systems and recommends greater connectivity to external third-party services. It is anticipated that VTS systems will be developing new capabilities and functionality over the coming years as such services become available and digital services evolve.

For example, the development of Maritime Autonomous Surface Ships (MASS) is progressing. At the time of publishing this guideline, IALA is producing a new guideline titled "Guideline on the implications of maritime autonomous surface ships from a VTS perspective".

A VTS system primarily comprises three elements: an IT platform, software functionality and a suite of communication devices and sensors. The communication devices and sensors are each covered by the new sub-Guidelines G1111-2 to G1111-8. This document is defined as the core VTS system because it comprises the IT platform and the software that creates the traffic image, processes sensor data and provides tools to support decision making. The software functionality offered by the core VTS system is expected to change with the currently evolving requirements and therefore it is expected that this document (G1111-1) will be updated more frequently than other G1111 guidelines. VTS providers are recommended to regularly monitor the status of G1111 to ensure that the latest version is being used. It is also recommended that VTS providers ensure that their procurement process includes the ability to apply software updates to their VTS system during its normal system lifecycle. These updates may be to provide new functionality and to ensure appropriate, up to date, cyber security.

The main purpose of this document is to assist the VTS provider in preparing the functional requirements for the core VTS system.

This document focuses on the human aspects of the VTS system design including:

• user Interface
• decision support
• data processing
• external information exchange

VTS system: within the G1111 guidelines, the VTS system is the VTS software, hardware, communications and sensors. This excludes personnel and procedures.

VTS Equipment: within the G1111 guidelines, VTS Equipment refers to the individual items of software, hardware, communications and sensors, which make up the VTS system.

VTS user: within the G1111 guidelines, VTS user is defined as someone with either an operational, technical, or administrative need to use or access the VTS system.

The purpose of this section is to support VTS providers in the specification of the user interface (UI) for a VTS system. This includes all interactions of people with a system such as operational traffic management and maintenance. This section should be read in conjunction with IALA Recommendation R0125 [9].

The user interface is the space where interaction between humans and technology occurs. The goal of this interaction is effective operation and control of the machine on the user's end, and feedback from the machine, which aids the VTS user including VTS operator (VTSO) gaining and maintaining situational awareness and in making operational decisions.

Specific terms used are as below:

Maritime domain awareness: is defined by the International Maritime Organization (IMO) as the effective understanding of anything associated with the maritime domain that could impact the security, safety, economy, or environment. The maritime domain is defined as all areas and things of, on, under, relating to, adjacent to, or bordering on a sea, ocean, or other navigable waterway, including all maritime-related activities, infrastructure, people, cargo, and vessels and other conveyances.

Traffic image: is the real-time presentation of vessels and objects and their movements, as well as other activities affecting maritime domain awareness.

Chart: A chart is a graphic representation of the maritime domain.

The UI of the core VTS system provides operational functionality to VTS users to enable the provision of an effective VTS, enter the necessary information in the system and maintain the system in a good condition. The principal goal of a UI is to provide users with an intuitive, reliable, accurate and efficient way of interacting with the VTS system for the task at hand.

This goal is achieved through a combination of:

• information presentation style and methodology – screens, windows, menus, status bars;
• ergonomically designed physical interface technologies such as mouse, keyboard, touch pad, roller ball, touch screen;
• visual and audible indications; and
• ergonomically designed UI.

Typically, the UI for the VTSO comprises the following:

• Presentation of the traffic image
• Voice communication
• Environmental information
• Information on vessels and planned voyages
• Tools supporting operational and emergency situation procedures
• System health

In addition, the VTS system may include individual system UI for the system maintenance and data entry tasks.

The UI should be reliable, designed and built to contribute to the overall availability of the entire VTS system. A failure of individual elements should not disable the entire UI, e.g., a failed screen should cause gradual degradation of the system but does not make the UI unusable.

These following considerations are equally important but fall outside the scope of this Guideline:

• ergonomically designed VTS user workstation – lighting, seating, desk arrangements, noise reduction; and
• VTS centre layout with respect to the overall VTS operational sector layout.

The following sections describe the operational requirements related to the UI. Refer to the relevant G1111 series documents for operational requirements regarding the individual equipment components of the VTS system.

The traffic image consists of a geographic presentation of the maritime environment (see 2.3.1.1) overlaid with real-time vessel positions. It is important that the traffic image is designed to complement the VTS user's role. The design should ensure the display of information is appropriate to the VTSO role and the amount of information does not degrade overall situational awareness.

The traffic image is the central part of the UI and, generally, provides the following functionality to the VTS user:

• Real time presentation of vessel positions and information relating to their identity, if available
• Geographic information and supporting graphics relating to the maritime environment
• Facilities for monitoring the speed of vessels and alerting of excessive speed or low speed situations
• Facilities for predicting dangerous situations
• Where it is relevant, facilities for protecting assets or other objects within the VTS area and alerting of unauthorized incursion into a prohibited area
• Facilities for monitoring adherence to defined routes and alerting about divergence from routes or TSS
• Monitoring of Marine Aids to Navigation (AtoN) and other environment monitoring sensors. and providing alerts if the data exceeds pre-defined thresholds

In a VTS system the chart is a geographical representation of the maritime environment of the VTS area of interest. This chart forms the background for the traffic image. The VTS Provider should specify required chart coverage, scales, layers and updating period.

In a VTS system the Chart can be based on:

• Electronic Navigational Chart (ENC) (e.g., based on IHO S-57 or S-101 standards)
• Raster charts (e.g., Admiralty nautical charts (ARCS))
• Other types of vector nautical charts
• Satellite images, land maps, GIS sources, etc.

ENCs should be kept up-to-date for consistency with charts used on board ships (it should be noted that if licensed charts go out of date, they may add text or other markings that could degrade the traffic image). There may be associated cost for maintaining up-to-date Charts in the system.

When displaying Chart data, the following should be considered:

• the requisite Chart layers selected for display;
• optional layer selection by the VTS user; and
• use of locally defined layers.

The UI should support both automated and manual management of layers. It should be possible to automatically update charts without affecting the continuity of VTS operations.

The chart presentation should utilize a consistent symbology set and colour palette suited to the local operating environment. Preferably, Chart symbology should follow IHO ENC standards. The current ENC standards, i.e., S-57/S-101, are designed for navigational purposes and consideration should be given to how to use them in a VTS system. Specifically, it should be ensured that the VTS UI specification includes the capability for authorized personnel to amend the portrayal of the chart to suit the VTS operational requirements.

The chart should support zoom and pan operations without introducing errors or distortions, i.e., all distances, depths and bearings should remain consistent during zooming and panning of the chart. Please note that different information can appear on different zoom levels.

The UI should have the ability to display sensor data in accordance with the operational requirements defined by the VTS Provider. The display of sensor data (e.g., radar video, AIS, Electro Optics, RDF environmental monitoring etc) may support operational objectives and may consider factors such as:

• Real-time situational awareness
• Display of previous vessel positions
• Visual confirmation of the real-time traffic image
• Possible detection and identification of small, hard to observe, targets
• Sensor status
• Redundancy

Vessel presentation is addressed by IALA Recommendation R0125 [9]. Each vessel should be displayed in a consistent manner such that the VTS user can intuitively understand the true geographical position of the vessel. This is achieved by displaying the vessel symbol in its true position relative to the underlying or reference chart. In addition, this positional information can be augmented by the presentation of the geographical coordinates of the vessel or by its bearing and distance from a selected location.

The UI should be capable of displaying all the information associated with each vessel displayed in the VTS user's view. The VTS user should be able to selectively choose what information to display in accordance with local operational requirements. A straightforward and intuitive method should be employed to ease selection.

The information should be displayed either in textual or in graphical form as appropriate, e.g., course and speed vectors.

The UI should be able to support the portrayal of alerts ("Caution", "Warning", "Alarm" and "Emergency alarm") in accordance with G1110. The portrayal of these alerts including thresholds often need to be configurable.

Functionality can be made available to the VTS user in a number of different implementations including, but not limited to:

• graphical "icons" or "tool buttons" often supported by short descriptive phrases. It should be possible, in the UI, to select display of buttons, text or both. User configurable "tool bars" may be used to group tool buttons;
• context sensitive menus, with content depending on cursor location;
• dedicated function keys and/or key-stroke short-cuts; The UI interaction should be intuitive and efficient. Wherever possible, the number of keystrokes should be minimized. Input fields should be, where possible, filled with appropriate default values by the VTS system; and
• supporting functionality for decision support tools (see Guideline G1110)

Voice communication with vessels and other stakeholders within the VTS area is an important part of the VTS system and therefore the usage of the radio equipment should be easy. The voice communications UI may be integrated with the traffic image presentation or may be separate, for example, as standalone touch screen user interface. The VTS user may be provided with the following facilities:

• Radio selection and status
• Channel/Frequency selection
• Squelch control
• Digital Selective Calling (DSC)
• Facilities to replay recorded conversations
• Microphone or footswitch with Press-To-Talk capabilities
• Headset and/or speaker.

Details about the operational requirements of the voice communications equipment is provided in sub-Guideline G1111-2.

Radar can accurately detect and track objects and their movements without requiring any transmission signal from the object itself, unlike sensors such as RDF or AIS. It is important to note that radar does not identify an object. Radar data may include both dynamic and static objects, including but not limited to vessels, navigation aids, islands, bridges, offshore structures and coastlines. Radar data maybe presented directly as radar video or can be processed to get additional information like object speed.

The VTS user may be provided with the following facilities:

• Real time radar video plot representing an objects present position and afterglow of moving objects representing their past positions
• Real time radar track data, label and symbol
• Radar control and settings possibly using user profiles/permissions
• Selection/choice of the radar for the traffic image

The UI should be configurable to enable the VTS user to obtain more information about the radar tracking sources of a target and to optimize the performance of the radar in variable conditions.

Details about the Tracking function is provided in section 4 Data Processing, of this Guideline.

Details about the operational requirements of the radar sensor equipment is provided in IALA sub-Guideline G1111-3.

The Automatic Identification System (AIS) currently provides details of ship position, its identity, and some supporting information to the VTS centre. In addition to navigation functions of AIS the system also supports the transmission of additional data via application specific messages. AIS has been successfully implemented across the globe. In high density shipping areas, the allocated frequencies (i.e., AIS1, AIS2) risk becoming overloaded. Effort is ongoing to remediate this risk by allocating additional frequencies and by re-design of the system to provide more bandwidth

To enable automatic vessel identification, consideration should be given to the inclusion of AIS data in the data fusion process.

The VTS user may be provided with the following facilities for:

• portrayal of Class A, Class B positions;
• detection and display of AIS-SART transmissions;
• deployment of virtual and / or synthetic AtoN, which will appear on the ECDIS of ships within the coverage area;
• sending and receiving short text messages; and
• controlling the update rate of position messages, which can be increased or decreased in a special circumstances.

Details about the operational requirements of the AIS equipment is provided in sub-Guideline G1111-4.

The UI should be able to display information derived from the available meteorological and hydrographical sources as required for historical, real time and forecast data.

Depending upon the nature and extent of the available data, and the operational context in which the data may be used, the data may be integrated with the traffic image or the data may be displayed on a standalone display device.

Details about the operational requirements of the environment monitoring system(s) is provided in sub-Guideline G1111-5.

An electro-optical system (EOS) may consist of imaging devices, such as daylight CCTV, day/night CCTV, infrared, thermal and laser-illuminated cameras. The EOS data may assist the VTS user in the detection, recognition, and identification of vessels and/or objects within the VTS area.

The VTS user may be provided with facilities for:

• "Point and click" within the traffic image to enable the VTS user to quickly direct the camera(s) to a position, vessel or object of interest
• A target (vessel) can be selected in the traffic image such that the camera keeps this target centred in view, even when the target is moving
• Manual control of the camera(s)
• Playback of video data

EOS data (video) may be overlaid on the traffic image or displayed on a separate screen.

Details about the operational requirements for EOS devices are provided in sub-Guideline G1111-6.

Radio direction finder (RDF) equipment can be used to assist the VTS user with vessel location and identification during communication from the vessel and is often useful in search and rescue operations. RDF provides a bearing line on the traffic image that indicates the direction of a radio transmission.

The VTS user may be provided with the following facilities for:

• Channel/Frequency selection
• Colour of bearing line (for multi-channel RDF receivers).

Details about the operational requirements of the radio direction finder is provided in sub-Guideline G1111-7.

The use of information derived from long-range sensors can supplement information in a VTS system and may support the monitoring of vessel activities located beyond the VTS area. However, it should be noted that long-range sensor data may not be real time and therefore careful consideration should be given to the inclusion of this data in the real time traffic image.

Typical long-range sensor systems include:

• Long Range Identification and Tracking (LRIT)
• Satellite AIS/VDES
• Satellite-based Synthetic Aperture Radar (SARSAT)

Details about the operational requirements of the electro optic/thermal Cameras is provided in sub-Guideline G1111-8.

The ability to record and replay the traffic image and associated synchronized voice communication to VTS users is regarded as a critical part of the VTS system and may be used as evidence in cases of infringement. The replay UI may be integrated with the traffic image or may be separate. VTS systems should ensure that recording continues while replaying.

The VTS user may be provided with the following facilities:

• Fully synchronized replay facilities
• Selection of the source data (voice communications, sensors, data processing) and time period
• Selection of any combination of sources
• Instant replay of the traffic image and voice communications for a configurable time period
• Pause/stop/speed selection
• Export in an industry standard format

The recording of all source data should be automatic and archived at regular intervals. Access to system administration settings should be configurable as approved by the VTS provider.

Details about the recording and archiving function is provided in section 4.4 of this Guideline.

The UI should be capable of presenting the overall status of the VTS system including all the major system components/subsystems and the infrastructure. Typically, this will include:

• Communications – data and voice
• Sensors
• Main information technology (IT) elements – software, servers, processors, PC, workstations, data storage and network
• Where applicable - housekeeping, such as security cameras, access controls (status of doors and locks), status of heating and/or air-conditioning

It is essential that VTS users are provided with an intuitive, timely and readily accessible view of the VTS system status and health. The required level of detail may depend upon the role of the user. Sub-system status may be summarized hierarchically to suit each anticipated situation.

External connectivity of VTS systems is becoming increasingly important to exchange information with:

• Other VTS systems
• Allied services
• Third party service providers (e.g., meteorological forecasts and e-navigation maritime services).

Display of such additional information should be selectable by the VTS user. Specifications for specific VTS implementations should include functional descriptions of the various operational information sets that are required to be displayed to the VTS user.

Details about external information exchange is provided in section 5 - External Data Exchange and Information Sharing, of this Guideline.

The provision of vessel traffic services is the prime objective of the VTS user and the physical layout of the VTS centre should serve to enhance the ability to provide the service.

The VTS centre layout should consider:

• room layout;
• ambient lighting and comfort settings;
• noise levels, background machine noise as well as voice communications;
• screen specifications, including resolution, size, etc.;
• number of screens per VTS user workstation and their arrangement;
• number of workstations and operational sectors;
• location for the rest of the personnel;
• safety and security arrangements; and
• wall screen displays.

To provide optimal operating conditions in a VTS centre, it is of paramount importance to create a comfortable and supportive environment to facilitate the ability to concentrate with minimal distractions.

When contemplating a new or refurbished VTS centre, consideration should be given to seek ergonomic design consultancy to assist in defining the optimum design for the centre, particularly to minimize fatigue factors during VTSO watch schedules.

The environment should consider the advantages of air-conditioning, good and appropriate lighting, minimization of externally and internally generated noise distractions, nearby rest facilities to minimise user downtime. Special consideration should be given to lighting and climate control during night.

The layout should also consider emergency procedures and the role of the VTS centre in emergencies, as part of a regional or national infrastructure.

The screen layout needs to consider the appropriate use of multiple windows, pop-up windows, locked and flexible window positioning, overlapping and side by side windows containing chart data, textual information and dedicated status information etc. The relative importance of each information type needs to be accommodated within the adopted design, in particular the VTS traffic image should remain visible.

In the case of workstations employing multiple screens, care should be taken to ensure that the same concepts of window management are extended over the entire screen layout. It is important to ensure the VTS user can easily keep track of the cursor position.

The UI should consider allowing selection and filtering of the presented information to tailor the screen to the task in hand, including dedicated search functionality.

The UI may also support the interactive and automated provision of help text to the VTS user. For example, hovering the mouse over a particular tool button can result in the screen of a concise help reference for the use of that particular tool.

In accordance with IALA Guideline G1110 [8], decision support tools (DST) are used to help enhance situational awareness and the decision-making process of VTS users by providing analysis and insight to developing or emergency situations, in real time, near real time and for long-term planning.

Due to the perpetually evolving nature of VTS related concepts and technologies, consideration should be given to the continual development and refinement of DSTs as appropriate to meet future needs.

Alarm: A high priority alert requiring immediate attention and action (IMO Res. A.1021(26)).

Alert: An announcement of abnormal situations and conditions requiring attentions (IMO Res. A.1021(26)).

Caution: Lowest priority of an alert. Awareness of a condition which does not warrant an alarm or warning condition, but still requires attention out of the ordinary consideration of the situation or of given information (IMO Res. A.1021(26)).

Decision-maker: A person or group authorized to make decisions.

Decision support tool: A tool to assist the decision-maker in real-time, near real-time and long-term planning.

Emergency alarm: Highest priority of an alert. Alarms which indicate immediate danger to human life or to the ship and its machinery exits and require immediate action (IMO Res. A.1021(26)).

Long term planning: Refers to the action of analysing currently available information to proactively manage predicted future events.

Near real-time: Refers to predictions of developing situations.

Real-time: Refers to the immediate action taken to respond to current or developing situations.

Warning: Condition requiring immediate attention, but not immediate action (IMO Res. A.1021(26)).

Decision support may consider such aspects as vessel behaviour, vessel traffic development, legal criteria, incident management, environmental monitoring and forecasts, organizational and operational procedures. It can correlate and combine these aspects to give validated advice.

Decision support tools (DST) may be self-learning, make real-time risk assessments and/or provide recorded and statistical data to the VTS Provider to improve safety, efficiency and environmental protection. In view of this, decision support tools should be configured or tailored for each VTS, as appropriate. Alerts, raised by decision support, should be presented in a timely and relevant manner aligned to operational requirements.

Decision support tools are reliant on the timeliness, accuracy and integrity of the incoming data and the underlying model-based analysis of that data. Decision support tools may also be used to evaluate the performance of the VTS itself. For example, the process of establishing a vessel traffic service supported by a VTS system starts with a risk assessment of a potential VTS area. The risk analysis process leads to the identification of mitigation measures which will contribute to the definition of operational requirements for the VTS. Decision support tools may then assess whether these operational requirements have been achieved.

Decision support tools should be able to assist decision-makers by providing facilities that aid the management of risk situations and, thereby, reduce the level of risk. In addition, appropriate decision support tools may also provide a means of measuring the level of risk reduction achieved and assessing near miss situations.

Decision support tools may help the VTS user and other decision-makers with the implementation of the appropriate predefined and approved procedures for route management, traffic management, monitoring and protection of assets, environmental and fairway monitoring, incident response and anomaly detection.

Decision support tools aim to reduce the workload of VTS users. They may be based upon real-time, near real-time or long term, assessment of risks associated with the traffic situation. Where the risk level exceeds a pre-defined threshold, an alert may be raised, for example from "Caution" to "Warning", and the VTS user may be advised of the recommended risk mitigation options.

Management facilities should be provided for the adjustment of alert thresholds and the possibility of de-activation. However, it is recommended that the appropriate alert thresholds should be part of the agreed operational procedures to ensure that the deployed system is fit for purpose. Alert parameters should be set at levels appropriate to support the goals of the VTS service, being careful to avoid excessive notifications that may cause operator fatigue, distraction, and other factors that may negatively impact overall safety and efficiency.

Management reports may be generated from alert statistics and/or VTSO actions for analysis.

To reduce repeated alerts relating to the same vessel and situation, the reporting of alerts should incorporate filtering techniques, such as hysteresis.

Management reports may be generated from alert statistics and/or VTS user actions for off-line analysis.

The following is a list of common decision support tools groups.

Route management includes the sailing or route plan used by visiting ships and is an important aspect in ensuring safety within the VTS area. Over time, the VTS system records many ship visits and the routes that they use. These can be analysed for long term planning purposes to optimize safety and thereby define safety limits for each route used within the VTS area. High risk situations on a route can then be configured to provide useful alerts and ETAs for the VTS user when monitoring vessel movements in real time. For example, compliance with a sailing plan may alert a VTS user when a ship's track is outside the route spatial or temporal boundaries that have been defined for that specific ship.

Decision support tools can provide route analysis for the long-term planning of route management and for definition of alert thresholds to support real time operations.

Planning the arrivals and departures and understanding the limits for different types of ship is also an important part of ensuring safety within the VTS area through the definition of thresholds for providing useful alerts to the VTS user. These alerts may include:

• Close quarters and collision avoidance
• Grounding alerts
• Speed alerts
• Time slots
• Just in Time arrival
• Anchor watch
• Air draft clearance.

It also enables the definition of near miss alerts for different types of ship that can be further analysed when improving the overall safety measures of the port or TSS. Real time and near real time monitoring supported by appropriately configured alerting will support the VTS user.

Decision support tools enable the VTS Provider to plan the most effective use of alerts for real time and near real time operations.

A VTS area may include some significant assets that have certain risks or vulnerabilities such that the VTS user may wish to apply special monitoring and management techniques to ensure safety of vessel traffic and of the assets.

Examples of such assets may include offshore platforms (including FPSOs) and pipelines, offshore windfarms, subsea cables, environmentally sensitive areas, protected wrecks, and Marine Aids to Navigation, etc.

The protection of assets within the VTS area may involve the establishment of a protection zone around the asset with alerts being triggered if an unauthorized vessel enters the protection zone. The protection zone may be established based upon national legal requirements or may be the output of the risk assessment process that was undertaken when establishing the operational procedures. The size, shape and access permissions for the protection zone around the asset will be defined through the long-term planning assessment such that the VTS system can be correctly configured to provide the asset protection required. This may consider typical traffic patterns (route management) in order to quantify risk and to provide alert thresholds based on near miss and zone violations.

Decision support tools may provide forecast alerts relating to the risk of an unauthorized vessel entering the protected area and/or an alert when the vessel enters the protected area.

The VTS user should always be aware of environmental factors that could affect normal vessel traffic operations. Poor weather conditions may impact the expected time of arrival for a vessel and the overall plan for the services that would be supplied to that vessel when it arrived at its berth. It is therefore important to forecast the impact of weather within the VTS area and while a vessel is enroute from its previous port.

Ensuring adequate under keel clearance is an important factor in the planning and efficient management of ship visits, especially in approach fairways. VTS providers should consider monitoring tidal height and water depth and assessing the result against the draught information from visiting ships to ensure unhindered access including factors such as squat modelling and water density factors.

In line with the IMO greenhouse gas strategy, it is intended that emissions from ships will be reduced in accordance with the target dates published by the organization. VTS providers may consider measuring and recording emissions from visiting ships.

Environmental factors that could be considered for monitoring and forecasting may include:

• Wind speed and direction
• Rainfall
• Temperature
• Humidity
• Atmospheric pressure
• Visibility
• Tidal Height
• Wave Height and Sea State
• Water depth
• Current speed and direction
• Ice state
• Oil Spill Detection
• Ship gas emissions

Where the VTS provider is tasked to support incident response, it is essential that the VTS system provides comprehensive recording of the real time traffic image such that any incident can be replayed and analysed in order to improve operational procedures and reduce incidents.

Decision support tools may help visualize and plan the allocation of resources to assist in the prediction of where an object, person or vessel may drift over time, which together with search planning tools may ensure a quick and appropriate response is initiated.

Decision support tools may be provided for the VTS user to record additional details that can be associated with all the vessels involved in the Incident.

Further reference should be made to national guidance and the IAMSAR Manual.

VTS providers are encouraged to consider setting threshold limits related to appropriate routes for the VTS area in terms of a vessel's speed, rate of turn, etc so that the VTS user is alerted when abnormal behaviour or an unexpected route deviation arises.

Collision avoidance tools are intended to alert VTS users to potential collision incidents. Such tools may use CPA / TCPA and/or safety domain concepts.

The Closest Point of Approach (CPA) and Time to Closest Point of Approach (TCPA) are numerical indices characterizing the imminence of a close approach between two vessels. These indices must be pre-defined and interpreted together with a logical "AND" function. The definition of these indices should consider the range and azimuth (bearing) accuracy of the sensors, especially in the case of radar-only vessel tracking, as the sensor accuracy will impact the accuracy of the CPA and TCPA calculations.

Safety domains establish a zone around each vessel and monitor if another vessel will potentially enter that zone. Safety domains may be particularly relevant in areas of dense traffic. The size and shape of the zone can be used to reduce the number of false alerts.

If different areas are monitored according to different rules concerning alert thresholds, it should be possible for the VTS users to visualize the different zones and the associated alert levels.

If different alert levels are supported, the display of an alert should provide clear indication of the criticality of the alert.

Anchor watch should alert a VTS user that an anchored ship has drifted beyond the safe limits of its defined anchorage. "Anchor Watch" zones are monitoring zones that are based on a given vessel position and include its legitimate movement due to tidal conditions and the relevant sensor accuracy. The boundary should therefore be derived according to the greatest distance from the anchorage point (low tide limit). The ship should remain inside this zone in all but the most extreme conditions and alerts should advise the VTS user that the vessel has drifted beyond the "Anchor Watch" limits.

Distances should be expressed in the standard unit of distance.

Where meteorological and/or hydrographical forecast information is available, a decision support tool may be able to alert the VTS user that changing conditions could put certain vessels at risk of breaching their Anchor Watch limits.

A grounding alert requires details of the draught of the vessel and the bathymetry. Tidal information can be used for more accurate calculations. The alert is raised if the estimated under-keel clearance along the predicted path of the vessel is less than a pre-defined threshold. The source of draught information should be checked to ensure accuracy.

Depending on the capabilities of the VTS, the accuracy of bathymetric maps, of water height due to the tide and of the draught of the vessel, the grounding threshold may be adjusted by VTS authorities based upon their assessment of acceptable risk parameters, e.g., to allow for squat and variations in water density. It is recommended that these thresholds should be determined assuming worst case data accuracy.

Air draught is an alert that requires the air draught of the vessel, the obstacle clearance, bathymetry and tidal information. The alert is raised if the estimated clearance is less than a threshold.

Depending on the capabilities of the VTS, the accuracy of bathymetric maps, of water height due to the tide and of the air draught of the vessel, the air draught threshold may be adjusted by VTS authorities based upon their assessment of acceptable risk parameters e.g., to allow for squat and variations in water density. It is recommended that these thresholds should be determined assuming worst case data accuracy.

These alerts warn the VTS user that a ship has, or is about to, penetrate a stationary or moving pre-defined area or cross a pre-defined navigational line.

International regulations, national recommendations or VTS providers may define areas where no shipping is allowed under normal circumstances. These areas may be Special Protected Areas (SPA) or Marine Protected Areas (MPA), Prohibited zones, or Particularly Sensitive Sea Areas (PSSA), as defined by IMO or national authorities.

These alerts warn VTS users whenever a ships speed over ground (SOG) is outside pre-defined boundaries. Competent and VTS authorities may define upper and lower speed limits for navigation in certain areas such as port zones and traffic lanes. To implement this functionality, sufficiently accurate and reliable speed estimation should be available to avoid false alerts.

The selection of DST for a VTS system should be considered in conjunction with a historical analysis of the specific behaviour, characteristics of the vessels, typical routes, and hazards that may affect the efficient and safe movement of vessels within the VTS area affected.

Refer to IALA Guideline G1110 [8] section 3, for examples of where DSTs may assist in ensuring the safety and efficiency of navigation, through route and traffic management, monitoring and protection of assets, environmental and fairway monitoring, incident response and anomaly detection.

A VTS system uses data processing to create the traffic image, to manage ship visits, to support the VTS user with decision support tools and to record activity.

This section will provide further information to support VTS providers in the management of data associated with ship visits, the processing and data fusion of radar data in order to provide high quality track data for the traffic image and the recording of activity for analysis purposes.

For general terms used throughout this section refer to IEEE Std 686-2017 [14]. IEEE Standard Radar Definitions

Specific terms are defined as follows:

Confirmed track: A track that has previously passed the criteria for track initiation, tentative track formation and has been subsequently promoted to a confirmed track.

Data: Is everything that is potentially useful and relevant to the VTS user.

Data Fusion: In the tracking context, data fusion is the combining of observation updates from more than one sensor to create one track based on all available sensor information.

False Plot: A plot resulting from a phenomenon unrelated to VTS operation or from a reflection of an actual object.

False Track: A track created using sensor data that happens to behave in target-like manner but actually relates to phenomena unrelated to VTS operation or results from reflections of actual objects.

Note, the sensors and indeed the tracking process may not be able to differentiate between small detectable objects unrelated to VTS operation (birds for example) and at the same time to correctly detect and track small objects that are related to VTS operation.

Information: Is the result of the processing of the data. It should be appropriately useful and appropriately clear to aid the VTS user and the decision-making processes. In the context of a VTS system, there are many pieces of data, each with its own importance, validity and integrity.

Latency: A measure of time delay experienced in a system. Used here to indicate the time from a sensor first gathering data relating to a target, to the time the corresponding data is presented to the user (e.g., VTS user display or decision support process).

PD: Is the probability of target detection at the output of a sensor, subsequent to plot extraction, but prior to tracking, and presentation. Note, in some systems the boundary of the sensor and its achieved PD complicate this definition – clarification may be required to avoid misunderstanding arising from, for example, data compression or video processing.

Plot: A generic term to describe the report resulting from a sensor observation.

Plot extraction: The process of determining measurement values for a sensor observation from the raw sensor data. In the case of a radar sensor, this typically consists of comparing the video level with a threshold which can be (dynamically) adapted to local background noise and clutter conditions.

Plot-to-track association: The process of determining correlation of new sensor plots with existing tracks.

Processing: Involves summarising, analysing, converting, recording, sorting, calculating, disseminating, storing, aggregating, validating, tabulating, etc.

Radar: As referred to in this document, this relates to all aspects of the radar from sensor through to the availability of radar information (for presentation) from one or more radar sensors to the VTS user.

Radar track (report): A target report resulting from the correlation, by a special algorithm (tracking filter) of a succession of radar-reported positions (radar plots) for one object.

Radar video: A time-varying signal, proportional to the sum of the radio frequency (RF) signals being received and the RF noise inherent in the receiver itself. Radar video can be an analogue signal with associated azimuth reference information, and/or video data (including amplitude) in digital format.

Sensor: In the tracking context, a sensor is a device for observing and measuring, as a minimum, position information for a target or potential target.

Sensor PFA: Is the probability of false alarm (plot) at the output of a sensor, subsequent to plot extraction, but prior to tracking, and presentation. This is generally expressed as an average number per unit area.

Signal to noise ratio: The ratio of a measurement of the power of a return from a target vs. the local sensor noise around the location of the target

Tentative track: In the early part of the track lifecycle, a track is considered to be a tentative track until sufficient criteria are passed for it to be promoted to a confirmed track or for it to be discarded as a likely false track.

Track: The geo-spatial data, accumulated by the system, relating to an object of interest. As a minimum, this consists of unique identity, timestamp, current position and velocity, the associated quality of that information and other relevant attributes.

Track coasting: A feature that maintains tracks in the absence of expected sensor updates.

Tracking: The process of following an object to enable historical, current and future target positional and velocity information to be displayed and otherwise processed in support of the VTS system objectives.

Tracking PFA: Is the probability of false track at the output of the tracking process, prior to presentation. This is normally defined as number of occurrences per unit area per unit time.

Track initiation: This is the process of first creating a track from plots that could not be associated with existing tracks.

Track merging: As two approaching tracks come together, it may not be possible for the available sensors to individually discriminate and therefore to measure their continued presence and position. If this situation persists for some time, one of the tracks may be maintained whilst the other is terminated.

Track splitting: A single track may unpredictably split into two or more discernible objects which may invoke rules for track initiation on some or all of the resultant likely tracks.

Track swapping: The (usually unwanted) transfer of a track identity (track label) to another track. This can break the intended association between a track and a physical object.

Track termination: The process of permanently removing a track.

An up-to-date established traffic image is essential to the successful operation of a VTS. This is typically presented as a map showing fixed geographical and man-made features and moving objects to aid decision support and general traffic management of the VTS area.

The traffic image is created by processing data from the available sensors. The tracking and data fusion process accepts sensor data from individual VTS sensors and, possibly, other available sources. The resulting real time traffic image is displayed to the VTS user; it can be used in decision support and may be provided to other agencies and allied services. Within this Guideline, the "Sensors data processing" and "Tracking and data fusion" sections consider sensor data from various sources including:

• radar sensors;
• AIS;
• externally interfaced VTS systems; and
• Long Range sensors.

Note that contributions from mobile sensors (e.g., ship-borne sensors) are not normally considered. There may, however, be benefits to integrate these, such as extended sensor coverage or improved local situational awareness, at the expense of considerable additional complexity. The availability of more data bandwidth from ship to shore may facilitate integration of mobile sensors in the future.

Individual sensors are main source of input information for the tracking and data fusion process. In general, the tracking and data fusion process is fairly sophisticated in order to align the raw sensor data and to deal with less ideal behaviour of the sensors. In an ideal world, sensors have infinite accuracy and will always provide a measurement of only the target of interest. In reality, sensors have finite, limited accuracy and their measurements are affected by errors due to noise and misalignments. Also, sensors may generate unwanted measurements that do not represent real targets of interest. For confirmation, or as a backup, measurements can be displayed directly, e.g., radar video, but more reliable estimates of a target's position and speed vector can be obtained by further processing the measurements.

Sensors need to be accurately calibrated with respect to each other, so that a detectable point target is measured to have a common location from all sensors providing data on such a target. Calibration can take the form of manual bias entry, combined with a routine checking procedure, or automatic identification and correction of measurement biases within the tracking process.

The accurate time stamping of sensor data, reflecting the time of observation, is essential for establishing and maintaining a correct and accurate traffic image. Another important factor is the combined communication and processing latency from observation to the moment of traffic situation and display update. This determines if information can be presented in a timely fashion to the VTS user (or external system).

An AIS, satellite AIS or LRIT position message is known to originate from a single GNSS receiver and provides a time stamped position, course and speed which can be assumed, with significant confidence, to originate from one target. It is possible, however, that multiple targets share the same identity. Furthermore, targets may carry multiple active transponders, not necessarily emitting the same position and identity;

The plot extraction process lies between the collection of raw sensor data and the extraction of useful information from that data. It is highly dependent on sensor type. The process of radar plot extraction is more elaborate and may be affected by significant noise from the environment. This may give rise to unwanted measurements that do not represent real targets (false alarms). There is a trade-off between the amount of unwanted measurements and the ability to detect weaker (smaller, more distant) targets. Allowing weaker targets to be detected will increase the amount of unwanted measurements (and, hence, the likelihood of creating false tracks).

Multiple plots may arise from a single object (e.g., as a result of physical size and shape of the target) and these need to be processed in an appropriate way. Also, it may not be possible separate targets that are close to each other, resulting in only a single measurement for multiple targets.

Extracted plots, regardless of the sensor, should include the following attributes:

• Time of measurement
• Measured position and positional uncertainty
• Originating sensor

In addition, attributes may include:

• Identity
• Speed
• Physical extent of the target
• Signal strength

In general, the plot extraction process is fully automatic, relying on programmed algorithms tuned to optimize the process to the sensor characteristics and the topography of the coverage area.

It is recommended that a VTS system takes advantage of data available from multiple sensors and external sources by integrating this data in an appropriate way. Integration can be as simple as overlaying multiple sensor data sources on the VTS user Interface, but significant advantages can be gained by processing and combining the data within the data processing function. The use of data from all available sources can significantly improve the positional accuracy of the track and the reliability of associated track information (such as identity, target type and size, COG, SOG, manoeuvre indication).

The tracking and data fusion process attempts to correlate data from individual VTS sensors with existing tracks for the purposes of building a traffic image. Data that does not correlate with existing tracks, is handed over to the track initiation process to postulates new tentative tracks. Tentative tracks will, subsequently, be monitored until they either become confirmed tracks or are discarded as likely resulting from unwanted measurements.

The tracking process uses models of both the sensors and the target behaviour to provide a best estimate of, at least, the target position, course and speed over ground (COG, SOG). These models are also used to optimize the correlation process to combine new measurements with the existing tracks.

The design of the tracking and data fusion process should take into account the need to translate positional information into a common geographical reference system such as WGS84. Fusion of the data can be either combining tracks, created from individual sensors, or introducing the raw measurements from all sensors directly into the track filtering process. In both cases, the track fusion process may have to properly deal with biases in the data originating from the different sensors (e.g., differences in the North alignment of radar sensors).

In a fully calibrated system (i.e., with minimum measurement bias), the output of a data fusion tracker (multi-sensor tracker) should not reduce the quality of the information coming from the most reliable source and, in general, improved accuracy and reliability should be expected. Track fusion also provides redundancy to minimize the consequences of individual sensor failure.

Track fusion is an automatic process and, as such, it is recommended that VTS user interaction with this process be limited.

Plot-to-Track association is the selection of the most likely track, representing the object, for each (incoming) plot. This may result in more than one plot being assigned to the same track (a broken up target) or to one plot being assigned to multiple tracks (targets close to each other).

The extracted plots are passed to the tracking process and those which fail to correlate with existing tracks become candidates for the initiation of new tracks. Those plots which correlate successfully with existing confirmed or tentative tracks will be used to update the position and speed (and, possibly, other attributes) of the associating track.

The plots remaining un-associated following the plot to track association process may contain plots originating from real targets. These plots are used in the track initiation process to establish a list of tentative tracks.

In general, the track initiation process should be automatic but geographic limitations may be invoked upon areas where automatic initiation should and should not occur. Although VTS systems often include the requirement for manual track initiation, reliance on manual track initiation can significantly load and, therefore, distract the VTS user. The dependence on manual track initiation should, therefore, be kept to a minimum.

It can be assumed that an externally sourced (and likely to be externally maintained) track is very likely to become a track in the VTS area of interest and therefore a track can be initiated. AIS data, which have failed to associate, will typically initiate a new tentative track (although due consideration should be given to the quality of the received AIS data, in particular of class-B transponders and in areas with limited satellite view). Radar plots, which have failed to associate, require additional confidence building algorithms before completing the initiation of new tracks.

The track initiation process, in combination with the plot extraction process, needs to strike a balance between the ability to detect true targets of a certain type (especially small targets) and the possible initiation of false tracks. Lowering the plot detection threshold or relaxing the initiation rules, allows more true targets to be detected at the expense of an increased false track rate. This will require system level tuning (supported by modelling if appropriate) to optimize performance and achieve the VTS operational requirements.

In other words, there is a trade-off between a higher target detection probability, a larger initiation delay or a larger false target rate.

The extracted plots which associate with existing tracks are used to update those tracks by combining the plot data with the track predictions in accordance with the chosen tracking filter(s). Various mathematical techniques are available to forward predict and update the track information, including track position and speed. These techniques vary from simple to very complex with a more or less increasing level of performance. In complex traffic situations, it may be appropriate to consider the use of the more advanced algorithms.

Tracks should be validated against the possibility that they are, or have become, false tracks. Assessment of track quality and erratic track update behaviour may be considered as techniques to provide validation. The tracking system should be able to react quickly and initiate termination rules once it becomes clear that a false track may have been created. False tracks, from whatever mechanism, should be avoided in safety critical areas and occasionally accepted in other areas where surveillance and traffic monitoring is the priority. Note; operational requirements regarding the detection of small targets may result in an increase in the probability of false tracks, so due consideration should be given to these requirements.

If a confirmed track either:

• moves outside a user defined coverage area;
• moves into a user defined non-tracking area; or
• if the track cannot be updated with new plots for a certain amount of time;

then the track should be terminated. Sometimes termination also could happen if track updates do not follow the modelled behaviour. In certain cases, as defined by the VTS Provider, the VTS user should receive a warning of imminent track termination, and also the VTS user may be provided with a facility, via the UI, to manually terminate a track.

It may be appropriated to not terminate tracks immediately when there are no sensors measurements but allow some time during which the track is coasting, e.g., vessels may enter areas of limited sensor coverage or may be obstructed by other vessels. In such cases, coasting rules may be defined to take into account the need for intentional track coasting such as in areas obscured from sensor coverage.

Track loss may occur as a result of targets not being detected by sensors for a certain time. Note: the loss of target detection is likely to occur in the vicinity of obstructions such as bridges, land masses etc. In order to cover expected areas of poor detection, the system may be configured to bridge gaps in coverage e.g., by coasting previously reliable tracks. The VTS authority should address any critical areas, such as the vicinity of bridges, and explain expectations to tracking to allow VTS suppliers to design appropriate rules in such critical areas. Another source of track loss is the occurrence of target manoeuvre outside the modelled behaviour.

The conditions for track termination may need to be adaptable and adjustable in different areas or traffic / weather conditions. This additional complexity may be set up on system commissioning, user adjustable or even automatically reactive to real world data.

In rare cases there may be some classes of tracked objects that require special track processing. Special rules may be required to allow for unexpected appearance and disappearance of submarines, or the need to track extended objects such as icebergs, oil slicks and weather effects (and to monitor their size and changes in their shape).

Tracks should be uniquely identified. This identification should be based on operational procedures and is usually independent of other methods of vessel identifications such as internal and external databases (SafeSeaNetSes ame, single-hull database, various incident/blacklists, on-board identity, adjacent VTS and other allied services etc.) and local identification methods such as those arising from AIS data, voice communications and associated direction finding, camera recognition (manual and automatic).

Consideration needs to be given to the output of track data to other VTS sub-systems such as the display of the established traffic image to the VTS user. The appropriate tracking information will need to be available for display and for presentation on demand. It may also be appropriate to offer the ability to access and display raw sensor data, plot data and tentative track data.

The UI aspects of the display function will consider the use of symbols, colours, text etc. for the display of track information.

Track information, which might be required for display to the VTS user, includes:

• current location
• vessel identity
• speed and course over ground
• track history
• contributing sensors (and lack of updates i.e., coasting)
• associating plot data
• destination and ETA
• passage plan
• cargo
• crew and passenger details

The effective use of the VTS traffic image, reliant on accurate and reliable tracking and positioning of the objects of interest in relation to fixed and movable hazards within the VTS area, is fundamental to safe and efficient management of traffic. The following sub-sections describe the relevant parameters.

Key tracking system input parameters to be specified by the VTS system designer, based on the parameters specified by the VTS Provider, include:

• expected target characteristics (size, speed, manoeuvrability, height, type etc.);
• maximum number of targets to be tracked (it is recommended that the track capacity should be sufficient to accommodate ≥2 times the heaviest traffic predictions, including an allowance for false tracks);
• typical desirable and undesirable traffic behaviour, including traffic 'lanes' and traffic densities;
• anticipated variations in weather and sea/water conditions;
• external inputs and outputs to / from the tracking function;
• areas with specific tracking conditions (i.e., with automated tracking initiation inhibited);
• acceptable VTS user interaction with the tracking function; and
• sensor network design including its specific characteristics including latency.

The determination of performance parameters to specify a VTS tracking system design is a complex task and the achieved tracking performance is heavily dependent on the sensor data provided as inputs to the tracking process. The sensor requirements should consider information provided elsewhere in the other G1111 guidelines.

The location and configuration of the sensors determines the attainable performance of the VTS system. A tracker design needs to be tuned to optimize overall performance and the overall performance is unlikely to be constant throughout the VTS area. The VTS system design should therefore ensure that the achievable performance is aligned with the required performance for each of the areas within the VTS coverage area. It should be noted that track formation range may not be the same as the sensors' detection range – this needs to be considered when deriving the coverage and how this relates to the tracker behaviour.

Test scenarios may be developed jointly with users and the tracking experts to explore the anticipated performance of the VTS system as a whole, especially in critical (hazardous) areas of the VTS. Note that generic test cases may not be sufficient to demonstrate performance in these areas.

The tracking characteristics needed are highly dependent on local conditions which should be analysed individually. The following tables discuss some of the tracker performance parameters and criteria that may be considered.

Requirements for sensor fault detection and loss of sensor data integrity should also be considered; for example, the tracker may be used to identify consistent bias errors in the data from one sensor.

The tracker should be able to provide advance warning of track capacity overload and possible other conditions that may affect reliability of the tracking.

The data held in a VTS system is often important when managing ship visits or transits through a VTS area. Often referred to as a "management information system" for ports or transits, this database supports a workflow for the planning, utilization and recording of the resources allocated to a ship's visit. When integrated with the VTS system, it should receive real-time updates of the progress and status of the ship visit. Typically, the database may include the following resources: Pilots, Tugs, Berths, Linesmen, waste facilities and other services that may be provided to safely and efficiently handle a ship during a visit or transit.

The database may provide information that enhances the VTS traffic image such as showing when a pilot is on board a ship. The database is often a critical source of validated data that may be used for generating statistical reports such as the utilization of resources during a configurable time period and for invoicing.

When specifying the requirements, the VTS provider should consider their specific workflow/process when managing a ship visit. This is workflow/process is often stated in the VTS provider's standard operating procedures, VTS user guideline, or the relevant safety management system.

The types of data typically include:

• Voyage
• Cargo
• Vessel
• Incident
• Contact details
• Pilots and tugs
• Berths
• Traffic analysis
• Local hazards

Additionally, the database may contain other data such as:

• VTS equipment data such as status, build state, version, faults, spares, maintenance
• Shore-based personnel (VTS users, Pilots, Tugs, Linesmen, etc) data, which may be subject to privacy considerations
• Level of service

It may be appropriate to integrate the database with the VTS provider's invoicing system to automate the collection of all chargeable services related to the ship's visit to facilitate account management by systems associated with the port finances (i.e., not directly associated with VTS operations).

The recording of real-time data and vessel activity as presented to VTS personnel is a critical component of the VTS system design so that a consistently accurate replay of events can be reproduced. These recordings serve multiple purposes, which can include but are not necessarily limited to quality assurance, procedural review, incident investigation, training, and as evidence in legal proceedings.

Recording of sensor data, voice communications, the traffic image, system status and other elements as required by the VTS provider should occur automatically. Replay of recordings should not interfere with ongoing VTS operation, nor require recording facilities to be paused while recordings are being retrieved, compiled or archived.

It is recommended that the VTS system recording capacity covers, at least, 30 days of activity. Requirements for archiving data to external media should be derived from:

• Operational procedures
• Appropriate storage devices considered for the type of data being stored
• Resolution and quality
• Legal security requirements necessary to keep the data secure and free from tampering
• Period of time the data is required to be kept.

Details about the Replay function are provided in section 2.3.10.

The purpose of this section is to support VTS providers in the specification of collaborative data exchange. Such data exchange between the VTS system and external systems may improve the operational efficiency of the VTS and external stakeholders.

This is emphasized in the IMO Resolution A.1158(32) which states that effective harmonized data exchange and information-sharing is fundamental to the overall operational efficiency and safety. Typical examples of information exchange may include VTS to VTS, VTS to Ship, Ship to VTS, VTS to Pilot Portable Units and VTS to stakeholder services.

Specific examples of information exchange are the sharing of sailing/route plans and en-route updates of vessel positions prior to reaching the VTS area of interest. Such information may be provided through third party service providers, LRIT, AIS/VDES Satellite Services, by direct VTS to VTS data exchange using IVEF or by VTS to ship using e-navigation maritime services.

VTS providers should refer to the following IALA references for the sharing of maritime data for:

• Legal issues and processes may be found in Guideline G1086
• IALA data model domains may be found in Guideline G1087
• Technical aspects may be found in Guideline G1130.

When producing the VTS system specification, the VTS provider is encouraged to consult the references and consider changes that may occur in the lifetime of the VTS system, which may typically be 10-years.

The IMO defines e-navigation as:

"the harmonized collection, integration, exchange, presentation and analysis of marine information on board and ashore by electronic means to enhance berth to berth navigation and related services for safety and security at sea and protection of the marine environment."

E-navigation is intended to meet present and future user needs of shipping through harmonization of marine navigation systems and supporting shore services such as VTS. It is expected to provide digital information and infrastructure for the benefit of maritime safety, security and protection of the marine environment, reducing the administrative burden and increasing the efficiency of maritime trade and transport.

IMO established Common Maritime Data Structure as a part of Strategy for development of e-navigation and selected IHO S-100 for the implementation. IHO S-100 is a framework geospatial standard for hydrographic and related data. S-100 is aligned with the ISO 19100 series of geographic standards, thereby making the use of hydrographic and other geographic data more interoperable than using the present IHO S-57 data transfer standard.

IALA was granted governance the S-200 domain, in co-operation with the IHO. A supervisory structure has been established (IALA Guideline G1087) that uses the range S-201 to S-299 for product specifications compliant with the IHO S-100 standard, covering fields within the IALA remit, including Marine Aids to Navigation (AtoN), Vessel Traffic Services (VTS), positioning systems and communication systems.

[Figure 1 Graphical display of S-100 Standard]

More information about the S-100 framework and the related S-200 domain can be found in

• IHO S-100; https://iho.int/en/s-100-universal-hydrographic-data-model
• IALA S-200; https://www.iala-aism.org/technical/data-modelling.

As specified in the IMO Resolution A.1158(32), VTS systems should share information as this is fundamental to overall operational efficiency and safety of the VTS. To be effective, data exchange and information sharing must be harmonized with international standards and implemented within a secure infrastructure.

Table 3 and Table 4 provide a list of purposes for maritime information exchange. This list is not exhaustive and simply provides an indication of the range and diversity of such maritime data.

Users should always be aware of the validity and completeness of the data to ensure that actions taken are based on timely, accurate and appropriate information.

Where a specific data service is being used, it is recommended that the parties involved in the data-sharing agreement should establish a service level agreement (SLA). The SLA should clearly define the responsibilities for quality and delivery of the data and define relevant key performance indicators (KPI).

It is recommended that data exchange performance is monitored in accordance with KPI as agreed in the SLA.

SLAs should clearly state requirements for provision, security and confidentiality and clearly define permitted use of all externally exchanged information.

Clear and realistic principles and rules regarding access should be established by the VTS provider. These principles and rules should recognise national and international legislation and guidance.

The reception and use of data, broadcast by radio, is subject to ITU-R: Radio Regulations [21] article 17 on Secrecy.

The VTS system should be installed and maintained within a secure network infrastructure in compliance with national (cyber security) regulations. Firewall protection of the system and encryption of data (where practical) should be considered in order to avoid the loss of sensitive information. Software that is critical for maintaining cyber security should be maintained at the most recent version. Regular penetration testing may be considered in order to identify cyber security risks and subsequent actions for risk mitigation.

In many cases legislation requires confidentiality of the data, but this is not universal throughout the maritime domain. Furthermore, the requirement to protect access to data may go beyond the limits of primary legislation. Measures should be taken to protect information to the required security level, e.g., data encryption, password protection, authentication and access privileges.

Authentication means that the sending and receiving parties can unambiguously identify each other.

Encryption may be used to ensure that data is only accessible to authorized parties. The level of encryption required depends on the sensitivity of the data.

Many national states, in the lawful exercise of their authority, place legal limits on the exchange and public dissemination of data and information. These include protections on intellectual and commercial property rights, and limitations on third party use of data and information.

In the course of exchanging maritime data and information in the interest of safety, security and efficiency, these limitations shall be respected, and the authorities involved should be aware of their rights and obligations under law. In particular, data exchange should comply with the laws of the national authority. Authorities need to be aware of any exposure to liability that might occur from their actions or inactions with regards to data and information exchange.

Further information is available in Guideline G1086.

Data integrity is the responsibility of the data provider. It is an important factor as e.g., key navigation decisions should be based upon timely, accurate and consistent data.

Timely data is data that is available when needed. This may be in advance of an event or in real-time, as appropriate. The VTS Provider should state when data, such as a notification of arrival, is required. It is the responsibility of the sender to ensure that enough time is allocated for the data to be communicated and received.

Real-time data should be time stamped as close as possible to the time of capture. Network latency should also be considered when exchanging time-critical data. Within IP networks, the concept of "quality of service" (QoS) may be used to prioritize the delivery of time-critical data. In such a case, it is important that QoS be implemented from source to destination, as data may travel through multiple IP networks.

Data often travels circuitous routes undergoing multiple handovers, from source to destination, allowing for corruption to occur either accidentally or through deliberate actions. Where required, appropriate measures should be taken to avoid such data corruption.

The transfer of data between sender and receiver requires connectivity via a network. A network comprises appropriate hardware and software interconnected by communication channels.

Different technical solutions and architectures can be used when establishing a data sharing network. Consideration should be given to the:

• services provided by the network;
• quality of services required by the users; and
• constraints on infrastructure.

The sharing of maritime data and information can take place either through the Internet or through dedicated private networks. The Internet is public, while dedicated networks are private. Consideration should be given to the security related characteristics of these network types.

When designing a network for sharing maritime data, consideration should be given to transmission protocols, bandwidth, volume, communication/data distribution strategy, security aspects such as authentication and confidentiality as well as data integrity. It is recommended that spare bandwidth is always included to enable additional services to be added at a future date.

Definitions for certain terms are provided after each section in the Guideline. The definitions of other terms used in this Guideline can be found in the International Dictionary of Marine Aids to Navigation (IALA Dictionary) and were checked as correct at the time of going to print. Where conflict arises, the IALA Dictionary should be considered as the authoritative source of definitions used in IALA documents.

Please refer to IALA G1111 Establishing Functional and Performance Requirements for VTS Systems for an extensive list of abbreviations and acronyms covering the entire G1111 series.

1. IMO. Convention on Safety of Life At Sea (SOLAS 1974) (as amended).
2. IMO. Resolution A.1158(32)- Guidelines for Vessel Traffic Services (2021).
3. IALA. Vessel Traffic Services Manual.
4. IALA. Recommendation R0128 VTS systems and Equipment.
5. IALA. Recommendation R0119 Establishment of VTS.
6. IALA. Recommendation R0140 Architecture for Shore-based Infrastructure 'fit for e-Navigation'.
7. IALA. Guideline G1128 The Specification of e-Navigation Technical Services.
8. IALA. Guideline G1110 Use of Decision Support Tools for VTS personnel.
9. IALA. Recommendation R0125 The Use and Presentation of Symbology at a VTS Centre.
10. IALA. Recommendation R1014 Portrayal of VTS Information and Data.
11. IALA Guideline G1105 Shore-side Portrayal ensuring Harmonization with e-Navigation related Information.
12. IALA. Guideline G1110 on the Use of Decision Support Tools for VTS personnel.
13. IMO. IAMSAR Manual.
14. IEEE Std. 686-2017 - IEEE Standard Radar Definitions.
15. IALA. Standard 1060 Digital Communication Technologies.
16. IALA. Standard 1070 Information Services.
17. IALA. Recommendation R0145 The Inter-VTS Exchange Format (IVEF) Service.
18. IALA. Guideline G1086 The Global Sharing of Maritime Data and Information.
19. IALA. Guideline G1087 Procedures for the Management of the IALA Domains Under the IHO GI Registry.
20. IALA. Guideline G1130 Technical Aspects of Information Exchange between VTS and Allied or Other Services.
21. ITU. (2020) Radio Regulations. Geneva