a12. distributed solutions using navipac - eivadownload.eiva.com/online-training/navipac...

NaviPac Distributed Solutions

28 August 2013 of 21

A12. Distributed solutions using NaviPac



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


5 DISTRIBUTING RUN-LINES ....................................................................................................................... 7


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



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:



The driver supports currently 8 data formats:1

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



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.



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:



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:



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:



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.



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:





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.



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:





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.



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:



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



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



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



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.



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.



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



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.

a12. distributed solutions using navipac - eivadownload.eiva.com/online-training/navipac...

Documents