Can I open two webportal sessions simultanuously in order to work in one of them and view in the other?
       

Technically, yes. However, this is not recommended. There's a session timeout of 30 minutes which is applicable to all sessions of a user. If you do little in one of your sessions, this 30-minute timeout is quickly reached and you will be logged out of all your sessions. This means that you will be logged out of the session you are working in without notification, which might result in loss of unsaved work.

Rijkswaterstaat has permanently been testing the webportal with Microsoft Internet Explorer and Mozilla Firefox. Those two are currently officially supported. However, Internet Explorer is no longer recommended, due to evolving security concerns (see below). Most probably the webportal will work with every modern graphical web browser. More recently Rijkswaterstaat has tested with Google Chrome and no disqualifying issues have been found.
        
Note from Rijkswaterstaat IT department on Microsoft Internet Explorer
Microsoft no longer develops Internet Explorer. The default browser in Microsoft Windows environments is now Edge. Right now, Internet Explorer already lacks support for several security related technologies. It is to be expected that in the future Internet Explorer will lack support for more and more technologies (security and functional), some of which are required from a security point of view.
        
To avoid unnecessary risk to the user, it is recommended to abandon Microsoft Internet Explorer and use Mozilla Firefox or Google Chrome instead. Microsoft Edge Chromium is available sinds january 2020 and after brief tests the webportal appears to work correctly with Edge Chromium as well.

New versions of the webportal will be tested with Mozilla Firefox, Google Chrome and Microsoft Edge Chromium.

For new contracts Microsoft Internet Explorer wil no longer be supported.

The character sets do not work correctly with Microsoft Internet Explorer 11.3 on Windows 10. The use of Internet Explorer is no longer recommended, because Microsoft stopped developing this browser and it has security concerns. Please use Mozilla Firefox, Google Chrome or Microsoft Edge Chromium, instead.

The cause of this issue is not clear. It might be full cache memory.
If you change the language, but the language remains unchanged you can try to click several tabs as a workaround.

To calculate whether the sensors comply with the 60% or 25% rule, a number of parameters is required for an equation that checks whether the required condition is met. Below the equations for the individual rules:

• 60% hopper: [pinger_max_y] - [pinger_min_y] >= 0.6 *[length hopper]

• 60% ship: [draft-sensor_max_y] - [draft-sensor_min_y] >= 0.6 * [length ship]

• 25% hopper: [pinger_max_x] - [pinger_min_x] >= 0.25 * [width hopper]

• 25% ship: [draft-sensor_max_x] - [draft-sensor_min_x] >= 0.25 * [width ship]

Because from the calculation it is impossible to tell which of the parameters are wrong, all the parameters participating in the associated equation will be marked as incorrect if a rule is not met.

Check whether you entered the correct values. If so, please submit a comment to all fields associated with the specific rule. The red cross will then change into an orange exclamation mark and the configuration can be submitted.

To check whether the distance between sensor and propeller is sufficient, an equation is used. If the distance is insufficient, all parameters within this equation are marked as incorrect. These parameters are:

• y-position propeller,

• y-position draught sensor,

• propeller diameter.

Check whether you entered the correct values. If so, please submit a comment to all fields associated with this equation. The red cross will then change into an orange exclamation mark and the configuration can be submitted.

In earlier version of Edge and Internet Explorer (IE), you could not determine where a file you where viewing was temporarily stored. IE, for example, keeps those files in its Temporary Internet Files folder. Those temporary files are eventually removed, but you have no control over the period they remain in temporary storage.

The new Edge gives you more control about such files. You can specify which folder to use by default, but you can change to a different one. If most of your downloaded files fall into the category 'view and discard', specify (a folder within) your temporary folder as the default. That will usually be: C:\Users\{user}\AppData\Local\Temp.

After downloading the document, in Edge Chromium a bar appears at the bottom of the screen that displays an icon of the document. You can open the document by clicking on it.

The possible differences to be noted are:

By the user of the contractor:

• Difference between Board Application and Board Webportal

• Difference between Board Application and Shore Webportal

• Difference between Board Webportal and Shore Webportal

By the user of the client (not MSG):

• Difference between Shore Application and Shore Webportal

Causes:

• Ships that have not worked with MARS for a longer period of time.

• As soon as these ships start working with MARS again, an update must be installed.

• While releasing a release or patch.

• The MARS software on shore and on board the ships are released one after the other, with the ships being treated one by one according to a schedule.

• In the case of an update with a minor change.

• This will not be installed on all environments but initially e.g. only on shore or on a single ship for which this change is necessary.

• Only one of the two components (Application or Webportal) needed an update.

• In this case, the other component is not installed again. (just to change the version number)

If you have questions about differences in versions, you can read in the tab Release notes what the changes are, sometimes there is also a reason why there is a limited installation. For example, see version 2.3.7 (on request only) or version 2.3.6 (Webportal only)

If you still doubt whether you have the latest version, you can of course always contact the MARS Support Group at mars@rws.nl

-

-0-

A validation rule is constructed as follows:

On the left hand side of the validation rule the variable is given between brackets.

        example: [<variable>]

The variable consists of the field name preceded by the field number.

        example: [1.3.2:IP address (Eth0)]

After the right bracket follows the operator.

        example: [1.3.2:IP address (Eth0)]!=

To the right of the operator follows an expression or a number the operator needs to be compared to.

Some variables, such as values related to hopper sensors, are group variables. Those variables are used across fields. When used in a validation rule of a different field, group variables are not located between brackets but between curly braces.

In some configurations the tabs show red numbers that is because they were accepted before the new version was released. In the old release it was not possible to accept or disapprove of, and comment on the check mark "Not offered". This also applies to the check mark at question 4.1.16.1 Take hopper into account with determining empty ship. It was chosen not to interfere with configurations that had been accepted before the release of this new release. This was in the past also done with configurations that were accepted based on the output of the configuration tool when we switched to the web portal.

You will see red numbers (number of not accepted items) instead of a green zero (all items accepted) because the validation rules are not yet synchronized with the server on board of the ships.

If a configuration has been submitted and verified by the "MARS Support Group" an email will be sent to the person selected as a contact in the web portal. If the configuration was not submitted by this contact, still only the contact receives an email.

Only the contact can customize this by clicking the "Edit My Data" button" in "My Mars". After this, a window appears where you can make an adjustment in the upper part "Data of logged in organisation". There are two ways to do this:

1. Choose someone else from the list and make this person the contact for the web portal for your organisation. You will no longer be a contact! No email address needs to be entered, provided that one is linked to the chosen username.

2. Leave yourself as a contact but change the email address into:

1. The e-mail address of the person who normally creates the configurations,

2. A general email address of the company e.g. info@organisation.com. The applicant and/or contact person should be able to access this mailbox!

3. Choose a functional mailbox e.g. mars@organisation.com. The applicant and/or contact person should be able to access this mailbox!

You won't see sketches, help texts and validation rules on board because they are not yet synchronized to the server on board the ships.

The development of negative TDS can be caused by:

1. Inaccuracies in the provided data,

2. The operation of the system.

1. Inaccuracies in the provided data:

Possible sources of the occurrence of inaccuracies, including negative TDS, are very divers. Below are a number of them listed (not exhaustive):

Before receiving the data string in MARS:

• Measurement errors in the hopper sensors. (Can also be due to tolerance deviations within the standards set, see Regulations for MARS),

• Measurement errors in the draught sensors. (Can also be due to tolerance deviations within the standards set, see Regulations for MARS),

• Measurement errors in the ballast tank sensors. (Can also be due to tolerance deviations within the standards set, see Regulations for MARS),

• Incorrect calibrations, conversions, filtering, averaging and delays of analog sensor signals to the digital value for the data string, in the route from PLC and other intermediate systems up to the delivery of the data string to MARS,

• (Measurement) Errors in the supplied hopper table(s),

• (Measurement) Errors in the supplied ballast tank table(s),

• (Measurement) Errors in the supplied Carène table,

• Incorrect or no correction on offset in the ullage of the hopper sensors in the contractor's systems,

• Incorrect GPS coordinate that selects the wrong location with the possible result that a wrong water density is used.

In the supplied ship configuration:

• Incorrect values in the supplied Carène table. (e.g. not in m³ but in tonnes with the density of seawater),

• Incorrect distance from the reference level of the hopper table to the base of the ship,

• Incorrect positions of the hopper-, draught- or ballast tank sensors in the configuration,

• Incorrect offset in the configuration for draught sensors.

In the choice made on board:

• Incorrect parcel/parcel ship chosen, as a result of which an incorrect density for the water is used.

• Incorrect parcel/parcel ship chosen, as a result of which an incorrect calculation method (Loaded or Dumped) is used,

• Incorrect parcel/parcel ship chosen, as a result of which an incorrect calculation unit (TDS or m³) is used.

In the project layout of MARS:

• Incorrect layout of the parcel- or parcel ship data.

2. The operation of the system:

It must first be made clear that there is a difference between what is shown on the screen during a trip (presentation of the TDS line) and what is calculated after the trip:

• The TDS in the presentation can show a different value in the graph due to a known, and also logical, cause. This is due to the difference in the method of volume determination during dumping and after dumping.

  During dumping, the pump installation is often used to unload as much cargo as possible. The outflow from the pump often causes disturbances in the measurement signals of the hopper sensors at that time. To solve this problem, it has been decided in the past to determine the content with the draught sensors during opened bottom doors. This is only possible by stating that the level difference between inside (inside the hopper ) and outside the ship is equal to 0 cm. (Communicating Vessels) However in practice, due to measurement errors, the measured difference in level between inside and outside is rarely equal to 0 cm. It has been agreed that a deviation of plus or minus 20 cm is allowed during dumping.

  After closing the doors, a change is made from a volume measured with the draught sensors to a volume measured with the hopper sensors. The difference in volume is then at maximum the volume belonging to that 20 cm, this can be both positive and negative. With that, the difference in TDS can also be both positive and negative. In the image on the right, a fictitious representation is presented that is caused by the measurement errors. The only way to avoid a difference in the presentation is if the level difference between inside and outside is 0 cm and no other parameters change (e.g. another location) during the transition moment of dumping-sailing empty.

• The TDS in the calculation of the trip is only based on two measurement moments, namely the full ship (hopper volume and displacement) and the empty ship (displacement). All intermediate measured values (with possible inaccuracies) do not participate in this calculation. The TDS quantity from this calculation is correct, provided that no inaccuracies have been introduced as mentioned under the point "Inaccuracies in the provided data".

Starting at version 2.3.2 the distribution of amounts over locations within a trip is calculated in a different, more accurate and more detailed, way.

Note: The calculations of the total of billable amounts remains unchanged.

Changes in the calculation:

In previous versions the amounts assigned to a location were calculated based on time. In other words: The number of records in the database per locations were counted and multiplied by 5 seconds. (Registration of data in the database takes place every 5 seconds). Amounts calculated this way were not entirely correct.

Starting at version 2.3.2 percentages for distribution between locations are calculated by counting increase and decrease of amounts TDS per second. This is independent of the unit used for payment. If the calculation unit is m³ then the amount to pay will be m³, proportionally distributed over the locations. The proportion is determined in TDS.

Parameters to reduce the number of locations:

Several mechanisms have been implemented to avoid listing a large number of locations with small amounts. The client can configure a number of percentages for each parcelship. Those settings are therefore part of the project setup:

• Percentage lower limit work on a unknown location

• Percentage lower limit work in another area location

• Percentage lower limit work in another location

The defined percentages are applied on a per-session basis.

The lower the percentages, the more locations will be listed. If the percentage dredged on a location is lower than the percentage set in the parcelship, then this amount is added to the previous location. If there is no previous location, the amount is added to the next location. This reduces the number of locations in a session.

A simplified example:

Assume the "Percentage lower limit work in another location" is set to 5% and the real amounts dredged are:
Location A: 100 TDS, location B: 3600 TDS, location C: 1100 TDS, location D: 200 TDS.

The total is therefore 5000 TDS, 5% of which is 250 TDS.

The following amounts will then be reported:

Location B: 3700 TDS, location C: 1300 TDS.

Starting at version 2.3.2 the userinterface concerning the distribution of amounts over locations within a trip has been extended. More details have been added. An explanation of the visible data is given below:

Within the Sessions tab of a trip, one line per session is visible. This line contains a summary of the session. The summary line displays the location where the most work has been done. Furthermore it contains the begin- and end times of the session as well as the values used for calculations of the trip, such as mass of fullship, mass of emptyship and hopper volume.

Clicking the summary line reveals more details. Here the distribution of the billable amounts over the different locations is shown.

In the columns Duration and TDS or m³

The column Start time shows the lowest value, which is the starting time of work in this location.

The column End time shows the highest value, which is the end time of work in this location .
Note: It's the overall end time in that location over the entire session. It is possible that between Start time and End time work has been done in other locations.

The column Duration shows the real duration of work in this location during the session. This might differ from the period between Start time and End time.

The column Mass empty ship shows the value that was used for the calculation. This value is identical for all lines within a session.

The column Mass full ship shows the final value when the ship leaves the location.

The column Volume total load shows the final value when the ship leaves the location.

The calculation unit can be derived indirectly from the corresponding column, either TDS or m^{3,/sup>. The one that is filled in, is the calculation unit.}

If "yes" is filled in in the column Extended ES the used emptyship value was determined during discharging.
this is importanty, because determining the emptyship at a different (postponed) time is also possible.

Caution: Not all locations worked on are necessarily visible in the userinterface. It is possible that amounts have been redestributed over other locations because the dredged amount on a location was below a predefined theshold. (See a different FAQ for the way the redestribution works).

Currently, it may happen that the graph is not shown. The cause is in the browsers. Some browser(versions) may not handle presenting an image properly if the width of space value the image comes in contains digits. In many cases, it can be solved by maximizing the browser screen by clicking on the square at the top right of the browser .  It should be noted that this only works if the taskbar is at the bottom of the screen and not on the left or right side of the screen. The F11 (Full screen) function also works. This also applies that the taskbar must be at the bottom. The disadvantage of F11 is that the browser bars such as the menu, work and bookmarks bar are no longer visible by default. But the advantage is that this space becomes available on the screen of the application. 

Final solution

A patch is currently being made. As soon as it has been tested and approved, it will be made available and can be installed on request, in consultation with the MARS Support Group. This patch will be part of release 2.4.x. and will then be installed on every ship.

If a location on shore is archived, it will be treated in different ways when synchronizing to the ship.

1. If the location has not been used in the historical data available on board, it will be deleted immediately.

2. If the location has been used in the historical data available on board, it will receive the status “DELETED”, but it will remain available for display and reporting in the on-board interface only after the historical data has been deleted (now after 186 days) then the location will be deleted too.

Historical data that is no longer available on board cannot be accessed. In other cases the above applies.

As long as the data is not synchronized to shore, the client cannot see it either. In principle, this data will only become visible to the client again after the synchronization has been reactivated.

It remains possible to continue working with MARS on the ships during the period that synchronization has been stopped. All collected data is buffered on the on-board system. After the synchronization has been reactivated, the collected data from the ship will be synchronized to the new shore environment.

The test environment is designed to test as well as possible, but not all possible situations can be tested. Before testing, an assessment is made as to which situations should be tested. Practice is approximated as much as possible, but of course it can never be completely imitated.

We strive to display the correct information in the Web portal and in the application. When it comes to the help texts on the Web portal, this is already described in the Tips & Tricks on the Web portal under "You know that...?"

This also applies to the sketches in the help texts, but the sketch will first have to be adjusted before it can be replaced, so this takes a little more time than when adjusting texts.

The Dutch language is leading. The English translation is for support purposes only and is made available on a "best effort" basis.

The numbers behind the release notes and prognosis refer to the number of the defect or requirement in our registration system. In case of questions, it is easier for the MARS Support Group or Functional Management to retrieve the corresponding report.

This question was asked in response to “Correct limit values for coordinate system”.

In those cases where there is no other option, the RD system is sometimes still used. The other options were used in the past. Removing this from the software costs money, so we will leave it for the time being.

We make sure that all data from the on-board server is synchronized before the on-board server is swapped for 2.4.1. All data from the old shore system will be transferred to the new shore system, so that all old data will remain available ashore.

Because the on-board server is being switched for version 2.4.1, the data on board before the switch is unfortunately no longer available. Version 2.5.1 is an update. So all data that is collected on board from 2.4.1 will remain available on the onboard server for six months, as is the case now.

During the execution of the work, there was a need to proceed in the following way, and it turned out that MARS did not determine the correct empty ship (value).

One of the ships working with MARS went from Dumping to Rainbowing within one trip. In such a trip, MARS used the empty ship that was determined during the Dumping session. At that time, of course, the ship was not yet empty. We found out that a status order Dumping - Rainbowing and a status order Dumping - Pumping Ashore is not defined in MARS. After Dumping, MARS only knows Sailing Empty. If there is an Empty Ship between the Dumping and Rainbowing or between the Dumping and Pumping Ashore, MARS will determine the right Empty ship for the voyage.

The more common status sequences Rainbowing - Dumping and Pumping Ashore - Dumping are defined in MARS, with or without Sailing Empty in between.

The change means that the definitions of the status sequences Dumping - Rainbowing and Dumping - Pumping Ashore have been added to MARS, so that an Empty Ship is also calculated at the correct moment of determination. By adding the two new status sequences during unloading, the determination of the Empty Ship has therefore been improved.

The change only affects the calculation if unloading method Rainbowing or Pumping Ashore immediately follows Dumping, in this situation MARS from version 2.5.1 works as expected. Nothing has changed for all other unloading sequences.

This is about adding basic functionality of one depth per location. There is no possibility to check or compare slopes with other reference levels such as tolerance depth, mandatory dredging depth or nautical guaranteed depth (NGD).

If this value is exceeded, it is only an indication for the RWS project employee to take a closer look at the data provided by the contractor. It is therefore the RWS project employee who indicates the desired depth that should be used when creating the project in MARS.

To gain more insight into the dredged depth, other software packages are available that are much better suited for this. (e.g. GIS)

We have this "in concept!" described in the upcoming "Voorschriften voor MARS" ("Regulations for MARS") version 3.03. The draft text of this version is added only in Dutch:

11 Bepaling hoeveelheden per locatie

11.1 Inleiding

Het systeem verschaft inzicht in de verwerkte hoeveelheden per locatie. De hoeveelheidsbepaling per locatie vindt alleen plaats tijdens laad- en lossessies. Dit hoofdstuk beschrijft hoe dit werkt.

De opdrachtnemer biedt de positie van het schip aan het systeem aan. Op basis daarvan bepaalt het systeem iedere 5 seconden op welke perceellocatie het schip zich bevindt. Daarnaast berekent het systeem de toe- of afname in TDS per 5 seconden. Deze waarden worden vervolgens gecumuleerd per gevonden locatie. Dit noemen we in het vervolg de geturfde TDS.

Het inzicht in de verwerkte gegevens is op verschillende niveaus mogelijk namelijk:

• Binnen één sessie: Locatie en hoeveelheden per locatie,

• Per sessie: De locatie waar het meest gewerkt is en de totale hoeveelheid van de sessie,

• Per reis: De totale hoeveelheid TDS of kubieke meter van alle laad- respectievelijk lossessies van de reis.

11.2 Bepaling binnen één sessie

Binnen een sessie worden alle berekende toe- en afnames in geturfde TDS gecumuleerd per gevonden locatie. Deze verdeling wordt getoond samen met het eerste tijdstip waarop binnen deze sessie op deze locatie werd geladen respectievelijk gelost en het laatste tijdstip waarop binnen deze sessie op deze locatie werd geladen respectievelijk gelost. De hoeveelheid geturfde TDS dient slechts voor de verdeling van de uiteindelijke berekende hoeveelheid van de reis over de verschillende locaties. Dit geldt voor zowel de gebruikte verrekeneenheid TDS alsook kubieke meters. De finale herverdeling van de bepaalde hoeveelheden vindt pas plaats als alle gegevens van een reis binnen zijn.

Daarnaast is het mogelijk om kleine hoeveelheden die bepaald zijn in andere vakken te laten vereffenen met de naastliggende vakken. Zie "Ongewenste effecten herverdelen"

11.3 Bepaling per sessie

Aan een sessie wordt de locatie toegewezen waar na herverdelen in de eerste stap de grootste hoeveelheid geturfde TDS bepaald is. De totaal bepaalde hoeveelheid TDS of kubieke meter binnen deze sessie wordt dan toegewezen aan deze locatie.

11.4 Bepaling per reis

De hoeveelheidsbepaling van een reis blijft zoals eerder beschreven in onder andere hoofdstuk 1. Hierbij wordt zoals gebruikelijk de hoeveelheid berekend met slechts enkele waarden uit de cyclus namelijk:

• beuninhoud volschip

• waterverplaatsing volschip

• waterverplaatsing leegschip

• dichtheid van het water

• dichtheid van de vaste stof

• handpeilingen van de toezichthouder (bij zand)

Op basis van deze totale waarde, in TDS of kubieke meter, vindt er een herverdeling plaats van de hoeveelheden die zijn bepaald in de eerste stap "Bepaling binnen één sessie"

11.5 Ongewenste effecten herverdelen

Bij het werken langs de randen van een locatie is het haast onvermijdelijk dat een schip net binnen maar ook net buiten de locatie werkt. Om het toewijzen van hoeveelheden aan deze aangrenzende locaties te voorkomen bevat het systeem een filter waarmee hoeveelheden kunnen worden herverdeeld over de overige locaties. Dit verdelen gebeurd op basis van een in het perceelschip vastgelegd percentage dat als grenswaarde dient. Deze percentages zijn vastgelegd voor de volgende situaties:

• werken in een naastliggende locatie

• werken in een onderliggende gebiedslocatie

• werken op een onbekende locatie (er is op de doorgegeven coördinaat geen locatie beschikbaar in het systeem)

Na het voltooien van een reis worden de verzamelde hoeveelheden bepaald op basis van de volgende uitgangspunten:

• Van alle locaties worden de geturfde TDS gecumuleerd per locatie.

• Voor elke locatie binnen de sessie wordt het percentage berekend van de geturfde TDS t.o.v. de totale geturfde TDS van de sessie.

• Deze percentages worden vergeleken met de ingestelde grenswaarde(n) uit de vorige alinea.

• Als het percentage van een locatie lager is dan de grenswaarde, dan worden de 5-secondewaarden toegewezen aan de locatie waar het schip net uit kwam. Als dat niet mogelijk is, zoals bij de eerst bepaalde locatie van een status (Laden of Lossen) dan wordt toegewezen aan de locatie erna.

• Hierna kunnen er minder locaties overblijven. De percentages van de overgebleven locaties worden nu opnieuw berekend.

• Daarna wordt de totale hoeveelheid TDS of kubieke meter van de sessie percentsgewijs verdeeld over de overgebleven locaties.

11.6 Aandachtspunten

• De hoeveelheidsbepaling per 5 seconden kent een bepaalde onzekerheid. Door scheepsdynamiek, sensoronnauwkeurigheden, etc. fluctueert de bepaalde hoeveelheid per 5-secondewaarde. Tijdens het zuigen zal een aantal 5-seconde-waarden een negatieve TDS-toename hebben. Als het aantal waarden, binnen een locatie waarin gebaggerd wordt, groot genoeg is zullen de positieve en negatieve toenames van alle 5-secondewaarden bij elkaar opgeteld een positieve netto hoeveelheid geven. Als er slechts enkele waarden binnen een locatie zijn bepaald is het mogelijk dat er een negatieve hoeveelheid wordt bepaald.

• Ook wanneer er niet wordt gezogen tijdens status zuigen, bijvoorbeeld bij het verhalen of draaien van het schip, zal de bepaalde hoeveelheid per 5-secondewaarde fluctueren als gevolg van ruis op het signaal Tijdens dit tussentijds verhalen of draaien heeft het schip nog steeds de status zuigen. Dit kan ervoor zorgen dat een aangrenzende locatie waarin er b.v. gedraaid wordt een positieve of negatieve hoeveelheid toebedeeld krijgt.

• De positie die gebruikt wordt voor de bepaling op welke locatie er gewerkt is, is niet gelijk aan de positie van de sleepkop(pen). De werkelijke positie van de sleepkop(pen) is niet aanwezig in MARS. Tussen het referentiepunt, namelijk de achterloodlijn/hart schip, en de kop kunnen tientallen meters zitten. Dit is de afstand van de achterloodlijn/hart schip naar de werkelijke positie van de sleepkop.

Parcel separation ensures that when the ship has sailed over multiple parcels/locations during dredging (loading and unloading), then the dredging actions in the relevant parcels/locations are registered separately and not everything just in a main parcel/location. There is still a main parcel/location for the dredging action, but now in MARS the session also distinguishes between all parcels/locations in which the ship has dredged. This is a new functionality in MARS that allows you to better distinguish the dredged/discharged quantity per parcel/location.

The merging of the session locations is done to maintain the "old" working method, so that the project team can choose which payment method will be used before a tender is published:

• Pay on one location where the most dredging has taken place;

• Separately pay per location where has been worked on within a trip.

The configuration for the new ship is entered in the Web portal.

A server can be requested via the “Request ship server” button. The following data must be entered at least:

• Block 1.2 Ship data

• Block 1.3 Network data

The server is set up by Rijkswaterstaat's Technical Application Management (TAB). This is on a “Best effort” basis.

An appointment will be made in mutual consultation between the Contractor and the MARS Support Group to place the server on board.

A system check is then attended by the MARS Support Group shortly afterwards.

Ships that have ever sailed with MARS and still have a server on board must report this to the MARS Support Group (MSG).

Rijkswaterstaat's Technical Application Management (TAB) must then check whether:

1. The current version in use is present. If not, it will be installed. NB! If the version is older than version 2.3.5, a “clean install” must take place on a new server.

2. The “certificate store” is still correct. If not, it will be updated.

The MSG will check whether any system checks need to be done.

If there are any matters that need to be adjusted or still need to be implemented, the MSG will contact the contractor about this and make an appointment.

In principle, the same process applies as for New ships, but the contractor must check the configuration and request a new server via the “Request ship server” button. This will then be provided with the most recently production version of MARS by Rijkswaterstaat's Technical Application Management (TAB) based on “Best effort”.

If a new contractor arrives, he must first request an account from the MARS Support Group. After this, the configuration for the new ship must be entered in the Web portal.

A server can be requested via the “Request on-board server” button. The following data must be entered at least:

• Block 1.2 Ship details

• Block 1.3 Network data

The server is set up by Rijkswaterstaat's Technical Application Management (TAB). This is on a “Best effort” basis.

An agreement will be made in mutual consultation between the Contractor and the MARS Support Group to place the server on board.

A system check is then attended by the MARS Support Group shortly afterwards.

.

Questions about MARS can be asked to the Mars Support Group by phone or email. Contact the "directie UAV" of your contract for the contact details.

Questions regarding improvement of the application or the web portal can be submitted by using the button "Send change request" in "My MARS".

Logged-in users can submit change requests with regard to the MARS webportal or application. A button "Send change request" is located on the "My MARS" page. Those change requests are registered and prioritized through a backlog procedure. A representative of the requester's business is invited to participate in the prioritizing process.

Once a change request is on top op the priority list, the change will be included in a sprint build and taken into production as soon as possible after satisfatory testing.

This FAQ does not apply to users in English.

If you are logged in and you have chosen the English language and you want to check a configuration from the configuration list that is archived, an error message will appear.

Workaround:

1. Switch the language to "Nederlands",

2. Activate the checkbox of the desired archived configuration,

3. Open this configuration,

4. Switch back to the English language.

The button to request a new ship server is located at the tab Configurations, at the bottom of the page with the list of ship configurations. Requesting a new ship server automatically creates a ticket for "Technical Application Management" (TAM) at Rijkswaterstaat. TAM will then install and configure a server.

You should only request a ship server when at least one configuration is present in the webportal for the ship the server is requested for. TAM needs the network information provided for the ship to correctly configure the server.

If this is the first configuration for a ship, please create and submit it first, before clicking the 'Request ship server' button.

The above can be deviated from in consultation with the coordinator of the MARS Support Group.

Sometimes the message "There no ongoing trip" appears within the "system checks" compartment when the user clicks on "Perform water trip" or “Determine Empty Ship”. That happens although a correct datastring is being sent to the shipserver. This is a glitch in the Mars system. The recommended workaround is to select the main compartment "Management" en then go back to the main compartment "Monitor" and subcompartment "Systemchecks". If the datastring is indeed correct the message will not appear anymore and the systemcheck can be started.

While performing a dredge head depth check, you check the value measured with an external sensor with the data in MARS. It may be that the data before it enters MARS has been adjusted, for example to apply an offset for the tide (tide corrected). By looking in MARS, you can be sure that any adjustments will be made properly (not corrected tides).