NaviPac Distributed Solutions

A12. Distributed solutions using NaviPac

28 August 2013 Page 1 of 21

 NaviPac Distributed Solutions

Table of content
1 INTRODUCTION........................................................................................................................................ 3

2 DATA FLOW.............................................................................................................................................. 3

3 EXCHANGE VESSEL AND OBJECT POSITIONS ........................................................................................... 3

3.1 DATA OUTPUT ............................................................................................................................................. 3
3.2 DATA INPUT ................................................................................................................................................ 5
4 SURFACE POSITIONING FROM REMOTE VESSEL ..................................................................................... 6
4.1 DATA OUTPUT ............................................................................................................................................. 6
4.2 DATA INPUT ................................................................................................................................................ 6
5 DISTRIBUTING RUN-LINES ....................................................................................................................... 7
5.1 DATA OUTPUT ............................................................................................................................................. 7
5.2 DATA INPUT ................................................................................................................................................ 8
6 DISTRIBUTING WAYPOINTS ................................................................................................................... 10
6.1 DATA OUTPUT ...........................................................................................................................................10
6.2 DATA INPUT ..............................................................................................................................................10
7 ANCHOR PATTERNS ............................................................................................................................... 11
7.1 DATA OUTPUT ...........................................................................................................................................12
7.2 DATA INPUT ..............................................................................................................................................12
8 MULTIPLEX DATA ................................................................................................................................... 13
8.1 DEFINING TELEMETRY..................................................................................................................................14
8.1.1 Polling ...........................................................................................................................................16
8.2 ONLINE MULTIPLEX .....................................................................................................................................18
9 DATA FORMATS ..................................................................................................................................... 19
9.1 NAVIGATION DATA .....................................................................................................................................19
9.2 RUN LINES .................................................................................................................................................20
9.3 WAYPOINTS ..............................................................................................................................................20
9.4 ANCHOR PATTERNS.....................................................................................................................................21

Version History
Version Who Additions
3.0 OKR 2002 Created
3.5 OKR 2005-09-16 Upgraded to 3.4D p12
3.5-1 OKR 2006-02-15 Added section on polled telemetry
3.5-9 OKR 2007-10-22 Modified section on runline
3.5 OKR 2011-03-30 Adjusted section on telemetry

28 August 2013 Page 2 of 21

 NaviPac Distributed Solutions

1 Introduction
This document describes how to exchanges various information types between two or more
NaviPac systems.

2 Data flow
Each vessel must be equipped with a decent NaviPac system, i.e. full blows or dedicated tug
version.

Communication can either be performed using ordinary telemetry (established using some
intelligent modem set-up {Only tested with Satel 2ASX}) or LAN (Wireless?) using UDP/IP
protocol.

Data can be send point-to-point (i.e. one communication channel per data source), broadcasted (one
sender many listeners) or multiplexed on one channel.

NaviPac supports the following information being transferred:

 Remote positioning:
Full positioning and data of remote objects. Including position, heading, motion data and
data acquisition data (1 channel)

 Surface navigation:
A vessel is positioned from another vessel, e.g. Tugboats being positioned using remote
range/bearing.

 Run lines:
Distribution of run lines from main vessel to one or more vessels.

 Waypoints:
Distribution of waypoints from main vessel to one or more vessels.

 Anchor patterns:
Distribution of anchor pattern (part of RIG move/ tug management system) and intended
position.

In the simplest set-up, you can transfer one of each data type per port (COM port or UDP/IP port).
If a vessel need to receive more than one data type on a COM port (and perhaps send data out on
the same port), it requires a multiplex telemetry solution.

Each of these scenarios is discussed in the following sections.

3 Exchange vessel and object positions

The first scenario describes the situation, where two or more vessels need to exchange their
positioning data.

3.1 Data output

To distribute data to another vessel, you must define a “Data to external nav. System” instrument.

This instrument can hold several positioning information in the same interface:

28 August 2013 Page 3 of 21

 NaviPac Distributed Solutions

1
The driver supports currently 8 data formats:

1. NaviPac
X, Y and heading

2. Winfrog
Lat, Long and heading

3. NMEA alike
Lat, Long and heading

4. Expanded NaviPac
X, Y, Z, Heading, Roll, Pitch, Heave, Altitude, Std. Dev. Age

5. NaviPac plus tug status

Like NaviPac. But expanded to send GPS status, geodesy and CRP definitions. Mainly
used from tug to barge

6. Apache $SFPOS
Position, height and heading in grid coordinates

7. IMCA
Position and heading in IMCA $..TEL,PH format

1
NaviPac 3.5 patch 22

28 August 2013 Page 4 of 21

 NaviPac Distributed Solutions

8. Sonsub $PSURP
Position in format required by Sonsub 3D QC module

If the data is to be read by another NaviPac system, we recommend the NaviPac or the
expanded NaviPac format.

The outputs will be given id numbers, as the First Id field specify the number for the first item.

Data will be sent with an output frequency as defined in Rate (in cycles).

3.2 Data input

If a vessel wants to read external navigation data, he must include a dynamic positioning
instrument of the type Remote Dynamic Objects (1-10):

The system can handle the same 8 formats as defined in previous section (and Thales Tracks,
Century Subsea Spar and Ixsea GAPS), as the driver based on data layout determines the format
automatic.

For each wanted object (= vessel or remote object from the sender), the operator must specify
name of vessel and id, where id must correspond to the id define in previous section.

28 August 2013 Page 5 of 21

 NaviPac Distributed Solutions

Having defined this instrument, each selected object are now positioned as XY and presented on
the HD with attached heading. If the format was based on expanded NaviPac format, you can
select the following instruments:

 Gyro From NaviPac

 RP From NaviPac

 Data from NaviPac

All these instruments are dedicated calculated instruments, which only make sense if a Remote
Dynamic Objects based on expanded NaviPac is selected. You must include one instrument per
object (in the above example you must define two gyro’s – one for “TUG 1” and one for “TUG 2”)
you want to include.

4 Surface positioning from remote vessel

This scenario is a kind of specialisation of section 3. If a smaller vessel (e.g. tug boat) doesn’t have
it’s own navigational system, but is positioned from main vessel or platform (using e.g. remote
Fanbeam or similar). Then the position can be transmitted from main vessel to the tug and used for
surface navigation, i.e. enable full NaviPac appearance.

4.1 Data output

Output from main vessel is defined as an ordinary output to remote nav. system, as discussed in
previous section. There is one special thing to note – the receiver can in current version only
handle one incoming string, i.e. it does not separate on vessel id’s. To do so you must either only
transmit the one object or send it as id 0 and combine with multiplex telemetry.

4.2 Data input

On the receiver a navigation system must be defined to handle the data:

28 August 2013 Page 6 of 21

 NaviPac Distributed Solutions

The definition is similar to other inputs (like XY), as the operator can apply C-O on eating and
northing. The position id is not used in current configuration, but will probably be enabled later on.

Having defined a system for this, you can simply define an instrument of the type, and it will act as
any other navigation instrument.

Please note, that you as minimum must define a gyro (either real or calculated) to be able to use
NaviPac on the remote vessel.

5 Distributing run-lines
A very general scenario is two or more vessels operating in the same are, it could be survey or tug
boats or combination of these. A common question could be – where are the other vessels going to
operate. An answer to that could be sharing run-line between the vessels.

5.1 Data output

If a vessel want to distribute it’s run lines to another vessel(s), he must define a output of the type
Remote NaviPac – Control:

28 August 2013 Page 7 of 21

 NaviPac Distributed Solutions

There is no special setting to this output.

A message will be sent each time a run-line is activated, as the message contains name of run-line
and all run-line parameters defined. It does also contain the number of the object controlling the
runline – so only the tug in action will activate it

A message will also be broadcast when performing start or stop of line.

5.2 Data input

If a vessel need’s to receive the information, it requires a special input of the type Remote NaviPac
– control:

28 August 2013 Page 8 of 21

 NaviPac Distributed Solutions

When NaviPac start’s online, a new remote NaviPac module is opened automatically:

This module covers both run line, waypoint and anchor pattern messages.

When a run-line message (or in fact a series of messages has been received), it displays the name
of the current run line, which is identical to the name used on the mother vessel plus a sequence
number. The module creates a new run line with that name, and the sequence number protects
against overwriting is vessels uses same name.

28 August 2013 Page 9 of 21

 NaviPac Distributed Solutions

A message is automatically sent to the Helmsman’s Display and the runline is displayed
automatically.

Please note that this only will be activate if this tug boat is controlling the line on the barge

6 Distributing waypoints
NaviPac includes a feature, where active waypoints can be distributed to other vessels. The
distribution is from version 3.4D patch 10 directed from barge to tug via the object selected in the
Helmsman’s Display Range/Bearing view. For further details please refer to Appendix A11.

6.1 Data output

If a vessel want to distribute its waypoints to another vessel(s), he must define an output of the type
Remote NaviPac – Control:

There is no special setting to this output.

A message will be sent each time a waypoint is activated, i.e. when the operator defines a
range/bearing view to a waypoint on the Helmsman’s Display.

6.2 Data input

If a vessel need’s to receive the waypoint information, it requires a special input of the type Remote
NaviPac – control:

28 August 2013 Page 10 of 21

 NaviPac Distributed Solutions

When NaviPac start’s online, a new remote NaviPac module is opened automatically:

This module covers both run line, waypoint and anchor pattern messages.

When a waypoint message has been received, it displays the name of the current waypoint, which
is identical to the name used on the mother vessel.

A message is automatically sent to the Helmsman’s Display and displayed here.

7 Anchor patterns
If NaviPac is used in a RIG Move / Tug management scenario, a common requirement is to
distribute anchor patterns and tug commands from rig to the tugboats. For a full description of RIG
Move and TUG management, please see A11_RIG_Move.doc.

28 August 2013 Page 11 of 21

 NaviPac Distributed Solutions

7.1 Data output

If a vessel want to distribute anchor patterns to a tug / remote vessel, it must include a driver called
Data to tug boats:

This driver supports either the Stolt Offshore PCTUG format, which can’t be interpreted by a
remote NaviPac or the EIVA format.

7.2 Data input

If a vessel need’s to receive the information, it requires a special input of the type Remote NaviPac
– control:

28 August 2013 Page 12 of 21

 NaviPac Distributed Solutions

When NaviPac start’s online, a new remote NaviPac module is opened automatically:

This module covers both run line, waypoint and anchor pattern messages.

When a TUG related command is received, the message is displayed and distributed to the
Helmsman’s display. Each time an update is received, either automatic or due to change, the
Helmsman’s display is updated automatically.

8 Multiplex data
In more and more situations, the various distributed solutions are implemented using wireless LAN
connections, where NaviPac reads and sends data on UDP/IP ports.

But we still see the need for original telemetry solutions, where data is transferred on radio links. In
NaviPac a radio link is connected to COM ports, and can be handle as if we had a direct serial link
between the two computers. It’s even possible to make broadcast solutions, where data from one
vessel can be received on several other vessels.

28 August 2013 Page 13 of 21

 NaviPac Distributed Solutions

For some installations this will not be sufficient, as then need some mixture of scenarios, and need
to send and receive more information on the same serial port (= radio link).

To be able to handle this, we have introduced a multiplex telemetry, where a dedicated multiplex
module reads and sends data on a port and communicated with NaviPac on a series of UDP/IP
ports. It’s only possible to have one multiplexed port in current set-up.

8.1 Defining telemetry

To enable a multiplexed solution, you must activate Options, NaviPac Mode in NaviPac Config:

and select the Multiplex telemetry field.

This enables a new entry in the Options menu – Multiplex telemetry:

28 August 2013 Page 14 of 21

 NaviPac Distributed Solutions

NaviPac allows up to 3 multiplexer in operation at the same time – where each must identify a
mapping between a telemetry modem (a COM port) and a set of UDP/IP input/outputs, The
definition will be identical for all 3

In this dialogue you must specify which COM port you want to use for multiplex data. It can be
changed by double clicking on the COM box and selecting new port and settings.

Vessel Id is reserved for use in the polling master/slave and can be set to 0 in asynchronous. In
polling mode make sure that each vessel has got a unique number – we do normally recommend
30 for the barge, 31 for tug1 etc

Hereafter you must specify which kind of data you want to be able to read from the port, as you can
select between the following

 Surface navigation

 Remote navigation

28 August 2013 Page 15 of 21

 NaviPac Distributed Solutions

 Runline control (including waypoints)

 Tug management

Please note that the points correspond to the various scenarios discussed earlier.

For each selected type you must enter a UDP/IP port. This port number must be used in the
ordinary NaviPac set-up, as e.g. the remote navigation uses port 9191:

The output can also handle outputs, as it will grab all data defined on the UDP/IP port, i.e. it’s
possible to mix more than one output.

8.1.1 Polling
The multiplexer can be operated in three modes

28 August 2013 Page 16 of 21

 NaviPac Distributed Solutions

 Asynchronous:
The default mode where all in- and outputs are un correlated. Data is sent out whenever
received. This might introduce collisions if the modems aren’t handling buffering.
There are no special settings.

 Polling master:
The Barge acts as a master in the communication. Tugs will only transmit within certain
time-slots. This will optimize the use of the bandwidth and minimise the risk for collisions.
Tugs are divided into three groups: Tracking, Assigned and others. Each group is polled in
their own cycle.

o Primary time slot:

The main polling frequency in milliseconds (ms). Each polling sequence is started
with this interval.
In TMS scenario tracking vessels are polled with this interval.
In normal scenario all vessels are polled with this frequency

28 August 2013 Page 17 of 21

 NaviPac Distributed Solutions

o TMS: Assigned polling frequency:

How often is assigned vessels polled. Given as multiply of primary time slot

o TMS: Default polling frequency:

How often is all other vessel polled. Given as multiply of primary time slot
For non TMS operation this will be the same for all vessels

o Rx/Tx Overhead:
How much time must the system give the modems to switch mode. Must be
specified very carefully. Given in ms.

o Maximum Reply Characters:

How many character do we maximum expect to receive from a slave. The total
slave time slot is defined approximately as Rx/TX Overhead + time to transmit
maximum characters. This value must be set carefully.
The optimal solution would be obtained by setting it too high and let the slave
send acknowledgements.

o Echo position data:

Shall the module duplicate all incoming position telegrams (NaviPac format) to the
slaves.

o Send commands between polls:

Shall any output from the barge be send in the middle of a polling sequence – or
await total completion.

o Slaves:
The total list of tugs being polled. This has to be defined very carefully before
starting up, as the master needs to know the tug that has to be polled.
The list is defined as space separated list of object numbers. Press the Get button
to read list from NaviPac setup.
The id numbers must be identical to the Vessel id on each slave.

 Polling slave:
If the barge is using polling master then all slaves must be set into Polling Slave mode.
That is it will only send data out on the modem within a certain time slot. Definition of slots
handled purely by the master.
The operator must specify the following:

o Send slave acknowledgement:

The slave sends a special end message when all buffered messages has been
sent out. This allows the master to close the timeslot prior to timeout and thus
utilise the bandwidth.

o Vessel id:
Identification number of this slave vessel. Must be identical to the number used
onboard the master – default is the object id from the master.

8.2 Online multiplex

If NaviPac is defined with multiplex option, a special multiplex module is opened automatically. This
window reads data from the port and distributes it to NaviPac and visa versa. Therefore: do not
close that window.

28 August 2013 Page 18 of 21

 NaviPac Distributed Solutions

The window displays the data coming in, as it’s ordered after the interpreted type, and can
therefore be of a great help during mob phase. After that – just minimize it.

9 Data formats
This section gives a short definition of the used exchange format between NaviPac’s.

9.1 Navigation data

The NaviPac format (ordinary and expanded) is as follows:
<stx>,<id>,<easting>,<northing>,<heading> XX, <height>, <std.dev>, <roll>, <pitch>, <heave>,
<altitude>, <age> *<checksum> <cr><lf>, where

<stx> Binary digit 2

<id> Vessel id
<easting> Easting of vessel – grid X
<northing> Northing of vessel – grid Y
<heading> Vessel heading in degree
XX Marks that the string contains expanded information:
<height> Height/depth of vessel
<std.dev> Quality of positional data
<roll> Roll in degree
<pitch> Pitch in degree
<heave> Heave in m
<altitude> First attached data acquisition channel – typical altitude
<age> Age of data when transmitted on port
<checksum> Checksum calculated using NMEA standard.

28 August 2013 Page 19 of 21

 NaviPac Distributed Solutions

Sample:

12,550000.000,6299999.997,359.314 XX,15.40,0.00,2.34,-0.45,1.23,-1.05,0.075 *02

9.2 Run lines

A NaviPac run line is transmitted as a series of messages:

$EIRRL,HEAD1,<number>,<id>,<type>,<path\name><cr><lf>
$EIRRL,SIZE,<filesize><cr><lf>
$EIRRL,RLN,1,"<info>"<cr><lf>
$EIRRL,RLN,2,"<name>"<cr><lf>
$EIRRL,RLN,j,<EIVA run line data><cr><lf> // One string per segment
$EIRRL,EOT<cr><lf>

$EIRRL,CLR<cr><lf>

Where

<number> Id of object controlling the line

<id> EIVA run line identifier
<type> EIVA run line type identifier
<path\name> Where was original file stored (relative to $EIVAHOME)
<filesize> Size of original run-line file
<name> Name of run line
<EIVA run line data> Parameters defining each segment – see Helmsman’s manual

Sample:

$EIRRL,CLR
$EIRRL,HEAD1,3,2,0,Runlines\FromBarge_003.rlx
$EIRRL,SIZE,328
$EIRRL,RLN,0,# 22/02/2006 16:20:16
$EIRRL,RLN,1,"TestSjov"; 64; 0.0000; "Meter"
$EIRRL,RLN,2,464483.380; 6147130.340; 464596.210; 6147815.950; 0.00000000; 0.69483212;
0.0000; 17; 64
$EIRRL,RLN,3,464596.210; 6147815.950; 464778.810; 6147865.760; 0.69483212; 0.93241901;
104.0856; 1; 128
$EIRRL,RLN,4,464778.810; 6147865.760; 464956.960; 6147716.330; 0.93241901; 1.16494158;
0.0000; 17; 64
$EIRRL,EOT
$EIRRL,SOL,3

9.3 Waypoints
An active waypoint is transmitted as one message:

$EIRWP,<id>,<easting>,<northing>,<name><cr><lf> , where

<id> EIVA identification number

<easting> Easting of waypoint – grid X
<northing> Northing of waypoint – grid Y
<name> Name of waypoint (corresponds to filename)

Sample:

$EIRWP,0,549825.26,6300169.87,Girassol1

28 August 2013 Page 20 of 21

 NaviPac Distributed Solutions

9.4 Anchor patterns

Each time the anchor state changes (or at least with some user defined interval) a message is
transmitted. The format must be selected to either EIVA format or PCTug (Stolt Offshore France)
format. The message is sent in the selected format.

EIVA format:

 Anchor pattern:
$TUG-R, <Ep>, <Np>, <Hp>, <rigname>*<ChS><cr><lf>
$ANC-U,<tug>,<anchor>,<state>,<Ep>,<Np>,<Ea>,<Na>,<name>*<ChS><cr><lf>
for every anchor

 Single Anchor Update:

$ANC-U,<tug>,<anchor>,<state>,<Ep>,<Np>,<Ea>,<Na>,<name>*<ChS><cr><lf>
For every state and position command, the anchors attributes are updated and then we send a
Single Anchor Update for the actual anchor.

 Text message:
$TUG-M,<tug>,<text>*<ChS><cr><lf>

 MLB update:
$MLB-U,<ObjNo>,<E>,<N>,<meridConv>*<ChS><cr><lf>

 MLB removal:
$MLB-R*<ChS><cr><lf> (removes all MLB objects)

For Stolt Offshore PCTug format see A11 Rigmove & Tug management manual.

28 August 2013 Page 21 of 21