2007R0415 — EN — 17.08.2012 — 001.001

---

This document is meant purely as a documentation tool and the institutions do not assume any liability for its contents

►B

COMMISSION REGULATION (EC) No 415/2007 of 13 March 2007 concerning the technical specifications for vessel tracking and tracing systems referred to in Article 5 of Directive 2005/44/EC of the European Parliament and of the Council on harmonised river information services (RIS) on inland waterways in the Community (OJ L 105, 23.4.2007, p.35)

Amended by:

		Official Journal
		No	page	date
►M1	COMMISSION IMPLEMENTING REGULATION (EU) No 689/2012 of 27 July 2012	L 202	5	28.7.2012

---

▼B

COMMISSION REGULATION (EC) No 415/2007

of 13 March 2007

concerning the technical specifications for vessel tracking and tracing systems referred to in Article 5 of Directive 2005/44/EC of the European Parliament and of the Council on harmonised river information services (RIS) on inland waterways in the Community

Article 1

This Regulation defines the technical specifications for vessel tracking and tracing systems in inland waterway transport. The technical specifications are set out in the Annex to this Regulation.

Article 2

This Regulation shall enter into force on the day following its publication in the Official Journal of the European Union.

This Regulation shall be binding in its entirety and directly applicable in all Member States.

---

ANNEX

Vessel tracking and tracing systems — Inland AIS

CONTENTS
1.	The use of vessel tracking and tracing in inland navigation
1.1.	Introduction
1.2.	Scope
1.3.	Navigation
1.3.1.	Navigation, medium-term ahead
1.3.2.	Navigation, short-term ahead
1.3.3.	Navigation, very short-term ahead
1.4.	Vessel traffic management
1.4.1.	Vessel traffic services
1.4.1.1.	Information service
1.4.1.2.	Navigational assistance service
1.4.1.3.	Traffic organisation service
1.4.2.	Lock planning and operation
1.4.2.1.	Lock planning, long term
1.4.2.2.	Lock planning medium term
1.4.2.3.	Lock operation
1.4.3.	Bridge planning and operation
1.4.3.1.	Bridge planning medium term
1.4.3.2.	Bridge planning short term
1.4.3.3.	Bridge operation
1.5.	Calamity abatement
1.6.	Transport management
1.6.1.	Voyage planning
1.6.2.	Transport logistics
1.6.3.	Intermodal port and terminal management
1.6.4.	Cargo and fleet management
1.7.	Enforcement
1.8.	Waterway and port infrastructure charges
1.9.	Fairway information services
1.9.1.	Weather warnings (EMMA)
1.9.2.	Signal status
1.9.3.	Water level
1.10.	Conclusion
2.	Inland AIS technical specification
2.1.	Introduction
2.2.	Scope
2.3.	Functional requirements
2.3.1.	General requirements for Inland AIS
2.3.2.	Information content
2.3.2.1.	Static ship information
2.3.2.2.	Dynamic ship information
2.3.2.3.	Voyage related ship information
2.3.2.4.	Traffic management information
2.3.3.	Reporting interval of information transmission
2.3.4.	Technology platform
2.3.5.	Compatibility to IMO Class A transponders
2.3.6.	Unique identifier
2.3.7.	Application identifier for Inland AIS application specific messages
2.3.8.	Application requirements
▼M1
2.3.9.	Type approval
▼B
2.4.	Protocol amendments for Inland AIS
2.4.1.	Message 1, 2, 3: position reports (ITU-R 1371)
2.4.2.	Message 5: ship static and voyage related data (ITU-R 1371)
2.4.3.	Message 23, group assignment command (ITU-R M.1371)
2.4.4.	Application of specific messages (ITU-R 1371)
2.4.4.1.	Allocation of function identifiers (FI) within the Inland AIS branch
2.4.4.2.	Definition of inland specific messages
Appendix A:	Definitions
Appendix B:	EMMA codes
Appendix C:	Example of signal status
Appendix D:	Proposed digital interface sentences for Inland AIS
Appendix E:	ERI ship types
Appendix F:	Overview of information required by the user and the data fields, which are available in the defined Inland AIS messages.

REFERENCES

The content of this document is based on:

ABBREVIATIONS

1.   The use of vessel tracking and tracing in inland navigation

1.1.   Introduction

In maritime navigation, IMO has introduced the automatic identification system (AIS). All seagoing vessels on international voyage falling under SOLAS convention Chapter 5 have to be equipped with AIS since the end of 2004. The guidelines for the planning, implementation and operational use of River Information Services define Inland-AIS as an important technology. Because of mixed traffic areas it is important that the standards, technical specifications and procedures for inland shipping are compatible with already defined standards, technical specifications and procedures for seagoing navigation.

To serve the specific requirements of inland navigation, AIS has been further developed to the so called Inland AIS technical specification while preserving full compatibility with IMO's maritime AIS and already existing standards in inland navigation.

In this document chapter 1 describes the functional specifications related to vessel tracking and tracing in inland navigation. In chapter 2 the inland AIS technical specification is described, including the standard inland tracking and tracing messages. An overview of definitions of services and players is given in Appendix A: Definitions.

The purpose of the introduction chapter is to define all necessary functional requirements related to vessel tracking and tracing in inland navigation.

An overview of fields of interest and users is provided and particularly the information needs for each field of interest are described. The functional specifications are based on rules and regulations for navigation, based on discussions with experts and based on existing experiences.

Three groups of information are distinguished:

For each group of information different ways of information exchange can be identified:

In the paragraphs below that information is described in detail which can be exchanged by vessel tracking and tracing systems between ships and between ships and shore. The information needs are described relating to tracking and tracing. However, for most of the tasks additional information like geographical information, detailed cargo information, address information is required. This kind of information will be provided by other systems.

1.2.   Scope

The table below gives an overview of the fields of interest dealt with in this document. Each field of interest is split up into tasks and for each task the users are defined.

In the following paragraphs for each field of interest and tasks the users and the information needs are described in detail.

Note: the order of the information needs within each task does not imply different importance of the information. The accuracy of the information needs is summarised in a table in the last paragraph.

1.3.   Navigation

Vessel tracking and tracing can be used to support the active navigation on board.

The process navigation can be split up in three phases:

For each phase the user requirements are different.

1.3.1.   Navigation, medium term ahead

Navigation a medium term ahead is the navigation phase in which the skipper observes and analyses the traffic situation looking some minutes up to an hour ahead and considers the possibilities of where to meet, pass or overhaul other vessels.

The traffic image needed is the typical ‘looking around the corner’ feature and is mainly outside the scope of the on board radar range.

Exchanged traffic information consist of:

The update rate is depending on the task and differs from the situation in which the ship is involved. (The maximum update rate is two seconds.)

1.3.2.   Navigation, short-term ahead

Navigation a short-term ahead is the decision phase in the navigation process. In this phase traffic information has relevance for the process of navigation, including collision avoidance measures if necessary. This function deals with the observation of other vessels in the close surroundings of the vessel. Exchanged traffic information consists of:

The actual traffic information on position, identification, name, direction, speed over ground, course, heading and intention (blue sign) will be exchanged continuously at least every 10 seconds. For some routes the Authorities will set a predefined update rate (maximum two seconds).

1.3.3.   Navigation, very short term ahead

Navigation a very short term ahead is the operational navigation process. It consists of execution of the decisions that were made beforehand, on the spot and monitoring its effects. The traffic information needed from other vessels especially in this situation is related to its own vessel conditions, such as relative position, relative speed, etc. In this phase following highly accurate information is needed:

Based on the abovementioned requirements it became clear that from today's point of view very short term navigation can not make use of tracking and tracing information.

1.4.   Vessel traffic management

Vessel traffic management comprises at least of the below defined elements:

1.4.1.   Vessel traffic services

Within vessel traffic services different services can be distinguished:

In the next paragraphs the user needs related to traffic information are described.

1.4.1.1.    Information service

An information service is provided by broadcasting information at fixed times and intervals or when deemed necessary by the VTS or at the request of a vessel, and may include for example reports on the position, identity and intentions of other traffic; waterway conditions; weather; hazards; or any other factors that may influence the vessel's transit.

For the information services an overview of traffic in a network or on fairway stretch is needed. The traffic information will comprise vessel information like:

The competent authority will set the predefined update rate.

1.4.1.2.    Navigational assistance service

A navigational assistance service informs the master on difficult navigational or meteorological circumstances or assists him in case of defects or deficiencies. This service is normally rendered at the request of a vessel or by the VTS when deemed necessary.

To provide individual information to a skipper, the VTS operator needs an actual detailed traffic image.

The contribution of vessel tracking and tracing is:

Any other information needed is environmental, geographic information and Notices to Skippers.

The actual traffic information on identification, position, direction, speed, course and intention (blue sign) has to be exchanged continuously (every three seconds, almost real time or another predefined update rate set by the competent authority).

All other information had to be available on request of the VTS operator or in special occasions (on event).

1.4.1.3.    Traffic organisation service

A traffic organisation service concerns the operational management of traffic and the forward planning of vessel movements to prevent congestion and dangerous situations, and is particularly relevant in times of high traffic density or when the movement of special transports may affect the flow of other traffic. The service may also include establishing and operating a system of traffic clearances or VTS sailing plans or both in relation to priority of movements, allocation of space, mandatory reporting of movements in the VTS area, routes to be followed, speed limits to be observed or other appropriate measures which are considered necessary by the VTS authority. The requirements on the traffic image for the traffic organisation service are the same as described in paragraph 1.4.1.2 Navigational assistance service.

1.4.2.   Lock planning and operation

In the next paragraphs the lock planning processes — long- and medium-term — and lock operation process are described.

1.4.2.1.    Lock planning, long-term

Lock planning a long-term ahead is dealing with the planning of a lock some hours up to a day ahead.

In this case the traffic information is used to improve the information on waiting and passing times at locks, which are originally based on statistical information.

Traffic information needed for long term lock planning is:

ETA should be available on demand or should be exchanged when a by the competent authority predefined deviation of the originally ETA is exceeded. RTA is the response on an ETA report.

1.4.2.2.    Lock planning medium-term

Lock planning a medium-term ahead is dealing with the planning of a lock up to two or four lock cycles ahead.

In this case the traffic information is used to map the arriving vessels to the available lock cycles and based on the planning to inform the skippers about the RTA (requested time of arrival).

Traffic information needed for medium term lock planning is

ETA should be available on request or should be exchanged when a by the Competent Authority predefined deviation of the originally ETA is exceeded. All other information shall be available once at the first contact or on request. RTA is the response on an ETA report.

1.4.2.3.    Lock operation

In this phase the actual locking process take place.

To facilitate the lock operational process the following traffic information is required:

The actual traffic information on identification, position, direction, speed and course has to be exchanged continuously or by the competent authority set predefined update rate.

1.4.3.   Bridge planning and operation

In the next paragraphs the bridge planning processes — medium- and short-term — and bridge operation process are described.

1.4.3.1.    Bridge planning medium term

The bridge planning process on a medium-term is dealing with the optimisation of the traffic flow in such a way that the bridges are opened in time for passing of vessels (green wave). The time looking ahead varies between 15 minutes to two hours. The timeframe will depend on the local situation.

Traffic information needed for medium term bridge planning is:

ETA and position shall be available on request or shall be exchanged as a by the competent authority predefined deviation of the originally ETA is exceeded. All other information shall be available once at the first contact or on request. RTA is the response on an ETA report.

1.4.3.2.    Bridge planning short term

In case of bridge planning process on a short-term decisions are made on the strategy for opening of the bridge.

Traffic information needed for short term bridge planning is:

Actual traffic information on the position, speed and direction, shall be available on request or by the competent authority set predefined update rate, e.g. every five minutes. ETA and position shall be available on request or shall be exchanged as a by the Competent Authority predefined deviation of the originally ETA is exceeded. All other information shall be available once at the first contact or on request. RTA is the response on an ETA report.

1.4.3.3.    Bridge operation

In this phase the actual opening and passing of the vessel through the bridge take place. To facilitate this process the following traffic information is required:

The actual traffic information on identification, position, direction, speed and course has to be exchanged continuously or by the competent authority set predefined update rate.

1.5.   Calamity abatement

Calamity abatement in this context focuses on repressive measures: dealing with real accidents and providing assistance during emergencies. To facilitate this process the following traffic information is required:

In the case of an accident the traffic information can be provided automatically or the calamity fighter will ask for the information.

1.6.   Transport management

This service is divided into four activities:

1.6.1.   Voyage planning

Voyage planning in this context focuses on the planning on-trip. During the voyage the skipper will check his original planned voyage.

For this process the following traffic information is needed:

The traffic information is needed on request or on in case of a special event like a relevant change in ETA or RTA.

1.6.2.   Transport logistics

Transport logistics consist of the organisation, planning, execution and control of the transport.

For these processes the following traffic information is needed:

All traffic information is needed on request of the shipowner or logistic players.

1.6.3.   Intermodal port and terminal management

Intermodal port and terminal management considers the planning of resources in ports and at terminals.

The traffic information needed for this these processes is described below:

The terminal and port manager will request for traffic information or will agree that in predefined situations the traffic information will be send automatically.

1.6.4.   Cargo and fleet management

Cargo and fleet management considers the planning and optimising the use of vessels, arranging cargo and transportation.

The traffic information needed for this these processes is described below:

The shipper or shipowner will ask for the traffic information or the traffic information will be send in predefined situations.

1.7.   Enforcement

The scope of the enforcement task described below is limited to the services on dangerous goods, immigration control and customs.

The contribution of vessel tracking and tracing for these processes is:

The traffic information will be exchanged to appropriate authorities. The traffic information exchange will take place on request or at fixed predefined points or at special described circumstances defined by the responsible authority.

1.8.   Waterway and port infrastructure charges

At different locations in Europe one has to pay for the use of the waterway and ports.

The traffic information needed for these processes is described below:

The traffic information will be exchanged on request or at fixed points, defined by the responsible waterway or port authority.

1.9.   Fairway information services

Related to fairway information services three services are described:

In the next paragraphs, the provided information is described.

1.9.1.   Weather warnings (EMMA)

The European ongoing project ‘EMMA’ (European multiservice meteorological awareness system) is dealing with standardisation of weather warnings. Standardised symbols for meteorological warnings have been developed within the EMMA project and can be used for the display of messages on the Inland ECDIS screen.

EMMA is not going to provide continuous weather information, but only warnings in case of special meteorological situations. The warnings are provided for regions.

Only km/h (wind), oC (temperature), cm/h (snow), l/m2h (rain) and m (distance to be seen by fog) may be used for weather warnings.

The following information is needed:

This information is only exchanged in special events, in case of extreme weather conditions.

1.9.2.   Signal status

Vessel tracking and tracing systems can be used for the transmission of status of traffic signals in inland navigation. The information to be exchanged consists of:

Examples of signals are given in Appendix C.

The distribution of the information has to be restricted to a specific area.

1.9.3.   Water level

Vessel tracking and tracing systems can be used for the transmission of (actual) water level information:

The information to be exchanged consists of:

The information will regularly be sent or sent on request.

1.10.   Conclusion

The functional specifications described the user needs and the data needs for each field of interest. Tracking and tracing systems will exchange particularly the dynamic information.

In table 1.2 an overview is given of the accuracy requirements of the dynamic information related to the tasks described in this chapter.

2.   INLAND AIS TECHNICAL SPECIFICATION

2.1.   Introduction

In maritime navigation, IMO has introduced the automatic identification system (AIS). All seagoing ships on international voyage falling under SOLAS convention Chapter 5 have to be equipped with AIS since the end of 2004.

The European Parliament and the Council have adopted Directive 2002/59/EC ( 2 ) establishing a community vessel traffic monitoring and information system for seagoing vessels carrying dangerous or polluting goods using AIS for Ship Reporting and Monitoring.

AIS technology is considered as a suitable way that can also be used for automatic identification and vessel tracking and tracing in inland navigation. Especially the real time performance of AIS and the availability of worldwide standards and guidelines are beneficial for safety related applications.

To serve the specific requirements of inland navigation, AIS has to be further developed to the so-called Inland AIS technical specification while preserving full compatibility with IMO's maritime AIS and already existing standards and technical specifications in inland navigation.

Because Inland AIS is compatible to the IMO SOLAS AIS it enables a direct data exchange between seagoing and inland vessels navigating in mixed traffic areas.

Using AIS for automatic identification and vessel tracking and tracing in inland navigation provides the following features:

AIS is:

The purpose of this document is to define all necessary functional requirements, amendments and extensions to the existing maritime AIS in order to create an Inland AIS for use in inland navigation.

2.2.   Scope

The AIS is a ship-borne radio data system, exchanging static, dynamic and voyage related vessel data between equipped vessels and between equipped vessels and shore stations. Ship-borne AIS stations broadcast the vessel's identity, position and other data in regular intervals. By receiving these transmissions, ship-borne or shore-based AIS stations within the radio range can automatically locate, identify and track AIS equipped vessels on an appropriate display like radar or Inland ECDIS. AIS systems are intended to enhance safety of navigation in ship-to-ship use, surveillance (VTS), vessel tracking and tracing, and calamity abatement support.

Several types of AIS stations can be distinguished:

The following modes of operation can be distinguished:

A characteristic of AIS is the autonomous mode, using SOTDMA without any need for an organising master station. The radio protocol is designed in a way that vessel stations operate autonomously in a self-organised manner by exchanging link access parameters. Time is divided into one minute frames with 2 250 time slots per radio channel which are synchronised by GNSS UTC time. Each participant organises its access to the radio channel by choosing free time slots considering the future use of time slots by other stations. There is no need for a central intelligence controlling the slot assignment.

An Inland AIS station consists in general of the following components:

Universal ship-borne AIS, as defined by IMO, ITU and IEC, and recommended for the use in inland navigation uses self-organised time division multiple access (SOTDMA) in the VHF maritime mobile band. AIS operates on the internationally designated VHF frequencies AIS 1 (161,975 MHz) and AIS 2 (162,025 MHz), and can be switched to other frequencies in the VHF maritime mobile band.

To serve the specific requirements of inland navigation, AIS has to be further developed to the so called Inland AIS while preserving compatibility with IMO's maritime AIS.

Vessel tracking and tracing systems in inland navigation shall be compatible with maritime AIS, as defined by IMO. Therefore, AIS messages shall contain:

▼M1

For moving vessels an update rate for the dynamic information on tactical level can be switched between SOLAS mode and inland waterway mode. In inland waterway mode it can be increased up to 2 seconds. For vessels at anchor it is recommended to have an update rate of several minutes, or if information is amended.

▼B

AIS is an additional source for navigational information. AIS does not replace, but supports navigational services such as radar target tracking and VTS. AIS has its strength as a means of surveillance and tracking of vessels equipped with it. Due to their different characteristics, AIS and radar complement each other.

2.3.   Functional requirements

2.3.1.   General requirements for Inland AIS

Inland AIS is based on the maritime AIS according to IMO SOLAS regulation.

Inland AIS shall cover the main functionality of IMO SOLAS AIS while considering the specific requirements for inland navigation.

Inland AIS shall be compatible to the IMO SOLAS AIS and shall enable a direct data exchange between seagoing and inland vessels navigating in a mixed traffic area.

The following requirements are complementary or additional requirements for Inland AIS, which differs from the IMO SOLAS AIS.

▼M1

The Inland AIS design shall take into account the technical guidelines on Inland AIS as prepared and maintained by the expert group on vessel tracking and tracing ( 3 ).

▼B

2.3.2.   Information content

Generally only tracking and tracing and safety related information shall be transmitted via Inland AIS. Taking into consideration this requirement, Inland AIS messages shall contain following information:

Items marked with ‘*’ have to be handled differently as for seagoing ships.

2.3.2.1.    Static ship information

The static ship information for inland vessels shall have the same parameters and the same structure as in IMO AIS as far as it is applicable. Not used parameter fields shall be set to ‘not available’.

Inland specific static ship information shall be added.

Static ship information is broadcast autonomously from ship or on request.

2.3.2.2.    Dynamic ship information

The dynamic ship information for inland vessels shall have the same parameters and the same structure as in IMO AIS as far as it is applicable. Not used parameter fields shall be set to ‘not available’.

Inland specific dynamic ship information shall be added.

Dynamic ship information is broadcasted autonomously from ship or on request.

2.3.2.3.    Voyage related ship information

The voyage related ship information for inland vessels shall have the same parameters and the same structure than in IMO AIS as far as it is applicable. Unused parameter fields shall be set to ‘not available’.

Inland specific voyage related ship information shall be added.

Voyage related ship information is broadcasted autonomously from ship or on request.

2.3.2.4.    Traffic management information

Traffic management information is for specific use in inland navigation. This information is transmitted when required or on request to/from inland vessels only.

ETA at lock/bridge/terminal information is transmitted as addressed message from ship to shore.

RTA at lock/bridge/terminal information is transmitted as addressed message from shore to ship.

The number of persons on board is transmitted preferably as an addressed message from ship to shore on request or on event.

Signal status information is transmitted as broadcast message from shore to ship

EMMA warning information is transmitted as broadcast message from shore to ship

Water Level Information is transmitted as broadcast message from shore to ship

Safety related messages are transmitted when required as broadcast or as addressed messages.

2.3.3.    Reporting interval of information transmission

The different information types of Inland AIS shall be transmitted with different reporting rates.

▼M1

For moving vessels in inland waterway areas the reporting rate for the dynamic information can be switched between SOLAS mode and inland waterway mode. In inland waterway mode it can be increased up to 2 seconds. In mixed traffic areas like seaports it shall be possible to decrease the reporting rate for dynamic information by the competent authority to ensure a balance in reporting behaviour between inland vessels and SOLAS vessels. The reporting behaviour shall be switchable by TDMA commands from a base station (automatic switching by TDMA telecommand via message 23) and by commands from ship borne systems, e.g. MKD, ECDIS or on board computer, via interface, e.g. IEC 61162 (automatic switching by ship borne system command). For static and voyage related information it is recommended to have a reporting rate of several minutes, on request, or if information is amended.

▼B

Following reporting rates are applicable:

▼M1

Note: An Inland AIS mobile station operates either in inland waterway mode (group assignment by message 23) or in SOLAS mode (autonomous mode, no group assignment active).

▼B

2.3.4.   Technology platform

▼M1

The technical solution of Inland AIS is based on the same technical standards as IMO SOLAS AIS (Rec. ITU-R M.1371, IEC 61993).

▼B

The use of Class A mobile station derivates or Class B ‘SO’ mobile station derivates using SOTDMA techniques are recommended as platform for Inland AIS. The use of the Class B ‘CS’ using CSTDMA techniques is not possible, because it does not guarantee the same performance as the Class A or Class B ‘SO’ equipment. Neither can the successful transmission to radio link be granted nor does it provide the capability to send the Inland AIS specific messages defined in this technical specification.

As long as no Class B ‘SO’ devices are available, Inland AIS Mobile equipment is a derivative of the maritime AIS Class A mobile equipment according IMO SOLAS regulation.

▼M1

2.3.5.    Compatibility to IMO Class A transponders

Inland AIS transponders must be compliant to IMO Class A transponders and must therefore be capable of receiving and processing all IMO AIS messages (according to ITU-R M.1371 and IALA technical clarifications on ITU-R M.1371) and in addition the messages defined in Chapter 2.4 of these technical specifications.

The DSC transmitting (tx) capability and the provision of an MKD are not required for Inland AIS transponders, but the MKD functionality as well as the DSC channel management functionality are required. The manufacturers may remove the respective hard- and software from the Class A transponders.

▼B

2.3.6.   Unique identifier

In order to guarantee the compatibility to maritime vessels, the Maritime Mobile Service Identifier (MMSI) number must be used as a unique station identifier (radio equipment identifier) for the Inland AIS transponders.

2.3.7.   Application identifier for Inland AIS application specific messages

To serve the information requirement for inland navigation application specific messages are used.

The application specific messages consist of the Standard AIS framework (message ID, repeat indicator, source ID, destination ID), the Application Identifier (AI = DAC + FI) and the data content (variable length up to a given maximum).

The 16-bit application identifier (AI = DAC + FI) consists of

For Inland AIS application specific messages the DAC ‘200’ is used.

2.3.8.   Application requirements

It is necessary to input and display Inland AIS messages (binary coded). This shall be handled by an application (preferably with a GUI capable of interfacing the AIS transponder) at the Presentation Interface (PI), or in the transponder itself. Possible data conversions (e.g. knots into km/h) or information concerning all ERI codes (location, ship type) shall be handled there.

Furthermore the transponder or the relevant application shall be capable of storing also the inland specific static data in the internal memory, in order to keep the information when the unit is without power supply.

In order to program the inland specific data into the transponder the input sentences listed in Appendix D: Proposed digital interface sentences for Inland AIS are proposed.

The Inland AIS equipment shall provide as a minimum an external RTCM SC 104 interface for the input of DGNSS correction and integrity information.

▼M1

2.3.9.    Type-approval

Inland AIS equipment shall be type-approved for compliance with these technical specifications.

▼B

2.4.   Protocol amendments for Inland AIS

▼M1

2.4.1.    Message 1, 2, 3: position reports (ITU-R 1371)

▼B

▼M1

2.4.2.    Message 5: ship static and voyage related data (ITU-R 1371)

▼B

▼M1

2.4.3.    Message 23, group assignment command (ITU-R M.1371)

▼M1

The Group Assignment Command is transmitted by a base station when operating as a controlling entity. The message shall be applied to a mobile station within the defined region and as selected by ‘Ship and Cargo Type’ or by ‘Station Type’. The receiving station shall consider all sector fields concurrently. It shall control the following operating parameters of a mobile station: transmit/receive mode; reporting interval; and the duration of a quiet time.

▼B

▼M1

Note: When the dual channel transmission is suspended by Tx/Rx mode command 1 or 2, the required reporting interval shall be maintained using the remaining transmission channel.

2.4.4.    Application of specific messages (ITU-R 1371)

▼B

For the necessary data exchange in inland navigation Inland AIS application specific messages are defined.

The regional application identifiers (RAI) of the Inland AIS application specific messages consist of the DAC ‘200’ a function identifier (FI) as defined in this section.

2.4.4.1.    Allocation of function identifiers (FI) within the Inland AIS branch

►M1  The FIs within the Inland AIS branch shall be allocated and used as described in ITU-R M.1371. ◄ Every FI within the Inland branch shall be allocated to one of the following groups of application fields:

Some FI within the inland branch shall be reserved for future use.

2.4.4.2.    Definition of inland specific messages

This message shall be used by inland vessels only, to broadcast ship static and voyage related data in addition to message 5. The message shall be sent with binary message 8 as soon as possible (from the AIS point of view) after message 5.

The details regarding the ERI ship type coding can be found in Appendix E.

This message shall be used by inland vessels only, to send an ETA report to a lock, bridge or terminal in order to apply for a time slot in resource planning. The message shall be sent with binary message 6.

An acknowledgement by inland branch function message 22 shall be received within 15 minutes. Otherwise the Inland branch function message 21 shall be repeated once.

This message shall be sent by base stations only, to assign a RTA at a lock, bridge or terminal to a certain vessel. The message shall be sent with binary message 6 as reply on inland branch function message 21.

This message shall be sent by inland vessels only, to inform about the number of persons (passengers, crew, shipboard personnel) on board. The message shall be sent with binary message 6 preferably on event or on request using IAI binary functional message 2.

Alternatively the Standard IMO binary message ‘number of persons on board’ (IAI number 16) could be used.

The EMMA warning shall be used to warn shippers using graphical symbols on the ECDIS screen of heavy weather conditions. The following message is capable of transmitting the EMMA data using the AIS channel. It will not replace the Notices to Skippers warnings. This message shall be sent by base stations only, to give weather warnings to all vessels in a certain area. The message shall be sent with binary message 8 on demand.

This message shall be used to inform skippers about actual water levels in their area. It is additional short term information to the water levels distributed via Notices to Skippers. The update rate shall be defined by the competent authority. It is possible to transmit the water levels of more than four gauges using multiple messages.

This message shall be sent by base stations only, to give water level information to all vessels in a certain area. The message shall be sent with binary message 8 at regular intervals.

This message shall be sent by base stations only, to inform about the status of different light signals to all vessels in a certain area. The information shall be displayed on an external Inland ECDIS display as dynamic symbols. The message shall be sent with binary message 8 at regular intervals.

An example of signal status is given in APPENDIX C: Example of Signal Status

---

Appendix A

DEFINITIONS

A.1   Services

▼M1

River Information Services (RIS)

A European concept for harmonised information services to support traffic and transport management in inland navigation, including the interfaces to other transport modes.

▼B

Vessel traffic management

Vessel traffic management is providing information orally as well as electronically as well as giving directions in interaction with and response to vessels in a traffic flow to optimise the smooth (efficient) and safe transport.

Vessel traffic management shall comprise at least one of the below defined elements:

Vessel traffic services (VTS)

Vessel traffic service is a service implemented by a competent authority, designed to improve the safety and efficiency of vessel traffic and to protect the environment.

The service shall have the capability to interact with the traffic and to respond to traffic situations developing in the area.

VTS services — VTS shall comprise at least an information service and may also include others, such as a navigational assistance service, or a traffic organisation service, or both, defined as below:

(Source: IALA VTS guidelines)

▼M1

VTS area

VTS area is the delineated, formally declared service area of a VTS. A VTS area may be subdivided in sub-areas or sectors. (Source: IALA VTS guidelines).

Navigational information

Navigational information is information provided to the skipper on board to support in on-board decision-making. (Source: IALA VTS guidelines).

Tactical traffic information (TTI)

Tactical traffic information is the information affecting the skipper’s or the VTS operator’s immediate decisions with respect to navigation in the actual traffic situation and the close geographic surroundings. A tactical traffic image contains position information and specific vessel information of all targets detected by a radar presented on an electronic navigational chart and — if available — enhanced by external traffic information, such as the information delivered by an AIS. TTI may be provided on board of a vessel or on shore, e.g. in a VTS Centre. (Source: RIS guidelines).

Strategic traffic information (STI)

Strategic traffic information is the information affecting the medium and long-term decisions of RIS users. A strategic traffic image contributes to the planning decision capabilities regarding a safe and efficient voyage. A strategic traffic image is produced in a RIS centre and delivered to the users on demand. A strategic traffic image contains all relevant vessels in the RIS area with their characteristics, cargoes and positions, reported by VHF voice reporting or electronic ship reporting, stored in a database and presented in a table or on an electronic map. Strategic Traffic Information may be provided by a RIS/VTS centre or by an office. (Source: RIS guidelines).

▼B

(Vessel) tracking and tracing

▼M1

Vessel traffic monitoring

Vessel traffic monitoring is providing important information relating to the movements of relevant ships in a RIS area. This includes information about ships identity, position, (type of cargo) and port of destination.

▼B

Logistics

The planning, execution and control of the movement and placement of people and/or goods and the supporting activities related to such movement and placement within a system organised to achieve specific objectives. (Source: COMPRIS WP8 Standardisation)

A.2   Players

Shipmaster

The person responsible for the overall safety of the vessel, cargo, passengers and crew and thereby for the voyage plan of the vessel and the condition of the vessel, the cargo, respectively passengers and the quality and quantity of the crew.

Conning skipper

The person who navigates the vessel according to voyage plan instructions of the shipmaster. (Source: COMPRIS WP2, Architecture)

VTS operator

A person, appropriately qualified by the competent authority, performing one or more tasks contributing to the services of the VTS (Source: IALA VTS guidelines for inland waters).

The person who monitors and controls the fluent and safe progress of traffic within the area around the VTS centre. (Source: COMPRIS WP2, Architecture)

Competent authority

The competent authority is the authority made responsible for safety, in whole or in part, by the government, including environmental friendliness and efficiency of vessel traffic. The competent authority usually has the tasks of planning, arranging funding and of commissioning of RIS. (Source: RIS guidelines)

RIS authority

The RIS authority is the authority with the responsibility for the management, operation and coordination of the RIS, the interaction with participating vessels and safe and effective provision of the service. (Source: RIS guidelines)

▼M1

RIS operator

A person performing one or more tasks contributing to the services of RIS.

▼B

Lock operator

The person who monitors and controls the fluent and safe progress of traffic around and through a lock and who is responsible for the locking process in itself. (Source: COMPRIS WP2, Architecture)

Bridge operator

The person who monitors and controls the fluent and safe progress of traffic around a moveable bridge and who is responsible for the operation of a movable bridge. (Source: COMPRIS WP2, Architecture)

Terminal operator (synonym: stevedore)

A party responsible for the execution of loading, stowing and discharging (unloading) of vessels. (Source: COMPRIS WP8 Standardisation)

▼M1

Fleet manager

A person planning and observing the actual (navigational) status of a number of vessels moving or working under one command or ownership.

Operator in calamity centres of emergency services

The person who monitors, controls and organises the safe and smooth fighting of accidents, incidents and calamities.

▼B

Consignor (synonym: cargo shipper or sender)

The merchant (person) by whom, in whose name or on whose behalf a contract of carriage of goods has been concluded with a carrier or any party by whom, in whose name or on whose behalf the goods are actually delivered to the carrier in relation to the contract of carriage. (Source: COMPRIS WP8 Standardisation)

Consignee

The party such as mentioned in the transport document by whom goods, cargo or containers are to be received. (Source: Transport and logistics glossary (P&O Nedlloyd) and COMPRIS WP8 Standardisation)

Freight broker (Synonym: freight forwarder)

The person responsible on behalf of the transport supplier for the physical transport of the goods to be executed. The freight broker offers transport capacity to shippers on behalf of the transport supplier and is this way mediator between supply forwarder and shipmaster. (Source: COMPRIS WP2, Architecture)

Supply forwarder

The person who is responsible on behalf of the shipper for the organisation of the physical transport of the goods that shall be exchanged. The supply forwarder offers cargo to transporters on behalf of the shipper. (Source: COMPRIS WP2, Architecture)

Customs

The department of the Civil Service that deals with the levying of duties and taxes on imported goods from foreign countries and the control over the export and import of goods, e.g. allowed quota prohibited goods. (Source: Transport and logistics glossary (P&O Nedlloyd),

---

Appendix B

EMMA CODES

---

Appendix C

Example of signal status

C.1   Light status

The examples show a grey background in a square of a fixed size of about 3 mm x 3 mm at all display scales with a ‘post’ like it is used for the present static signal in the presentation library. The white point in the centre of the post indicates the position and the post itself allows the user to read the direction of impact. (At a lock, for example, there are often signals for vessels leaving the lock chamber and vessels entering the lock chamber on the inner and the outer side of the door construction) However, the manufacturer of the display software can design the shape of the symbol and the background colour.

The status of a signal can be ‘No light’, ‘white’, ‘yellow’, ‘green’, ‘red’, ‘white flashing’ and ‘yellow flashing’ according to CEVNI.

C.2   Signal forms

For each of these signals there are a lot of possible combinations of lights. It is required to use:

a number to indicate the kind of signal, and

a number for each light on a signal to indicate its status:

1 =

no light,

2 =

white,

3 =

yellow,

4 =

green,

5 =

red,

6 =	white flashing, and

7 =	yellow flashing.

---

Appendix D

PROPOSED DIGITAL INTERFACE SENTENCES FOR INLAND AIS

▼M1

D.1    Input sentences

The serial digital interface of the AIS is supported by existing IEC 61162 sentences and new IEC 61162 like sentences. The detailed descriptions for the digital interface sentences are found in IEC 61162.

This appendix contains information used during the development of Inland AIS in order to input the inland specific data (see protocol amendments for Inland AIS) into the Inland AIS shipboard unit.

▼B

D.2   Inland waterway static ship data

This sentence is used to enter inland navigation static ship data into an Inland AIS unit. For setting the inland static ship data the sentence $PIWWSSD with the following content is ►M1  used ◄ :

Note 1

ERI ship type according to ERI classification (see Appendix E)

Note 2

length of ship 0 to 800,0 metres

Note 3

beam of ship 0 to 100,0 metres

Note 4

quality of speed information 1=high or 0=low

Note 5

quality of course information 1=high or 0=low

Note 6

quality of heading information 1=high or 0=low

D.3   Inland waterway voyage data

This sentence is used to enter inland navigation voyage ship data into a Inland AIS unit. For setting the inland voyage related data the sentence $PIWWIVD with the following content is ►M1  used ◄ :

Note 1

See Table 2.5 Reporting rate settings, default setting: 0

Note 2

number of blue cones: 0-3, 4=B-Flag, 5=default=unknown

Note 3

0=not available=default, 1=loaded, 2=unloaded, rest not used

Note 4

static draught of ship 0 to 20,00 metres, 0=unknown=default, rest not used

Note 5

air draught of ship 0 to 40,00 metres, 0=unknown=default, rest not used

Note 6

number of assisting tugboat 0-6, 7=default=unknown, rest not used

Note 7

number of crew members on board 0 to 254, 255=unknown=default, rest not used

Note 8

number of passengers on board 0 to 8 190, 8 191=unknown=default, rest not used

Note 9

number of shipboard personnel on board 0 to 254, 255=unknown=default, rest not used

Remark: The former proposed input sentence $PIWWVSD, used in Inland AIS units developed prior this standard, contains the parameter field ‘blue sign’ which may raise conflicts with the parameter field ‘regional application flags’ in the $—VSD sentence according IEC 61162-1:VSD-AIS Voyage static data.

It shall no longer be implemented in new AIS transponders. However, for compatibility reasons, it shall be supported by external applications.

Note 1

0=not available=default=factory settings, 1=SOLAS settings, 2=Inland Waterway settings (2 sec), rest not used

Note 2

0=not available=default, 1=not set, 2=set, rest not used

Note 3

number of blue cones: 0-3, 4=B-Flag, 5=default=unknown

Note 4

0=not available=default, 1=loaded, 2=unloaded, rest not used

Note 5

static draught of ship 0 to 20,00 metres, 0=unknown=default, rest not used

Note 6

air draught of ship 0 to 40,00 metres, 0=unknown=default, rest not used

Note 7

number of assisting tugboat 0-6, 7=default=unknown, rest not used

Note 8

number of crew members on board 0 to 254, 255=unknown=default, rest not used

Note 9

number of passengers on board 0 to 8 190, 8 191=unknown=default, rest not used

Note 10

number of shipboard personnel on board 0 to 254, 255=unknown=default, rest not used

▼M1

---

Appendix E

ERI SHIP TYPES

This table shall be used to convert the UN ship types, which are used in Inland message 10 to the IMO types which are used in IMO message 5.

▼B

---

Appendix F

Overview of information required by the user and the data fields, which are available in the defined Inland AIS messages

---

( 1 ) OJ L 255, 30.9.2005, p. 152.

( 2 ) Directive 2002/59/EC of the European Parliament and of the Council of 27 June 2002 establishing a Community vessel traffic monitoring and information system repealing Council Directive 93/75/EEC (OJ L 208, 5.8.2002, p. 10).

( 3 ) VTT-secretariat@risexpertgroups.org