EPIS Pilot – Status Paper 2 (03 June 2011)
EPIS Pilot
Status Report: 2
Background
In December 2010 the PLATINA project produced a draft Functional Specification for an EPIS Pilot in
which a number of specific (potential) applications of EPIS were considered. This specification would
form the basis for the realisation of the Pilot itself, in close cooperation with the IRIS Europe II project,
and serve to illustrate potential functionality within a dissemination and evaluation program.
Following discussions between the PLATINA and the IRIS Europe II projects it was agreed in May
2011 that the scope of the EPIS Pilot be reduced, in part due to the fact that the user requirements,
and perceived need for such a service, were still tentative and that the full potential of EPIS was still
subject to many issues relating to legal and organisational barriers and not so much the technical
capabilities of the involved EU Member States. The revised EPIS pilot would therefore focus on
providing a working demonstrator to confirm the technical capability whilst forming output that could
be used in a dissemination program for discussions with potential users through, amongst others, the
Logistic Task Force.
Whilst the original specification considered the distribution of position, cargo and voyage data, the
revised scope only considers position data. This appeases a number of current legal and
organisational barriers whilst it is envisaged that the resulting Pilot will not disproportionally
compromise the ability to use the Pilot for discussions with potential users for the further expansion of
such services to include cargo and voyage data.
Purpose of the EPIS Pilot
The European Position Information Service (EPIS) is a concept under development as a potential
augmentation to River Information Services (RIS). An eventual EPIS is intended to support authorities
and logistic service providers in providing data on the actual position, voyage and cargo of a vessel
and is provided on a pan-European basis whereby a user based in one Member State can retrieve
information on the progress of a vessel in another Member State in order to support the relevant (and
authorised) operations. For the purposes of the EPIS pilot only position data will be considered; an
evaluation for the need for cargo and/or voyage data will form part of the dissemination and
evaluation activities within the Pilot. The tracking or tracing of a vessel is dependent on specific
conditions and access to vessel-related data is always only available to authenticated and authorised
users. It is not intended that EPIS will replace RIS information exchange services on a national basis
for processes such as traffic management or the required cross border information exchange.
It is foreseen that the position information for the EPIS pilot is derived from AIS broadcasts from
participating vessels on the inland waterway network of Austria, Slovakia, Hungary, Belgium and the
Netherlands. Initial consideration for the need for additional data through existing electronic (voyage)
information processing systems, ERINOT messages and the European Hull Database pilot has been
revised for the EPIS pilot and will not be required at this stage.
The structure and content of the messages for exchange of information defined in the IRIS Europe
project, including access rights principles, have been accounted for as much as possible. To this end
03 June 2011
Page 1
EPIS Pilot – Status Paper 2 (03 June 2011)
it is the intention that EPIS is in line with the RIS standards as defined in the context of the RIS
directive, in particular standards related to Vessel Tracking and Tracing, Electronic Reporting (ERI)
and the project standard for international RIS Data Exchange (R2D2).
Status
The following Milestones have been determined for the realisation of the EPIS Pilot and the
subsequent dissemination and evaluation activities:
Milestone
1
2
3
4
5
6
7
Description
Revised Technical Specifications (according scope of
limited EPIS pilot to facilitate development by participating
national RIS centres)
EPIS pilot internal test
EPIS pilot tested and delivered for connection to third
parties / final specifications
Third parties (participating national RIS centres) connected
to EPIS pilot
Presentations conducted / EPIS pilot system end of
operational phase / pilot technical support complete
Evaluation performed
Final report issued
Completion Date
31/05/2011
15/06/2011
15/07/2011
31/07/2011
30/10/2011
30/11/2011
31/12/2011
The Pilot is currently being realised and will be ready for internal tests by 15 th June. Connection to
other RIS centres will be available by 15th July latest and it is the intention to complete connections by
31st July.
Proof of Concept
The EPIS Pilot is to be realised as a Proof of Concept under the following assumptions and principles:
To realize the minimal functionality EPIS, is described as:







Only position information (but also ENI number and time-stamping) will be recorded and
shared (no other ship-related information, such as voyage, cargo, hull will be stored or
distributed);
Historical (position) data will be logged, but will not otherwise be visible or published (no
historical tracks). The last reported position should be known;
Only position information can be accessed by authorized parties (no other related
information);
RIS centres will periodically (automatically every 15 minutes) send their position information
to the EPIS and EPIS will publish the last received positions (EPIS will not have the
functionality to request RIS centres for additional updates or for ensuring that position
information is actual);
The interfaces are based on web services and existing R2D2 messages (see Figure 1);
The current IRIS-layer does not (yet) have SSL functionality. This functionality will be realized
subject to applicable RIS standards. If necessary this will require coordination with other EU
partners and their RIS specialists;
The EPIS will use its own (simple) user accounts for authentication (no single sign on);
03 June 2011
Page 2
EPIS Pilot – Status Paper 2 (03 June 2011)



Role Based Access will not be implemented (EPIS user accounts will be used for
authorization);
Interfacing with other databases (EU Hull DB, ERINOT server etc.) will not be realized at this
stage;
The functioning of the EPIS Pilot in its ability to respond to position requests is highly
dependent on the input to EPIS by the participating RIS centres.
Figure 1: EPIS system
03 June 2011
Page 3
EPIS Pilot – Status Paper 2 (03 June 2011)
Process
The following process(es) are to be supported by the (revised) EPIS Pilot:
See Note 1
See Note 2
Figure 2: EPIS process
Note 1:
The initial process with regard to the “Access Rights Matrix” will not form part of the Pilot and will be
completed on an individual basis with respect to ensuring access merely for illustrative purposes. In
the event of a valid user request for ‘connection’ to the Pilot then the necessary authentication and
authorisation checks will be conducted manually before granting access. This is to reduce any burden
on the partners with respect to data provision.
03 June 2011
Page 4
EPIS Pilot – Status Paper 2 (03 June 2011)
Note 2:
The national RIS centres that have agreed to provide regular updates on position data are:





Austria;
Slovakia;
Hungary;
Belgium;
The Netherlands.
In the case of Austria, Slovakia and Hungary it has been agreed that position updates are to be
provided at intervals of 15 minutes. For Belgium and The Netherlands it has been agreed that, whilst
the ambition is to provide the updates every 15 minutes, the update interval may be re-evaluated
during pilot testing and connection to participating countries in order to allow for the expected high
volume in data traffic.
Position data is to be provided by the participating RIS Centre III (RIS Centre Vessel Current) by
means of the message “Not_data.xml”. On request of the participating RIS Centres the
“receipt_data.xml” message will not be used.
The “Not_data.xml” message will include the relevant data from the Header, IMO message 1 and IMO
message 5. See appendix.
The revised EPIS Pilot only deals with position data and as such fields such as Destination,
TypeShipand Cargo and ETA are not required even if known. For the limited purpose it is envisaged
that key data fields include:



Header:
o TestID;
o SentAt;
o From.
IMO_Msg 1:
o MMSI (vessel id);
o NavigationalStatus;
o Position (Lat/Long);
o TimeStamp.
IMO_Msg 5:
o Name;
o PositioningDevice.
As previously stated (Note 1) the authentication and authorisation process will be conducted
“manually” whereby verified users will be able to access pertinent data on the basis of individual
requests to the administrator of the EPIS pilot. It is envisaged that this may be conducted on an adhoc basis in order for potential users to evaluate and provide feedback on the potential of EPIS during
the dissemination phase of the EPIS pilot.
“Req_data.xml” is to be used by ‘authorised’ users to request the latest position of a particular vessel.
EPIS will respond with the “resp_data.xml” message.
03 June 2011
Page 5
EPIS Pilot – Status Paper 2 (03 June 2011)
It is envisaged that the EPIS pilot will remain in an operational phase until end October 2011, whereby
participating RIS centres should provide the “Not_data.xml” messages until this time. Following this
the operational phase of the Pilot will be suspended.
Actions
The following actions are foreseen in the coming period (June 2011):
1. (Re-) Confirmation partners with respect planned milestones (3,4,5):
Partners requested to (re-)commit to the planning dates. In the case of Austria, Slovakia,
Hungary and Belgium this refers to the ability to complete connection to the EPIS pilot by 31
July 2011.
2. Further definition relevant data fields for “not_data.xml”:
Whilst an indication of (some) relevant data fields has been provided above it is necessary for
each partner to indicate which data fields can be sent as part of each update.
3. Test scheme (timing):
Following confirmation by each partner a test scheme can be set up indicating when
connection can be made to the EPIS.
4. Request_data protocol for Pilot purposes:
Discussions will commence on which users can/should be able to access which data from the
EPIS. A pre-condition is the respect of privacy and confidentiality issues.
03 June 2011
Page 6
EPIS Pilot – Status Paper 2 (03 June 2011)
Appendix
The following table for the “Not_data.xml” has been extracted from Section 3.1.1.1. of the RIS Data
Exchange XML Messaging Reference Guide (v1.3.1). All citations to “chapters” etc. refer to the
original document:
Item
Header
Occ
1
Version
Type
Length
1
Text
3
0-1
0-1
Text
Text
8
38
1
DT
19
0-1
Int
From
1
Text
7
To
1
Text
7
StatusCode
0-1
Enum
StatusMessage
0-1
Text
Role
0-n
ENUM
User_ID
0-1
Text
255
Password
0-1
Text
32
User_Location
0-n
Text
20
User_permitted_re
quest_area
0-n
Text
40
TestId
MSRefId
SentAt
TimeoutValue
03 June 2011
0-255
Description
The Version field is an attribute of the Header
element. The format of the version is n.m. The
current version of the header is 0.1. If a new XSD
is released, the version has to be increased. All
RIS centres are not allowed to accept older XML
messages.
Test Case identification. Only useful for testing.
Unique Identifier for each sent Message. This Id
has to be inserted by the client in the Response
Message. If a message has to be retransmitted a
new MSRefId has to be used, and the old one is
not valid any more.
Notification creation date and time (ISO 8601 UTC
format)
Timeout value (in seconds) indicating when the
request should be considered as expired and must
not be processed.
Used for the international exchange of any defined
xml message whereas the field “From” contains
always the Codification of the RIS Centre that has
sent the xml message.
The name of the receiver of the message
(Codification of the RIS Centre in case of
international data exchange)
Global status code. Details are to be defined.
Mandatory only for Messages answering a request
or confirming a Notification. See 3.6 of the
Technical System Concept for more details.
Global status message string. Mandatory only for
Messages answering a request or confirming a
Notification
Roles of requesting user (TCA,…) used for
Req_Data Messages only. This field is only
important for RIS Centre- RIS Centre
communication. ; Not needed within this message
Not needed within this message; Identifies the
requesting user in the international data exchange
by the unique UserID as defined within the
Process Description (chapter 11: Annex 7: Unique
UserID)
Element: Password of the user; Not needed within
this message
Location Code(s) of the User; Not needed within
this message
2 Location Codes; the user is permitted to request
data of vessels currently navigating between those
two locations; Not needed within this message
Page 7
EPIS Pilot – Status Paper 2 (03 June 2011)
Body
Item
Occ
1
Notify_AIS
0-n
Type
Length
Response element node(s). More than 1
element node might be given (batch process)
IMO_Msg1
0-1
MessageID
RepeatIndicator
1
1
Int
Int
MMSI
NavigationalStatus
1
1
Int
Int
ROT
1
Int
SOG
1
Int
PositionAccuracy
1
Int
Longitude
1
Int
Latitude
1
Int
COG
1
Int
TrueHeading
1
Int
TimeStamp
1
DT
UN_CountryCode
1
Text
2
UN_Location_Cod
e
FairwaySectionCod
e
FairwayHectometre
1
Text
3
1
Text
1
Text
Blue sign
1
Int
RegionalBits
1
Int
Spare
1
Int
03 June 2011
Description
Identifier for this message 1, always 1
Used by the repeater to indicate how many times a
message has been repeated. Default = 0; 3 = do
not repeat any more
User ID (MMSI number)
0 = under way using engine;… see Inland AIS
Standards for details
±127 (–128 (80 hex) indicates not available, which
should be the default). Coded by ROTAIS=4.733
SQRT(ROTINDICATED) degrees/min
ROTINDICATED is the Rate of Turn (720 degrees
per minute), as indicated by an external sensor.
+127 = turning right at 720 deg
Speed over ground in 1/10 knot steps (0-102.2
knots) 1023 = not available; 1022 = 102.2 knots or
higher *1
1 = high (< 10 m; Differential Mode of e.g. DGNSS
receiver) 0 = low (> 10 m; Autonomous Mode of
e.g. GNSS receiver or of other Electronic Position
Fixing Device) ; default = 0
Longitude in 1/10 000 min (±180 degrees, East =
positive, West = negative. 181 degrees (6791AC0
hex) = not available = default)
Latitude in 1/10 000 min (±90 degrees, North =
positive,South = negative, 91 degrees (3412140
hex) = not available = default)
Course over ground in 1/10° (0-3599). 3600 (E10
hex) = not available = default; 3 601 – 4 095
should not be used.
Degrees (0-359) (511 indicates not available =
default).
Timestamp (data and time) of tactical traffic
information (UTC Format YYYY-MM-DD-HHMMSS+z)
UN Country Code calculated from vessel´s
position
UN Location Code calculated from vessel´s
position
Fairway Section Code calculated from vessel´s
position
Fairway Hectrometer calculated from vessel´s
position
Indication if blue sign is set 0 = not available =
default, 1 = no 2 = yes, 3 = not used *2
Reserved for definition by a competent regional
authority. Should be set to zero, if not used for any
regional application. Regional applications should
not use zero.
Not used. Should be set to zero. Reserved for
future use
Page 8
EPIS Pilot – Status Paper 2 (03 June 2011)
Item
Occ
Type
RAIM_Flag
1
Int
CommunicationSta
te
1
Int
Length
IMO_Msg5
0-1
MessageID
RepeatIndicator
1
1
Int
Int
MMSI
AISVersion
1
1
Int
Int
IMO_Number
CallSign
1
1
Int
Text
7
Name
1
Text
20
TypeShipAndCarg
o
1
Int
DimensionsShipCo
nvoy
1
Int
PositioningDevice
1
Int
ETA
1
DT
MaximumPresentS
taticDraught
Destination
1
Int
1
Text
DTE
1
Int
Spare
1
Int
03 June 2011
Description
RAIM (Receiver Autonomous Integrity Monitoring)
flag of Electronic Position Fixing Device; 0 = RAIM
not in use = default; 1 = RAIM in use)
See chapter 7 (Annex 2 – Reference to ITU-R M.
1371-1: table 15B)
20
Identifier for this message 5
Used by the repeater to indicate how many times a
message has been repeated.
User ID (MMSI number)
AIS Version Indicator: 0 = Station compliant with
AIS Edition 0; 1 - 3 = Station compliant with future
AIS Editions 1, 2, and 3.
1 – 999999999 ; 0 = not available = default *1
7 × 8 bit ASCII characters, "@@@@@@@" = not
available = default. *2
Maximum 20 characters 8 bit ASCII,
@@@@@@@@@@@@@@@@@@@@ =
not available = default.
Type of Ship and Cargo, 0 = not available or no
ship = default; 1 - 99 = as defined in § 3.3.8.2.3.2;
100 - 199 = preserved, for regional use; 200 - 255
= preserved, for future use. *3
Reference point for reported position; Also
indicates the dimension of ship in metres (see Fig.
18 and § 3.3.8.2.3.3) *4,5,6
Type of Electronic Positioning Fixing device:
0 = Undefined (default);
1 = GPS,
2 = GLONASS,
3 = Combined GPS/GLONASS,
4 = Loran-C,
5 = Chayka,
6 = Integrated Navigation System,
7 = surveyed,
8 = manual entry,
9 - 15 = not used.
Timestamp (data and time) of ETA (UTC Format
YYYY-MM-DD-HH-MM-SS+z)
in 1/10 m, 255 = draught 25.5 m or greater, 0 = not
available = default; *5
Destination of vessel (Codification UN Country
Code/UN Location Code/Terminal Code)
Maximum 20 characters using 8-bit ASCII;
@@@@@@@@@@@@@@@@@@@@ =
not available
Data terminal ready (0 = available, 1 = not
available = default)
Spare. Not used. Should be set to zero. Reserved
for future use.
Page 9