NaviPac. 17. General Design of NaviPac

Transcription

1 NaviPac 17. General Design of NaviPac

2 Version History Version Who Additions 1.0 kup Created 2.0 kup Updated with timing principles + start/stop of NP 2.1 kup Updated header/footer, figures, cross refs. 2.2 OKR : Updated section on timing principles (UTC timing) kup : New visual analyst figure updates, better description of DB s and processes. 3.0 OKR : New section on heave correction 3.4 OKR 2003 section on gyro correction and extra information on heave correction. 3.8 OKR Upgraded GUI 19 April, 2012 Page 2 of 36

3 Table of contents 1. INTRODUCTION CONVENTIONS COMMON DEFINITIONS READING GUIDE REFERENCES GENERAL DESCRIPTION OF NAVIPAC DFD DIAGRAM OBJECT TYPES PROGRAM ENVIRONMENT NaviPac <-> Instruments NaviPac <->NaviScan NaviPac <->Datafiles NaviPac <->Printer NaviPac <-> User DESCRIPTION OF NAVIPAC PROCESSES DATAIO/O KERNEL REMOTE ACCESS NAVIPAC ONLINE SIMULATEDATA BASE POSITION NAVIPAC SET-UP LOGDATA HELMSMAN OBJPOS ATTITUDES DATAACQ GPSMONITOR GPS STATUS LOCAL ACCESS RAWDATA USBL CALIBRATION CATENARY QC INTER PROCESS COMMUNICATION (IPC) TIMING PRINCIPLES IN NAVIPAC FUNDAMENTALS ORDINARY TIMING TIMING SUPPORTED BY EXTERNAL INFORMATION LATENCY IN STRING USING ORDINARY $..ZDA INFORMATION USING ASHTECH $PASHR - FUTURE USING TRIMBLE UTC MESSAGE IMPLEMENTATION OF PPS GPS -> NAVIPAC CABLE SPECIFICATION IMPORTANT MESSAGES /EVENTS BETWEEN PROCESSES START STOP SNAPSHOT OF MESSAGES BETWEEN ONLINE AND KERNEL MESSAGES BETWEEN LOCAL-ACCESS AND GUI S MESSAGES BETWEEN REMOTE-ACCESS, LOGDATA & DATAACQ April, 2012 Page 3 of 36

4 6.6 MESSAGES BETWEEN REMOTE-ACCESS AND HELMSMAN COMMON DATA STRUCTURES (STORES) RAWDATADB DISPRAWDATADB KERNELDATADB REMOTEDATADB GENERALSETUPDB Example of GeneralSetupDB (in ASCII format) ONLINEDB Example of OnlineDB (in ASCII format) OBJECTDB Example of objects.txt PROCESSINFODB Example of ProcessInfoDB SPECIAL CALCULATIONS HEAVE CORRECTION RTK BASED GYRO CORRECTION SPEED AND GEOGRAPHICAL GYRO CORRECTION April, 2012 Page 4 of 36

5 1. Introduction This is the overall design document for the EIVA NaviPac navigation SW for the Windows platform. For a description of other Eiva products see NaviPac is a real-time integrated navigation and data acquisition system, which makes it possible to escalate one or more positions from various navigation sensors: Combining this information with real-time roll and pitch values gives the best-suited data resolution and correctness. Note: We only use the term NaviPac in the rest of this document. The design documentation is divided into several documents. This document only describes the highest level of the system: that is the processes that make up the total system. Each of the processes is described in separate design documents. The NaviPac SW has a long history behind. First it was written in HP basic to HP computers, then ported (still in basic) to PC platform. Some years ago it was rewritten to a UNIX (SUN/Solaris 2.X) platform. Now the primary target platform has been changed to Windows 1. The long history (more than 16 years) of the SW have enabled us to get a good background of designing a system on Windows that is very future minded as we have learned at lot from the many customers/projects that use our old SW. The NaviPac SW suite is designed as a networking application. The data communication protocol used is TCP/IP. The SW can be set-up to run on an unlimited number of workstations. The only requirements are that 4 main processes are started on the I/O computer. The GUI s can be run on all networked computers as wanted. The design methods and development tools used for the analyses and design, implementation, and documentation are: Tools/methods Windows version Solaris version Methods used SA/SD(RT), SA/SD (RT) OMT/UML Tools used Visible Analyst, Rational Rose Microsoft Visual Easy Case, XDesigner, Sun compilers C++ and C# Documentation Microsoft Word FrameMaker 4.0 Number of > pages. Lines of code > Currently supporting Windows XP, Vista and 7 in Professional Mode 19 April, 2012 Page 5 of 36

6 Table 1: Tools & Methods The biggest part of the code is written in C++. However the data I/O and Kernel and data distributor programs are written in C. The latter primary because of speed requirements. The most updated modules has been moved on to a.net platform written in C#. 1.1 Conventions Bibliographic references are written as [1]; by looking in the reference list included in the introduction, the origin/source can be found. Command names, program names and file names are printed in boldface letters, e.g. gensetup. DB. Italics are used for emphasising important parts of the text such as name of processes, e.g. Online. 1.2 Common Definitions Name Class Description A peace of code holding both attributes & Methods Command Command is another name for event. E.g. holds no information. DFD Data Flow Diagram EVENT A control flow that denotes the transfer of an event, trigger (e.g. start or stop), or enable/disable between symbols (process<->process or module<->module). Events are symbolised as dotted lines. GUI Graphical User Interface (we use Windows NT/MFC ) Message A data item between two or more processes that holds information which can be read and manipulated by the receiver process. Data exchanged between modules are denoted: parameter. MFC Microsoft Foundation Classes Module A part of a process that contains isolated functionality. A module will normally contain one or more c functions an these are placed in a separate.c-file. Object A class that is instantiated at run time OOA/OOD Object Oriented Analyses and Design Parameter Data exchanged between modules. The counterpart for processes are denoted Message. Process Used for all programs which is run as a separate NT process. SA/SD(RT) Structured Analyses & Design with Real Time 19 April, 2012 Page 6 of 36

7 UML Unified Modelling Language OOA/OOD notation Table 2: Definitions 1.3 Reading Guide It will be a great help if the reader is familiar with object oriented SW development (OOA/OOD) and also Structured Analyses and Design methods (SA/SD) as we use Class diagrams, Context diagrams, Data Flow diagrams etc. The documentation follows most of the guidelines specified in the [6]. In chapter 2 a general description of the NaviPac system and the relationship to its surroundings can be found. This is done using context a diagram and of cause a textual description. In chapter 3 the NaviPac system is outlined in a DFD. Here all major processes, stores (files, memory structures) and data flows are described. The processes are numbered 1,2,3, etc. Data-flows and global stores (e.g. files for common information, shared memory structures) are outlined in Figure 2 Processes & DBs in NaviPac system. The basic data and the related structures used in NaviPac are also briefly described. In chapter 5 timing principles used in NaviPac are discussed. A brief introduction (snapshot) of the internal/external interfaces in NaviPac is described in chapter References This reference list will is used in all design documents in the NaviPac project. The design documentation consists of an overall document (this one) and a number of process design documents. See [11]-[25]. Note: [11]-[25] are design documents from the Solaris version of the product and are for internal use only. Also see User Guides in NP Document references.doc. References used in this project are: 1. NAVIPAC-UX SYSTEM DESCRIPTION EIVA A/S 2. YSBm MCM-system - SPECIFICATION FOR CONTRACT Erisoft, EIVA and FMV 3. Visual C++ programmers & Users guide - Microsoft 4. YSBm - MCM PRODUCTSPECIFICATION, PAC-PS-01-01, Ole Kristensen, EIVA a/s 5. System Requirement Specification, PAC-RS-01-01, Ole Kristensen, Eiva a/s 6. Struktureret Program Udvikling, ISBN , Stephen Biering-Sørensen a/o. 19 April, 2012 Page 7 of 36

8 7. Structured Development for real-time systems, by Paul T. Ward and Stephen J. Mellor, Yourdon Press, ISBN EasyCase Methodology Guide (version 4.0), Evergreen CASE Tools, 0593 Part No. MMA VisibleAnalyst workbench Turtorial see General Design of NaviPac NT kup 1998 (this document) 11. Process Design for NaviPac Set-up, PAC-DS ( ) 12. Process Design for NaviPac Online, PAC-DS-03-01( ) 13. Process Design for Kernel, PAC-DS ( ) 14. Process Design for Dataio/O, PAC-DS ( ) 15. Process Design for Local Access, PAC-DS ( ) 16. Process Design for Remote Access, PAC-DS-07-01( ) 17. Process Design for GUI RawData, PAC-DS Process Design for GUI BasePosition, PAC-DS Process Design for GUI Speed, PAC-DS Process Design for GUI GPSstatus, PAC-DS Process Design for GUI QC, PAC-DS Process Design for GUI Inclination, PAC-DS Process Design for SimulateData, PAC-DS IPC Design for NaviPac, PAC-DS-14-01( ) 25. Design of Common functions in NaviPac, PAC-DS-17-01( ) 26. NaviPac NT Design of Data acquisition program (kup 1997) 27. NaviPac NT logging Utillity (Logdata.doc), kup Users Guide to NaviPac Online, eiva Users Guide to NaviPac Set-up, eiva Users Guide to Helmsmans Display, Eiva Special EIVA Controls, fdj Process Design for SimulateData, PAC-DS Objeckt orienteret Analyse & Design, Andreas Munk m.fl. 34. UML Distiled, Martin Fowler, Addison-Wesley Object Oriented Modeling and Design, James Rumbaugh m.fl.m, Prentice Hall Rational Rose UML dokumenter fra 19 April, 2012 Page 8 of 36

9 2. General Description of NaviPac In this chapter the overall design of the NaviPac system will be described. The DFD diagrams are created using a CASE tool called Visual Analyst and the development model used follows Yourdon/DeMarco with the real time extension described by Ward & Mellor [7]. Rational Rose using the UML notation creates the class diagrams. 2.1 DFD Diagram object Types In the following the different objects on the DFD charts will be described briefly. Data flows are continuous lines between a pair of symbols (process, interface, and store) that is terminated at one or both ends by one or two arrowheads. The arrows on the data flow indicate the direction of the data. Squared boxes illustrate external entity (Terminator). It portrays physical devices, users or other systems outside the scope of the NaviPac system and provides information used by NaviPac or uses information produced by the system (e.g. a user). The circles illustrate data processes. It transforms input data into output data flows. The process name and level number is placed inside the symbol. Dotted circles illustrate a control transform. Control transforms are used to transform input control flows into output control flows - no processing of data take place. (Typically decomposed in a state -transition diagram, structured decision tables or processes activation table). NB: not used in this document. Two parallel lines illustrate a store (e.g. file, database, buffer or data structure). A control flow is illustrated as a broken, continuous line between a pair of symbols. They are typically used to illustrate events with or without data (e.g. start/stop of a process). A box illustrates interfaces on a chart. Interfaces are used on lower level data flow diagrams to avoid the Terminator s occur more than once (on the Context diagram). 2.2 Program Environment In this section the environment that the NaviPac system is a part of will be described. The NaviPac system consists of several (>16) NT processes. In addition a number of utility programs is included in the system SW. In Figure 2 Processes & DBs in NaviPac system on the NaviPac system environment is illustrated. Here all the above mentioned a single process substitutes processes: NaviPac. 19 April, 2012 Page 9 of 36

10 Figure 1 Context diagram for NaviPac By doing so we simplify the interfaces to NaviPac a lot - at least at this initial level of the design NaviPac <-> Instruments NaviPac interfaces to a lot of different navigation instruments. Instruments are the entity that symbols the different instruments connected to the NaviPac system. E.g. Surface navigation, Gyro, Speed Log, Trackpoint II, Radar etc. These instruments will have various set-up commands/ data to function properly. Figure 2 this is named instrument-set-up. NaviPac receive instrument-data from the instruments, as soon new data is ready. E.g. when new data from satellites have been collected/computed in the GPS receiver it will send instrument-data to NaviPac NaviPac <->NaviScan NaviPac can send position-data to NaviScan. This is currently done by a special outputs send on serial port or UDP/IP ports NaviPac <->Datafiles NaviPac can log data in different formats (gen-logdata, custom-logdata, and surveydata). NaviPac can also generate runline-data files for survey tasks. 19 April, 2012 Page 10 of 36

11 2.2.4 NaviPac <->Printer NaviPac can in generate and print events to a printer/plotter. Also lots of views, set-up info. can be printed/plotted NaviPac <-> User The User entity identify users like Navigation officer, a surveyor, the helmsman etc. which are the daily user s of NaviPac. The User s can send user-commands to NaviPac and NaviPac can respond with user-data. The users interface (GUI) in NaviPac is implemented as a number of Windows NT Windows applications. User-commands are menu selections, keyboard events, mouse events and data entered in one of the GUI s. User-data is data from the NaviPac system that will be presented for the user in one of the GUI s. 19 April, 2012 Page 11 of 36

12 3. Description of NaviPac Processes In this chapter the NaviPac process from figure Figure 1will be decomposed. The result in the level 1 DFD (Data Flow Diagram) below: instrument-data surveydata customlogdata genlogdata siminstrument-data 5 SimulateData 7 NaviPac Setup D2 D4 13 GPSmonitor 1 DATAI/O (RT) Setup DB Object DB raw-data setup-data D3 RawData 2 16 Kernel OnlineDB setup-data object-data access-data alarm-info online-setup 3 RemoteAccess 15 LocalAccess usbl-data 4 NaviPac Online log-data 9 Helmsman attitude-data 8 LogData 12 DataAcq 17 USBLCalibrate objpos-data qc-data basepos-data gps-status-data objpos-data runline-data setupdata 11 Attitudes 10 ObjectPos 19 QC 6 BasePosition 14 GPSstatus 18 Catenary user-data runline-files XYZ-log-files Custom-log-files Generel-log-files userdata instrumentsetup helmsmandata usercommands onlinesetup userdata kerneldata accessdata onlinedata dataacqdata rawdata instrumentsetup positiondata usercommands usercommands setupdata userdata userdata userdata userdata userdata userdata outpportdata objectdata instrumentdata runlinedata kernelcommands userdata Figure 2 Processes & DBs in NaviPac system The diagram shows the number of different processes that can/will are running on one or more NT computers. The different processes are described briefly here and more detailed in several process design documents. Refer to references [11]-[23]. The GUI processes 6,7, -14, 16 can all be started from NaviPac Online (process 4) by selecting a menu item or toolbar button. They will have their own windows which can be minimised etc. Furthermore they can be started on a number of networked workstations if needed. 19 April, 2012 Page 12 of 36

13 This require however that process 1 (Dataio), 2 (Kernel), 3 (RemoteAccess), 15 (LocalAccess) have been started on the computer where the instruments are connected. These can be started manual or restarted (if OnlineDB is OK) from 7 (NaviPac Set-up). 7 calls a program named StartNaviPac to get all wanted processes started. If the Local Access or RemoteAccess is not started OK all GUI s will however not be allowed to start and terminate immediately. If a User activates the restart operation from NaviPac Online all GUI processes will be stopped. This implies that remote users have to start their processes manually again in case of a restart. In the next chapters the subsection number refer to the process number in Figure Dataio/O Dataio/O is a real time process (RTP) that time stamps all received data packets. It will get the highest priority in the Real Time process hierarchy. This can be handled by the operating system as it supports real time processes (setting prio. to highest level). It will be the only one RT process in the NaviPac system. The Data I/O process takes care of data input and output to a number of navigation. Relationships between this and other processes are shown in Figure 2 Processes & DBs in NaviPac system. Dataio/O is the process that interfaces all the instruments in NaviPac. The process can read set-up-data from the SetupDB for all connected instruments. Also it can read port-set-up from this store and set-up the ports on which the instruments are connected with this default setting. Dataio/O read continuous data (instrument-data) from the and send it to the buffer called RawDataDB. It can notify the Kernel process when data is ready in RawDataDB. The module is also able to determine if the a user wants to run with simulated instrument data. If he has set-up one or more instruments to run simulated in NaviPac Set-up it can be determined from the SetupDB. The data (sim-instrument-data) will be treated like normal instrument-data. If some instruments are simulated and the Simulate Data process is not started it will be started by this process. If RawData is started Dataio/O also deliver raw-data from instruments to this utility process. 3.2 Kernel Kernel is as the name indicates the heart of the NaviPac system. The Kernel part performs all the data computation, make system error check etc. A QC part checks data from all sensors to verify that the data received is not corrupted (continuous). Data correctness is checked by Checksum, Kalman filtering and continuous 19 April, 2012 Page 13 of 36

14 averaging. Missing data and erroneous data result in system alarms (alarm-info) to the online process. Furthermore it can be logged locally in a file log. The NaviPac Kernel process handles all navigation in NaviPac, i.e. interpretation of raw instrument data, computation of reference position, sensor errors, remote positions, sub-sea positions and DAL/DOL information. Furthermore it handles events generation, filtering and prediction, data-distribution and automatically kernel parameter adjustments. The NaviPac Kernel process will be implemented following the principles used in the current NaviPac BASIC version. Kernel read the general set-up for NaviPac from the SetupDB and online set-up from the OnlineDB. The data (raw-data) from the connected instruments (via Dataio/O) will be read from a store called: RawDataDB. This will be a buffer between the Dataio/O process and the Kernel. Dataio will signal Kernel when new data is available. Data to GUI processes (like Nav. positions) will be sent to the KernelDataDB which LocalAccess or RemoteAccess processes will read and distribute the data access-data) to the processes which have requested data. The Kernel will be started and stopped from the NaviPac Set-up process. 3.3 Remote Access Remote Access is an interface process that handles a lot of the communication to and from the NaviPac system. It can receive data requests commands from Helmsman, LogData and Dataacq and following deliver data (helmsman-data, log-data, and dataacq-data) to the processes. It handles all output to external instruments, as it s controlled by the kernel cycle. RemoteAccess read data (access-data) computed in Kernel from a peace of shared memory and in every cycle deliver data that has been requested. Note: LocalAccess and RemoteAccess are both distributing data to other processes and could in fact have been one process. However for CPU load it was decided to make 2 processes. 3.4 NaviPac Online The NaviPac Online process allows the operator to present navigation data by connecting to LocalAccess and to change navigation set-up and to perform various navigation actions. NaviPac Online can be started in several incarnations to allow more than one user to use/view the navigation data. NaviPac Online communicates with Kernel and LocalAccess. 19 April, 2012 Page 14 of 36

15 NaviPac Online is the process that all most NaviPac users normally will use to request and view on various navigation data. Also online-set-up of the system can be edited/changed by the user. The online-set-up will be validated and if OK saved in the OnlineDB. User-data is answers and input data concerning the set-up replies/orders between the user and the process. Users can of course also activate a lot of other commands and get replies from the process in the form of user-data. NaviPac Online connects to Local Access and request different online-data from the Kernel. Local Access on the other hand can route online-data from the Kernel to (one or more) NaviPac Online processes new position info. Also communication with the Remote Access process take place. The user can request log-data through the Remote Access process and get the replies (log-data) when data has been received in the Remote Access process and from there sent to NaviPac Online. NaviPac Online also communicates directly with the Kernel process. E.g. when some QC-parameters was changed and the Kernel should be notified through the kernelcommands message. NaviPac Online reads / writes process-info in the ProcessInfoDB (not shown). This is a little database that keeps track of running NaviPac processes. E.g. NaviPac Set-up will lookup which processes that should be stopped as it has the functionality to restart the NaviPac processes. 3.5 SimulateData SimulateData is a GUI process that can make simulations of instrument-data that can be used by the Dataio/O process in case of missing physical instruments. It will e.g. be used in test situations to the NaviPac system. The user can enter the speed components for the ship and also the ships reference position. The process is able to receive set-up for the simulated instruments (see siminstrument-data in Figure 2) and can send sim-instrument-data to the Dataio/O process. It will be started from the Dataio/O process. Refer to [24] for a detailed description. 3.6 Base Position BasePosition is a GUI process that can be started from the NaviPac Online process and is used to display base positions for all LOP s included in the position calculation. Data for these LOP s are received as basepos-data from the Local Access process. As it is a GUI process it must be able to receive user-commands (including keys, mouse events) and also display the basepos-data (named: user-data). 19 April, 2012 Page 15 of 36

16 The detailed design can be found in the document: [18] 3.7 NaviPac Set-up The NaviPac Set-up process allow the users (normally privileged) to view and/or edit all set-up parameters stored in the SetupDB. NaviPac Set-up is used by the user to set-up the NaviPac system with the preferred instruments, ellipsoid, projection, datum shift etc. The set-up entered by this user (user-commands) will be interpreted by the process and if validated OK - stored in a database named SetupDB as user-set-up. The process can be started from the NaviPac Online process but NaviPac Set-up can also start the NaviPac Online process. The NaviPac Setup process can either be started from an icon in the main window on the navigation computer or from start menu. After start, the process reads the contents of the set-up database (SetupDB) and creates local structures containing the exact information. If all this turns out OK the user can redefine the set-up. If some instruments are set to ON and no dongle is present the navigation start/restart is disabled. The process generates messages containing current data/time, last date/time for change etc. and displays these messages in the message window. 3.8 LogData LogData is a GUI process that can be started from the NaviPac Online process and is used to select and log positions and other instrument data calculated in NaviPac. Output from LogData is logging info. (Custom-logdata or gen-logdata) that will be stored in log files. LogData receive log-data from the RemoteAccess process. As it is a GUI process it must be able to receive user-commands (including keys, mouse events) and also display the log-data in the main window. 3.9 Helmsman Helmsman is a GUI process that can be started from the NaviPac Online process (or start menu) and is used as the graphical fromtent for a surveyer/helmsman. Runlines can be created (see run-data/runline-files in Figure 2) and displayed. Also background charts, waipoints a.o. can be displayed/created ObjPos ObjPos is a GUI process that can be started from the NaviPac Online process and is used to display object positions for all objects included in NaviPac online. E.g. 19 April, 2012 Page 16 of 36

17 dynamic positions (ROVs, fish.) and some internal calculated object positions like position of a echo sounder. Data for these objects are received as objpos-data from the Local Access process. As it is a GUI process it must be able to receive user-commands (including keys, mouse events) and also display the objpos-data (named: user-data) Attitudes This process handles the display of heading-data and roll-pitch-data. Inclination is a GUI process that can be started from the NaviPac Online process (or from an icon) and is used to display the various information on the gyro (headingdata) and roll & pitch. I.e. raw gyro and course made good and the roll and pitch information from the connected Roll&Pitch system. Refer to the section. As it is a GUI process it must be able to receive user-commands (including menu selections, keys, mouse events) and the other way around display the roll-pitch-data and heading-data (named user-data) in related fields. The detailed description of the process can be found in [23] DataAcq Dataacq is a GUI process that can be started from the NaviPac Online process and is used to display value/time graphs for all data acquisition instruments included in NaviPac Set-up. Data for these data acquisition instruments are received as dataacq-data from the RemoteAccess process GPSmonitor GPSmonitor is a GUI process that can be started from the NaviPac Online process and is used to control and display GPS instruments included in NaviPac Set-up. Gps systems can receive instrument-setup to setup the gps and instrument-data can be displayed (e.g. time, position and height information from the receivers) GPS status GPSstatus is a GUI process that can be started from the NaviPac Online process and is used to display status information from the GPS systems in use. e.g. mode, hdop and number of satellites. GPS status information for this window is received as gps-status-data from the LocalAccess process. As it is a GUI process it must be able to receive user-commands (including menu selections, keys, mouse events) and the other way around display the gps-status-data in related fields (user-data). 19 April, 2012 Page 17 of 36

18 3.15 Local Access The LocalAccess process is a process that takes care of the data distribution from the Kernel and a number of NaviPac GUI processes that needs some data for displaying purposes. As shown in Figure 2 Local Access distribute access-data data to the following processes: online-data to NaviPac Online attitude-data to Attitudes basepos-data to BasePosition objpos-data to ObjPos and Catenary. qc-data to QC gps-status-data to GPS Status Local Access can find the destination process for a given data type by looking up in an internal process table. LocalAccess is started by NaviPac Set-up when the NaviPac system is started See Start. Note: LocalAccess and RemoteAccess are both distributing data to other processes and could in fact have been one process. However for CPU load it was decided to make 2 processes RawData RawData is a GUI process with a GUI interface that can be started from the NaviPac Online process from the view menu (or toolbar) and is used to display raw data from the instruments. The raw data is sent from the DataI/O process as raw-data and will be displayed in a special Window as raw-data. The user can select various parameters (user-commands) of which information to display and get information from the process like field values etc. as user-data. The RawData Process (16) is a GUI process that has the following main functionality: Display of raw instrument data (Read directly from DispRawDataDB buffer - shared memory). Display of interpreted-data from the Kernel process. Temporary control of different port setting (set-up-data to Dataio/O process) NOTE: If a user changes the port set-up it will not be saved in the SetupDB. Only set-up change by the NaviPac Set-up process will be saved permanently. 19 April, 2012 Page 18 of 36

19 The RawData GUI process can like the other GUI processes receive data (here interpreted-data) from the LocalAccess process. Furthermore it reads disp-raw-data in the DispRawDataDB (shared memory area that is updated by Dataio/O) and present it for the user in different forms/widgets. Also change of set-up of instrument interface parameters can be done from the GUI process. It will notify LocalAccess when it is stopped. It can be started from NaviPac Online (start-process-message from NaviPac Online). Also it will have the possibility to print the screen fields on a system Printer. Note: There can be more instances of the RawData process. The OS-kernel will give them different process id and DataI/O will be able to distribute the same data sets (interpreted-data) to all incarnations of the RawData process USBL Calibration The USBL Calibration program is a client network application that is a part of the NaviPac NT SW package. It can be started from in the online program. It get usbldata from DataI/O via a TCP-ip connection. It can calculate, display and store correction values for USBL objects Catenary The Catenary calculations program is a client network application that is a part of the NaviPac NT SW package. It can be started from in the online program's View menu: Catenary calculations or the toolbar s icon: It is used to calculate catenaries (curves) when laying cables, pipelines etc. It gets objpos-data from the Local Access process QC QC is a GUI process that can be started from the NaviPac Online process and is used to display QC related data for the navigation systems including error ellipse, STD deviation and range fluctuation. The user can select various parameters (user-commands) of which information to display and get information from the process like field values etc. as user-data. The user interface is described in [4]. QC Data for these objects is received as qc-data from the Local Access process. As it is a GUI process it must be able to receive user-commands (including keys, mouse events) and the other way around display the qc-data. The detailed description of the process can be found in [22]. 19 April, 2012 Page 19 of 36

20 4. Inter Process Communication (IPC) As mentioned in the above section a lot of data is exchanged between the NaviPac processes. This section will highlight which IPC methods we will use to implement the communication requirement. The detailed design of IPC is described in [25]. Shared memory: will be used as communication methods between the Dataio/O process and the Kernel and the RawData process. Refer to RawDataDB and DispRawDataDB in Level 1: DFD of NaviPac system. On page 7. Also between the Kernel and LocalAccess and RemoteAccess we have decided to used shared memory. It have been chosen on these places because that it is the fasted method and also Dataio/O don t have to wait until another receiver process is ready - it just write to a piece of memory and continue its work. One or more semaphore will be used in conjunction with shared memory - see below. Semaphore: used to synchronise e.g. shared memory operations where needed. TCP/IP Sockets: used as the communication media between RemoteAccess, LocalAccess and the GUI s. Named Pipes: used to transfer small messages between non-time critical processes on the same workstation. We will e.g. use named pipes between Kernel and Dataio/O. 5. Timing principles in NaviPac. This section defines the basic time tagging implementation in NaviPac. Please refer to the manual section 16: 16_Timing Principles in NaviPac.docx for updated version. 5.1 Fundamentals NaviPac has a dedicated process to handle all data collection and time tagging. The process is kept as simple as possible, as it s executes on the NT real time queue. For each port in use, the process creates a NT thread (i.e. a process) to handle the communication. Each thread reads data from port, collect it into packets and store data and time in a dedicated buffer area. The main process controls the navigation cycle, as it with user determined frequency: 1. Tell all thread to use new buffer area 2. Store header information into the buffer 3. Tells the kernel to start processing using the buffer area. 19 April, 2012 Page 20 of 36

21 4. Waits until next cycle. This gives a minimal load of the real-time process, and secures an optimal time tagging of the incoming data. 5.2 Ordinary Timing See also more up-to-date information in dedicated document. To secure the best timing, the thread should interrupt on first character in an incoming string, register time and read the entire string. This will give a high load of the system, and with many high-frequency sensors, the load would kill the NT system, as NT doesn t give any intelligent handles to that. Instead we have found a smarter and much more efficient way to handle interrupts. We set-up an interrupt on the last character in the string (most often <LF>). When <LF> occur on the port, we get an interrupt and register time (t0). Then we read the entire string. Based on the length of the string, we calculate total transmission time dt as DataBits StopBits Parity? TimePerChar BaudRate Length times TimePerChar: E.g. on a 9600-Baud line with N81, we use seconds per char. A typical GPS string like $GPGGA, , ,N, ,E,2,5,04,112,M,0,M,0.0,1234<CR><LF> with 69 characters will be transmitted on seconds. The time for the message is now t0 dt. 5.3 Timing supported by external information GPS navigation systems are based on a series of data calculation, before the information is sent on the port. To obtain that latency, we have the following methods. 5.4 Latency in string Ashtech has extended the GGA string, as they use the age field to two things: The part before decimal point is age of correction Part after decimal is age of position E.g defines that correction from base is 1 second old and the position was valid 0.73 seconds ago. 19 April, 2012 Page 21 of 36

22 Problem: Will only work for latency up to 0.99 seconds. 5.5 Using ordinary $..ZDA information To improve timing, the information in NMEA string might be combined with a ZDA message. Assumption: The ZDA message is output exactly when the GPS clock is what the string says, e.g. $GPZDA, is send when the GPS clock is 12:23: NaviPac now uses the timing of ZDA message to calculate age of the GGA string (by comparing the two time fields). Example: If UseZDA is on, the port library saves the last 20 ZDA messages, which are timed normally (reception of first byte or PPS - PPS is perhaps not ideal!). When another (i.e. GGA) messages is received, the library finds the time from that string (hhmmss.ss), and looks up in the table of ZDA messages for find the corresponding time. This time will hereafter be assigned to the GGA message. 1. A message is completed - local time stamp T0 2. if ZDA message - store message and T0 in table 3. if GGA, find hhmmss.ss and find corresponding time in ZDA table. If found assign it to the GGA message. (E.g. Leica) 4. If not found - interpolate to get more exact time. (E.g. Trimble) 5. Distribute time in ordinary format. 5.6 Using Ashtech $PASHR - FUTURE Ashtech has a special output with timing information ($PASHR,PPS,<seconds of week><cr><lf>), where seconds of week gives the GPS clock measured in seconds since Sunday current week. The signal is sent exactly when the time is valid, and can therefore be used to calculate age of any other NMEA message. The seconds of week must be compensated for difference between GPS time and UTC (pt. 11 seconds) and normalised to one day. Hereafter the principle will be identical to ZDA method. 5.7 Using Trimble UTC message Trimble uses a special UTC message UTC yy.mm.dd hh:mm:ss <fix> <satellites><cr><lf>. The message is outputted approximately 0.5 second before the time is valid! 19 April, 2012 Page 22 of 36

23 This message is sent on a separate port, and therefore NaviPac has a dedicated UTC time input (Data Input). The message can be collected and stored in the general logging as any other instrument. In Online Date&Time, the operator can select the UTC input for time-sync (as any ordinary GPS message). If selected for time-sync, the PC clock will be adjusted will be adjusted with the UTC clock with user defined frequency. For the ordinary Trimble input, the operator can select Use Time in string (station set-up), which defines that the position shall be time-stamped by the time in the string (hh:mm:ss) and not by the ordinary principles. Timing of the UTC string can be stand-alone or combined with PPS (See also ). Stand-alone: Each time a UTC message is received (time stamp T0), the resulting time stamp is defined as Tvalid = t0+0.5 PPS: The port library must perform the following cycle: 1) Read UTC string 2) Wait for PPS 3) When PPS occur, the corresponding time (Tvalid) is applied to the UTC string. 5.8 Implementation of PPS We have made a flag on each GPS port, where the operator can select if timing must be performed on basis of incoming data (ordinary) or on data valid flag (PPS). The cable from GPS to NaviPac must be designed to handle data and pulse in one 5.9 GPS -> NaviPac Cable specification GPS Digiboard/COM port (D-Sub 25 female) TxD (RxD) Gnd (Gnd) PPS Coax Shield PPS Coax center (Gnd) 22 (RI) To test the cable you can connect the GPS to the Digiboard with the cable, then start the Set-up program. In the set-up program select Test COM ports 19 April, 2012 Page 23 of 36

24 from the bottom of the Options menu and select the port in use, the raw input window should now display the following. <Ring> $GPGGA,. <Ring> $GPGGA,. <Ring> $GPGGA,. <Ring> $GPGGA,. <Ring> <Ring > can occur more times for each string, as a PPS has a certain width (for Ashtech Z12 app. 2ms), which might result in more interrupts. NaviPac will hereafter time-stamp the signal after PPS and not after reception of first byte. This is implemented on the basis of reception of one PPS followed by 0 or more strings per second. All messages after a PPS will be time-tagged with the PPS time. Problem: What if the delay is bigger than 1 second is (e.g. old Leica with > 2 seconds). In this case we cannot use PPS as stand alone (see ZDA). We have made a minor solution to handle close-to-one-second solutions: Let tmin determine an absolute minimum GPS calculation time, i.e. the fastest possible output!. If NaviPac receives a data set from the GPS and calculate the difference between reception time (T_now - transmit-tid) and the latest PPS, then the result must be bigger than tmin. If not, use last PPS. In current version, this will be set to 120 ms. Solution: Here we must combine PPS and system specific details e.g. Trimble UTC. First of all the UTC is timed using PPS. As we use the previous pulse, the UTC must be tagged as Tpps plus 1. When as normal position update is received, we use the UTC time tagging information to find exact age of the string. 6. Important Messages /Events between processes. In this section the events and commands that is exchanged between processes in NaviPac is described. 6.1 Start Processes are started by system calls in NaviPac NT. Depending on the situation calls like: System, ShellExecute & CreateProcess are used. 19 April, 2012 Page 24 of 36

25 6.2 Stop NaviPac is normally stopped from the Set-up program which call StopNaviPac.exe, which uses a process information database (EIVAHOME/DB/procinf.DB.txt), to lookup, which programs to stop. 6.3 Snapshot of messages between Online and Kernel THE FOLLOWING TCP/IP MESSAGES CAN BE SENT /RECEIVED BETWEEN ONLINE/KERNEL: TerminationOnline, SetEstimatedPosition, SetTimeController, SetLOPParameters, SetUSBLParameters, SetNavigationMode, ChangePriorityGroup, ChangeLOPSelection, ActivateRangeCalibration, DeActivateRangeCalibration, ActivatePositionCalibration, DeActivatePositionCalibration, DistributeAlarm, ReReadEvents SetDiveNo SetFixedOffset RequestUSBLData ContinousUSBLData CancelUSBLData 6.4 Messages between Local-Access and GUI s THE FOLLOWING TCP/IP MESSAGES CAN BE SENT /RECEIVED BETWEEN LOCALACCESS AND THE GUI PROCESSES: Online, QC, BasePos, ObjPos, GPSstatus, Attitudes, Catenary ONLINE_MAIN_WINDOW_DATA (se online-data) ONLINE_POS_FORMAT_CMD (position format data message to Online) ONLINE_DEAD_RECKONING_DATA (se online-data) ONLINE_SEMI_AUTO_LASER_NAV_DATA (se online-data) ONLINE_MANUAL_NAVIGATION_DATA (se online-data) ONLINE_RANGE_CALIBRATION_DATA (se online-data) ONLINE_POS_CALIBRATION_DATA (se online-data) ONLINE_BASE_LINE_CALIBRATION_DATA (se online-data) BASEPOS_LOP_DATA (se basepos-data) INCLINA_MAIN_DATA (se attitude-data) SPEED_MAIN_DATA (se attitude-data) 19 April, 2012 Page 25 of 36

26 GPSSTAT_MAIN_DATA (se gps-status-data) QCDISP_MAIN_DATA (se qc-data) OBJECT_MAIN_DATA (se objpos-data) 6.5 Messages between Remote-Access, LogData & DataAcq THE FOLLOWING TCP/IP MESSAGES CAN BE SENT /RECEIVED BETWEEN REMOTE- ACCESS, LOGDATA AND DATAACQ. DataAcq use the messages to order data etc. CMD_LD_GET_ALL_LOG_DATA = 1,/* All Logging data: Continuous flow */ CMD_LD_GET_LOG_DATA, /* Survey data: Continuous flow */ CMD_LD_START_LOG, /* Start logging now! */ CMD_LD_STOP_LOG, /* Stop logging now */ CMD_DA_ACQUSITION_ONLY, /* Send data acquisition only */ CMD_DA_SET_PARM, /* Set parameters */ /* REMACC -> LOGDATA */ CMD_RA_EVENT_REC = 10, /* Event Record */ CMD_RA_POSITION_REC, CMD_RA_ATTITUDE_REC, CMD_RA_DATA_REC, CMD_RA_GYRO_REC, CMD_RA_RAW_REC, CMD_RA_VELOCITY_REC, CMD_RA_START_LOG = 20, /* Start logging now! */ CMD_RA_STOP_LOG, /* Stop logging now */ CMD_RA_START_CYCLE, /* Start new cycle */ CMD_RA_STOP_CYCLE /* All data from this cycle transmitted */ 6.6 Messages between Remote-Access and Helmsman THE FOLLOWING TCP/IP MESSAGES CAN BE SENT /RECEIVED BETWEEN REMOTEACCESS AND HELMSMAN FOR DETAILS AND MOST RECENT STATUS PLEASE REFER TO HKINTERF.H /* KERNEL -> HELMSMAN */ CMD_KH_NEW_ORD_DATA = 1, // POSITIONING DATA: CONTINUOUS FLOW CMD_KH_UPDATE, // END OF NEW CYCLE TIME - DO UPDATE CMD_KH_ID_ADD_DATA, // OPTIONAL: DATA ACQUISITION CMD_KH_RAW_DATA, // DYNAMICAL RAW DATA CMD_KH_EVENT, // EVENT DATA CMD_KH_REINIT, // (RE)INIT INTERNAL HD DATABASES CMD_KH_REINIT_OBJECT, // (RE)INIT INTERNAL HD OBJECT CMD_KH_REMOVE_OBJECT, // REMOVE INTERNAL HD OBJECT CMD_KH_REQUEST_ARC, // REQUEST ARC SEGMENT FOR AUTOPILOT /* HELMSMAN -> KERNEL (AND SLAVE HELMSMANS) */ CMD_HK_NEW_LINE_DATA = 20, // LINE DATA: CONTINUOUS FLOW CMD_HK_SIDEBOAT_RUNLINE, // SIDEBOAT RUNLINE (SEGMENT) DATA CMD_HK_ARC_ACK, // ARC SEGMENT ACKNOWLEDGED 19 April, 2012 Page 26 of 36

27 CMD_HK_START_ARC, // REQUESTED ARC SEGMENT STARTED CMD_HK_ARC_PREWARNING, // 1 MIN PREWARNING FOR ARC SEGMENT CMD_HK_START_RUNLINE, // START OF SURVEY ON RUNLINE CMD_HK_STOP_RUNLINE, // STOP SURVEY RUNLINE CMD_HK_STOP_ARC, // REQUESTED ARC SEGMENT STOPPED CMD_HH_NEW_RUNLINE = 40, // LOAD NEW/CURRENT RUNLINE FILE CMD_HH_LOAD_RUNLINE, // (RE)LOAD ALL RUNLINE FILE(S) CMD_HH_START_SEGMENT, // START OF SURVEY ON SEGMENT CMD_HH_STOP_SEGMENT, // STOP SURVEY SEGMENT CMD_HH_INVERT_RUNLINE, // NEW STATUS OF RUNLINE INVERT CMD_HH_REMOVE_RUNLINE, // REMOVE RUNLINE FILE CMD_HH_SYNCHRONIZE_START = 100, // START SYNCHRONIZING CMD_HH_SYNCHRONIZE_STOP, // STOP SYNCHRONIZING CMD_HH_LOAD_DISPLAYLINE = 150, // LOAD DISPLAYLINE CMD_HH_LOAD_WAYPOINT, // LOAD WAYPOINT CMD_HH_LOAD_TARGET, // LOAD TARGET CMD_HH_LOAD_DXF, // LOAD DXF BACKGROUND FILE CMD_HH_LOAD_DX90 // LOAD DX90/ECDIS FILE 19 April, 2012 Page 27 of 36

28 7. Common Data Structures (Stores) This chapter describes the common data structures for the NaviPac system. Common data structures are those used in several places in NaviPac. The following data stores can be found: RawDataDB, DispRawDataDB, KernelDataDB, RemoteDataDB, GeneralSetupDB, and OnlineDB. Note: For simplicity these are not all outlined in Figure RawDataDB RawDataDB is a buffer between the Dataio/O (real time) process and the Kernel. The purpose of this buffer is to secure that the Dataio/O process can always deliver its instrument-data (output as raw-data) to the Kernel. That means Dataio/O write to the buffer and Kernel will read from the buffer. It will be implemented using shared memory and semaphore. See [25] for a detailed description. 7.2 DispRawDataDB RawDataDB is a buffer between the Dataio/O (real time) process and the RawData process. The purpose of this buffer is to secure that the Dataio/O process can always deliver disp-raw-data to the RawData GUI process. That means Dataio/O write to the buffer and RawData will read from the buffer. It will be implemented using shared memory and semaphore. See [25] for a detailed description. 7.3 KernelDataDB KernelDataDB is a buffer between the Kernel process and the LocalAccess process. The purpose of this buffer is to secure that the Kernel process can always deliver kernel-data to the GUI processes. That means Kernel write to the buffer and LocalAccess will read from the buffer. It will be implemented using shared memory and semaphore. See [25] for a detailed description. 7.4 RemoteDataDB RemoteDataDB is a buffer between the Kernel process and the RemoteAccess process. The purpose of this buffer is to secure that the Kernel process can always deliver access-data to the RemoteAccess process and thereby to the rest of the NaviPac processes. It will be implemented using shared memory and semaphore. See [25] for a detailed description. 19 April, 2012 Page 28 of 36

29 7.5 GeneralSetupDB SetupDB is a database (binary record based file) that holds all general set-up for the NaviPac system. E.g. which instruments are connected, which projection and ellipsoid are used, which instruments is currently in use and their current setting like port number, baud rate, databits etc The set-up information (set-up-data) is stored in the database by the NaviPac Set-up process. The Dataio/O process read information to set-up the connected instruments (instrument-set-up) and the Kernel read. Online also read this DB in a manual start Example of GeneralSetupDB (in ASCII format) DB ascii dump: C:\EIVA\Db\gensetup.DB Date: :40 User: OKR UserId: 4 ProgId: Restart mode: enabled Systems: 8 Stations: 8 Instruments: Ellipsoid : WGS 84 Inv. flat.: Semi major: Projection: UTM (north) Proj. type: 05 Org. scale: Parallel: '0.0000" 2.Parallel: '0.0000" Longitude: '0.0000" Latitude: '0.0000" Easting: Northing: UTMzone: Datum Shift: WGS84 to ED87 (Northsea) to ED50 Method: None Tx : m Ty : m Tz : m Rx : Ry : Rz : PPM : If the resulting latitude is below 62 degree, use dedicated algorithm to get from ED87 to ED50. If the resulting latitude is above 65 degree, use dedicated 7-parameter transformation from ED87 to ED50: Tx = 1.51 m Ty = 0.84 m Tz = 3.50 m Rx = 1.893E-6 radians Ry = 6.870E-7 radians Rz = 2.764E-6 radians PPM = E-7 If the resulting latitude is between 62 and 65 degree, use a weighted average of the algorithm and the dedicated 7-parameter Selected data scale: Position: metric scale Unit m Depth: metric scale Unit m Logging: Pos 1 Depth Environmental data: Gravity : April, 2012 Page 29 of 36

30 Pressure Surf : Density Water : Sound velocity: Survey information: Area : Norway Client : EIVA a/s Job : Vessel : LB Height/geoidal data: Geoidal red. : Manual GPS H ->Offset: No Global parameters: Deskewing : Yes Filter Cycle freq. : 1.00 CMG/SMG Filt. : GPS setting : Use all and discard height if non RTK USBL Setting : Stacked Surface = Yes : Use time from HiPAP = Yes : Hold time = 7.00 sec : Tolerance = % Navigation Systems: 1: Ashtech GPS1: test 2: GPS1 (NMEA): LRTK GPS 3: Trimble : NY Trimble 4: Geodimeter ATS 3D: Minden 5: GPS2 (NMEA): N45 6: Trimble : T2 7: Leica Total 1 (R/B): L1 8: AGA Geodimeter: A Navigation Stations: 1:AGA Geodimeter-tsa avail: OK Position E: , N: , H: :Leica Total 1 (R/B)-ts avail: OK Position E: , N: , H: :Trimble t2 avail: OK, COe: 0.00, COn: 0.00, Use age/time: OK, Fixed age: 0.00, GeoH: 0.00, DatumS: None (0) 4:GPS2 (NMEA)-t1 avail: OK, COe: 0.00, COn: 0.00, Use age/time: OK, Fixed age: 0.00, GeoH: 0.00, DatumS: None (0) 5:Geodimeter ATS 3D-NY avail: OK Position E: , N: , H: :Trimble tt avail: OK, COe: 0.00, COn: 0.00, Use age/time: NO, Fixed age: 0.00, GeoH: 0.00, DatumS: None (0) 7:GPS1 (NMEA)-Some name avail: OK, COe: 0.00, COn: 0.00, Use age/time: NO, Fixed age: 0.00, GeoH: 27.40, DatumS: None (0) 8:Ashtech GPS1-st1 avail: OK, COe: 1.08, COn: 2.17, Use age/time: OK, Fixed age: 0.00, GeoH: , DatumS: None (0) Navigation Instruments: Surface Navigation : Trimble type: 24, seq: 0, Mode [Sim] Port 01 IO 9600 N 8 1 XYZ: Command to GPS: FALSE, Use PPS: FALSE, Use ZDA: FALSE, command file:gps024.gps 1: Ashtech GPS1 type: 42, seq: 0, Mode [Sim] Port 10 IO 9600 N 8 1 XYZ: Command to GPS: FALSE, Use PPS: FALSE, Use ZDA: FALSE, command file:gps042.gps Gyro : NMEA1 Gyro type: 104, seq: 0, Mode [Cal] Port 48 IO 9600 N 8 1 XYZ: CO: 0.000, Time Slice: 0.000, Offset: LB200, obj.no: 0 3: NMEA2 Gyro type: 105, seq: 0, Mode [Cal] Port 23 IO 9600 N 8 1 XYZ: CO: 0.000, Time Slice: 0.000, Offset: EIVA-2, obj.no: 7 19 April, 2012 Page 30 of 36

31 Dynamic positioning : HPR 410/HiPAP type: 496, seq: 0, Mode [Sim] Port 24 IO 9600 N 8 1 XYZ: EIVA-1, obj.no 1, type V, id 1, XYZ EIVA-2, obj.no 7, type d, id 2, XYZ EIVA-3, obj.no 16, type d, id 3, XYZ : Remote GPS 1 type: 498, seq: 0, Mode [Sim] Port 21 IO 9600 N 8 1 XYZ: drone1, obj.no Data Output : Depth to Trackpoint II type: 668, seq: 0, Mode [On ], IO Type: Ascii Offset=EIVA-1, obj.no: 1 Pos/Depth Scaling: No 7: Position to NaviBat type: 622, seq: 0, Mode [On ], IO Type: UDP/IP, port: 5000, IP addr: XYZ: Offset=LB200, obj.no: 0 Pos/Depth Scaling: No 8: Gyro and age to NaviBat/Scan type: 670, seq: 0, Mode [On ], IO Type: UDP/IP, port: 5001, IP addr: XYZ: Offset=LB200, obj.no: 0 Pos/Depth Scaling: No User Defined Offsets : offset1 type: 801, Mode [Off], XYZ: name=eiva, obj.no: 0, type=secondary Secondary object (0)= EIVA-1, X: , Y:0.000, Z: Secondary object (1)= EIVA-2, X: 5.000, Y:0.000, Z: Secondary object (2)= EIVA-3, X: 0.000, Y: , Z: : offset3 type: 803, Mode [Cal], XYZ: name=eiei, obj.no: 0, type=gyro Data Acquisition : Paroscientific, Inc. Digiquartz type: 704, seq: 0, Mode [Sim] Port 31 IO 9600 N 8 1 XYZ: Offset=EIVA-1, obj.no: 1, No. of channels=2 Name: EIVA1, channel=1, avail: OK, X: 0.000, Y:0.000, Z: Name: D-PRES, channel=2, avail: OK, X: 0.000, Y:0.000, Z: : Elac HS4300 type: 738, seq: 0, Mode [Sim] Port 34 IO 9600 N 8 1 XYZ: Offset=EIVA-2, obj.no: 7, No. of channels=3 Name: Depth-S, channel=1, avail: OK, X: 0.000, Y:0.000, Z: Name: Depth-P, channel=2, avail: OK, X: 0.000, Y:0.000, Z: Name: Depth-B, channel=3, avail: OK, X: 0.000, Y:0.000, Z: This information is saved in 'C:\EIVA\log\current.setup.txt' in ASCII format OnlineDB OnlineDB is a database (binary record based file) that holds all the Online general setup for the NaviPac system.. Only the NaviPac Online process can update this database. The Kernel will be notified when changes have been done and can read the new set-up in OnlineDB ( the kernel-commands dataflow - see Figure 2 ) Example of OnlineDB (in ASCII format) Contents of NaviPac online database (online.db) NaviPac NT -Eiva a/s: C:\source\onlineDB\onlineUtil\COnlneDB.cpp Jan :13:03 Summary: 1 priorities 6 LOP's 4 additional 0 objects Time controlled by 0 (Operator) Reference_prio_grp = 1 Estimated position Selected LOPs: April, 2012 Page 31 of 36

32 LOP 0 Station 1 Type 42 Ashtech GPS1 [Pos] Name Ashtech GPS1: test - st1(x) Instrum 0 W,S,C-O Prio co LOP 1 Station 1 Type 42 Ashtech GPS1 [Pos] Name Ashtech GPS1: test - st1(y) Instrum 0 W,S,C-O Prio co LOP 2 Station -11 Type 153 Anschutz NMEA 0183 [Add] Name Gyro: Anschutz NMEA 0183 Instrum 1 W,S,C-O Prio co LOP 3 Station -3 Type 276 TSS 332 [Add] Name Motion: TSS 332(Roll) Instrum 2 W,S,C-O Prio co LOP 4 Station -4 Type 276 TSS 332 [Add] Name Motion: TSS 332(Pitch) Instrum 2 W,S,C-O Prio co LOP 5 Station -5 Type 276 TSS 332 [Add] Name Motion: TSS 332(Heave) Instrum 2 W,S,C-O Prio co ObjectDB ObjectDB is a database that holds all the objects used in NaviPac. It is ASCII based with one line for each object. syntax: <objectnumber> <space> <objecttype> <space> <objectname)> Where <objectnumber>: <objecttype>: d: for dynamic objects (USBL Tranponders) V: for vessel objects (USBL Tranponders) o: for internal objects i: Free objects inserted when no TP is assigned in set-up/online - but data read O: User defined offsets 19 April, 2012 Page 32 of 36

33 <objectname>: max 40 characters (ended by a new line: <cr><lf>) <objectnumber>: 0-2: <objectnumber>: 3-8: <objectnumber>: 8-13: <objectnumber>: : <objectnumber>: 5xxx: <objectnumber>: 4xxx: <objectnumber>: 7xxx: V:Vessel objects d:dynamic objects o:internal objects O:user defined offset objects o:data input objects i:free objects o:echosounder (channel) objects Example of objects.txt V Vessel 1 V Remote 1 2 V Remote 2 3 d ROV1 4 d ROV2 6 d Sweep 5 d Towfish 7 d Diver 8 d Test fish 8 o Reson minewarning sonar 9 o Navican output position 10 o Filtered vessel position 11 o USBL reference 12 o Radar reference 13 o LBL reference 801 O Offset O Offset O Offset O Offset O Offset O Offset O Offset O Offset O Offset O Offset O Offset O Offset O Offset O Offset O Offset O OSPREY DP WAYPOINT 5041 O NMEA waypoint O NMEA waypoint o DESO25-1: o DESO25-2: o Simrad EA300P 7020 o NaviSound 2000: o NaviSound 2000: o NaviSound 2000: o Digiquartz: depth 7041 o Digiquartz: preasure 7050 o Simrad Bathy: o Ulvertech Bathy: o ELAZ LAZ 4700: i Free TP i Free TP ProcessInfoDB The ProcessInfoDB holds information all of the processes. It is used to secure that all processes will be stopped before a manual- or re-start of NaviPac. All processes write a note in the database when they are started or stopped. 19 April, 2012 Page 33 of 36

34 This note consist of: 1. Machine name (NOT USED for processes always running on navigation computer) 2. Process name 3. Process ID (from NT operating system) Example of ProcessInfoDB NOTUSED dataio 188 NOTUSED remacc 159 NOTUSED locacces 123 NOTUSED kernel 167 NOTUSED simdata 235 KURT online 162 EIVA AS 8361 KURT logdata 239 KURT helmsman Special calculations This chapter describes the various special calculations performed in NaviPac 8.1 Heave Correction When NaviPac is configured with RTK GPS and heave sensor, the system enables calculation of heave correction (HC), which a.o. can be used in NaviScan to establish a very accurate total height. The HC is in short term the difference between the GPS based height and the heave, and will allow the user to get rid of Heave bias due to long wavelength Tide And allow him to establish a normal zero measurement. The value is automatically calculated in NaviPac and can be send to external equipment using either Heave correction and GPS height or customer specified output. The description will be based on the following: 19 April, 2012 Page 34 of 36

35 The HC is now the difference between the height in the reference position and the heave in the reference position. The calculation is as follows: A raw height H is received from the GPS at time T H is compensated for geoidal separation (H1 = H GC) (either from fixed number or from geoidal file). H1 is compensated for offset to reference point. Href = H1 RollPitchCorrect(dX,dY,dZ) where roll/pitch is from time T Href is now the height of the reference point From the buffered input find Heave at time T. Calculate dheave as the remote heave caused by arm from reference point to Roll/Pitch sensor HeaveRef = Heave + dheave HC = HeaveRef Href This information will now be send to e.g. NaviScan together with a latency information (Tnow T) Depending of mounting of GPS vs. RPH sensor and quality of the two sensors, the accuracy of HC will be within a few centimetres. The data send over is raw i.e. no smoothing or filtering is applied! Before using it in e.g. NaviEdit, it s highly recommended that it is smoothed a bit. 8.2 RTK based Gyro Correction If NaviPac is configured with two RTK GPS systems and a ordinary gyro, we can offer a solution to Calculate a vessel gyro based on the two GPS RTK readings. If the two antennas are placed on a suitable long baseline, this can give an accuracy of a few 1/1000 degrees. Compare the measured gyro with the calculated RTK gyro and calculate a gyro correction. 19 April, 2012 Page 35 of 36

36 Output the gyro correction to NaviScan (as a part of the position string) and thereby improve the heading compensation in NaviScan. 8.3 Speed and geographical gyro correction Some older gyro s (compasses) may introduce an error due to vessel speed and the geographical location. Normally this is compensated inside the gyro by interfacing navigational data. If that s not the case, then NaviPac can calculate the correction via the standard formula: Fulst: Nautische Tafeln, 24. Aufl. heading in [deg] as acquired from gyro speed over ground 'sog' in [m/s] latitude in [deg] Result: Speed introduced error in degree. Must be added to observed value. Calculates error in gyro reading based on sailed speed, direction and actual location. error = asin (-((sog * cos (heading * Deg2Rad)) / ( * cos (latitude * Deg2Rad)))); The error can be transmitted to NaviScan and used in the online XYZ calculations (NaviScan, Contour and various converters). 19 April, 2012 Page 36 of 36