If a ship sails for another client for a short time, it is desirable that the Mars data storage as well as the synchronisation can temporarily be stopped.

Further refinement has to take place in consultation with the contractors.

The ability to get an audible signal in the absence of incoming data. This signal can be turned on or off.

Further refinement has to take place in consultation with the contractors.

Make visible in the board interface for how long the water trip is still valid.

Place the "valid to" date on the report. 

If an input field is subject to validation, this validation takes place when leaving the field. The column on the right screen side therefore displays an error message. At that point, the cursor is either on the comment button or in the next input field. This can also be in an input field on another tab.   

The change is: 

• To stop showing the error message when leaving the field, 

• Showing the red cross behind the field remains unchanged,

• The error message will not show until the cursor is placed in the field that has a red cross or warning sign.

In this version, the following functionalities related to the box separation are added.

The location name is listed separately on the screen. These locations are displayed in a coloured way in accordance with the table below:

Below is an example of a location from the list of parcel locations:

Below is an example of a location "Unknown":

Any error messages resulting from the above list will no longer be taken into account in the "Warning state" (Trafic light). ^{[req 1547]}

(Mainrequirement: 821)

The solution is sought in filling in as much as possible in advance.

Further refinement has to take place in consultation with the contractors.

Distinguish the following roles:

• A shore user who can only enter and edit configurations.

• A shore user who can use only project data.

It can happen that the suction tube is in the correct location while the GPS antenna is in a different location. This happens most frequently if the defined location is small.

Further refinement has to take place in consultation with the contractors.

The certificates for MARS will expire at the end of April 2024.

On the ships that then sail with MARS, the certificate-store has to be replaced in order to be able to synchronize between board and shore.

The MARS Support Group will make an inventory when this is possible.

The system offers the possibility to:

• Enable or disable the display of each individual (optional) signal in the graph.

• Adjust the y-axis scaling for each individual (optional) signal.

• The scaling can be set to automatic, or to user-defined minimum and maximum values.

This already worked for a large number of signals, now also for all signals.

The TAB monitor on the on-board system contains TAB system checks. If no system check is currently being performed, this TAB will display a table of all system checks performed on the ship.
The "Empty Ship Value" has been added to this table so that it is easier to gain insight into the Empty Ship value.

In the past it was not always possible to add manual soundings, delays and comments. For example, during an interrupted trip or during the current trip.
Manual soundings, delays and comments can now be entered for multiple trip statuses. After validation on shore this is no longer possible.

For public documents, the user interface does not show who uploaded a document. After logging in, the name of the uploader is only visible for documents if:

• The uploader is the logged in user.

• The user is logged in with the Functional Management role.

It often happens that a contractor asks to put a configuration on concept again so that a final change is possible. In the past, all fields had to be reviewed before the MARS Support Group (MSG) could return a configuration.

Now the "Do not Accept" button becomes immediately available to the MSG, after it has added a comment on the "Overview and (Not) Accept" tab. This allows the contractor's request to be met more quickly.

Up to now the system has among other things displayed the following values in the harmonica view:

• empty ship displacement in tons;

• empty ship displacement in m³;

• displacement in tons (was always 0.000);

• displacement in m³ (same as empty ship displacement in m³);

The last two values are overbid and therefore removed.

Changing the parcel of the current trip. ^{[req. 1113]}

As long as the ship still has status empty sailing, it is possible to link the current trip to another parcel ship and parent parcel.

The old "Activate" buttons under parcel and under parcel ship have been removed. ^{[req. 1286]}

Due to the previously added functionality for activating a parcel and parcel ship, the old buttons are redundant or even unwanted. These buttons have been removed in this version.

When a ship departs, it has usually collected data shortly before in a trip that will not be completed and that not belongs to the current parcel. This data is not useful, but causes that the parcel has an uncompleted trip attached to it. As a result, it is currently not possible to set a parcel to "completed" status in MARS.
That has been improved with this version. In addition, when an item is completed, the underlying items are automatically set to completed.

The following fields have been removed:

• 3.1.1.x Sensor manufacturer

• 3.1.2.x Sensor type (manufacturer)

• 6.b.1.x Sensor manufacturer

• 6.b.2.x Sensor type (manufacturer)

• 7.1.13.x Sensor manufacturer

• 7.1.14.x Sensor type (manufacturer)
  

In addition, the relevant tabs have been adjusted, including the numbering and order of the fields and the layout.

The order of the columns has been adjusted, some fields have been deleted and new fields have been added. The changes are listed in a table below.

Until now this was only possible for port and/or starboard. When entering manual soundings, a choice can now be made for port, middle or starboard.

In the Preference Sets panel, both sections can now be scrolled independently for "Selectable Values" and "Visible Values". This change makes it easier for the user to see what changes have been made to the preference set. There is less scrolling back and forth to check the changes made in the "Visible Values" section.

The reason why a change is being made must be stated in the "Comment" field.

If the "Next" button is clicked within a configuration and not all fields have been completed, a pop-up will appear with a message "Continue to the next tab and ignore errors?" this has now been removed. The check whether all fields have been completed still takes place when saving and submitting a configuration.

At field 4.1.16.x it was not possible to save an entered comment. In addition, the acceptance process did not function on this field. This has now been resolved. ^{[def 1967]}

The publication date is the date of creation and is visible on the right side of a component in a smaller font, in the following sections FAQ, Tips&Tricks, Release Notes, Release Prognosis ^{[req 1632]}

In the user interface of the application and in the database, an additional field with the "Maximum dredging depth" is added under "Locations". ^{[req 1618]}

User actions are stored in the audit log. For a number of fields (a.o. 3.1.4.x) in the ship configuration, this does not seem to work. This has now been resolved. ^{[def 2111]}

For vessels with more than one hopper, a manual sounding cannot be added for another hopper if a manual sounding already exists for one of the hoppers. This has now been resolved and manuel soundings can now be added for all hoppers. ^{[def 778]}

Different sequences are followed with regard to unloading than those taken into account when writing the requirements, so in practice the empty ship is not always determined at the right time. For example, at Dumping to Rainbowen. (Whether or not with sailing empty in between) It also does not work correctly in every situation when there is no sailing empty between the two unloading sessions.

In the following situations, MARS must always make the empty ship determination at the correct time after the last unloading session, regardless of whether or not there is an sailing empty between the unloading sessions. ^{[req 1682, 1673, def 779, 2299, 2301]}

If "dumping" is detected, continue with standard water trip.

With the water trip you have three options after loading: "Continue", "Reverse water trip" or "Cancel".

If you do not choose any of these three options and the system detects the status transition "sailing full - dumping", then the system behaves as if you have clicked "Continue". After opening the bottom doors, the system continues automatically with the normal water trip and determines an empty ship value at the end. ^{[req 1095]}

A water trip with several hoppers.

In the case of a reverse water trip, the system only indicates that the minimum level difference inside/outside is sufficient as soon as this is the case for both hoppers separately and simultaneously. ^{[req 1100]}

Automatic completion of a water trip.

After all the conditions for completion of a water trip have been met, the system completes the water trip independently. It does not matter in which part of the user interface the user is located. ^{[req 1237]}

When searching for documents in the information tab in the web portal, duplicate results are given. This has now been fixed and only unique results are shown. ^{[def 2228]}

In this version, the following functionalities related to the box separation are added.

• A possibility is being built to be able to assign the client to the locations associated with the contract. ^{[req 1282]}

• Improve insight into the assigned session location (where the most has been dredged) and the actual locations within the session. ^{[req 1335]}

• Based on a percentage to be given, locations can be ignored and not shown. That is now an absolute number, so locations in which cargo is "lost" are also shown. By making the percentage a bandwidth, small amounts both positive and negative are not shown. ^{[req 1605]}
  

(Mainrequirement: 821)

If a user has not entered an e-mail address in the user data, and then tries to change the password, a message will follow that this cannot be done without further indication. This notification has been adjusted. The user will now be notified that the email address is missing. ^{[def 2234]}

After removing a manual sounding in the monitor screen, it could no longer be added to the same trip in the monitor screen, it was still possible in the management screen. This defect has been solved, now the manual sounding in the monitor screen can be added again to the same trip where it was removed. ^{[def 2294]}

When choosing a coordinate system for field 1.8.1 in the ship configuration, the correct minimum and maximum limit values are used in the background. These are used in the validation of the coordinates in the data string on board. In the past, the correct limit values were not selected when switching from RD to UTM(ETRS89). Now the correct values are selected. ^{[def 2263]}

When starting the MARS server, various processes are started. A number of these processes have a dependency, process Y can only function properly if process X is fully started. Sometimes this is not the case and process Y is immediately stopped because X is not ready yet. This causes a series of short trips of a few seconds. In version 2.4, the startup of the processes has been arranged differently and this problem probably belongs to the past. This problem did not occur during testing, practice will have to show whether this is really the case. ^{[def 2275]}

In the screen with starting conditions for Theoretical Empty Ship (TES) determination, the required value shows <= as Operator. This was incorrect and has been changed to >=.

NOTE

Regardless of the incorrect Operator, it functioned correctly.

In the past, archived locations were not removed from the system on board. As a result, there were too much choices on the system on board. The choice of location was not always clear.

With this version this has been fixed and archived locations are also deleted on board after synchronization. ^{[def 2282]}

In the log tab screen at the bottom of the monitor screen on board, a multitude of notifications appeared that the on-board user could not use. To avoid confusion and keep the log tab screen clear, a number of types of notifications have been removed from this screen. These notifications are still logged in the system in the background for the possible subsequent analysis of problems that have occurred. ^{[def 2292]}

In the context of life cycle management, a necessary update is needed of:

• the Red Hat Linux operating system (RHEL),

• the MySQL database;

• the underlying Wildfly framework;

• the Java version.

For this purpose, new servers will be set up on shore. On board, the current servers will be swapped with updated servers.

With this update, possible crucial security issues in the application will also be closed.