In this version, it is now possible to add multiple parcel locations to a parcel at once. While a parcel could already contain multiple parcel locations, these previously had to be added one by one.

If only one parcel is present in the onboard application, it will now be automatically activated starting from the next new trip.

In the trip map, the different statuses are now displayed with unique colors. This makes it easier to distinguish between statuses and see where the vessel was located during each status. Previously, a single color line was shown for all system statuses.
Additionally, four buttons have been added to the map, allowing users to view adjacent or underlying/overlying maps without having to navigate back to the overview.

The columns that are visible by default on the locations page have been expanded. More information is now directly visible. Previously, this data was only visible on the location detail page after clicking “view.”

When the MARS system on board is started and there is no empty ship value present (TLS), various calculations cannot be performed. In such a case, a so-called bootstrap trip is created. This is the purpose of a bootstrap trip.

In the current functionality of MARS, a bootstrap trip was also incorrectly created when the system was started or restarted. Even if a empty ship value was present. For example, during the temporary downtime of a ship when a server is shut down. This bootstrap trip cannot be used because necessary data, which are present in a regular trip, are missing. This causes problems that have been analyzed and resolved in this version.

When submitting a configuration, an error message was displayed indicating that no file was chosen, even when a file had in fact been uploaded. This issue has been resolved in this version.

In this version, the determination of the correct moment for the empty ship value during rainbowing/pumping ashore has been corrected. Previously, this was automatically adjusted in the Excel files on which settlement was made. Even after performing a theoretical empty ship determination (TLS), in some cases the correct value was not used at the correct time. This has also been resolved in this version.

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

Place the "valid to" date on the report. 

In this version, it is possible for an ON_WALGEBRUIKER to modify the network data in section 1.3 of a configuration with the statuses CONCEPT, SUBMITTED, or ACCEPTED. This can be done both in “edit” mode and in “view” mode.

Previously, modifications were only possible in the “CONCEPT” status and “edit” mode, and a completely new configuration had to be submitted for a configuration in the “ACCEPTED” status.

On the "Trip" page, after selecting a trip, the "Next" and "Previous" buttons have been added. With these buttons, users can more easily navigate through trips within the active filter settings.

In all tabs of a configuration, the ship name with IMO number and the configuration number are now displayed in the upper right corner of the screen.

Validation of MARS Data

The validation of MARS data took place outside the functionality of MARS. Excel files were created to apply corrections. Based on these files, the performed work was settled and accepted.

These enriched Excel files were stored on a drive within the projects but were not traceable in MARS, which was inefficient. To better formalize the validation of the data and maintain transparency for the future, from now on, the data enrichment will take place within MARS, and it will be possible to gain more insight into the data through statistics. The following functions have been added for this purpose:

1. Implementing corrections to the data.

2. Indicating and routing validation findings.

3. Enhancement of delay registration.

1.    Implementing corrections to the data

The following corrections have been made possible for the data collected in MARS:

• Regardless of the calculation unit (M3 or TDS), a project/contract or parcel can be reassigned to the correct project/contract or parcel. [req. 1597].

• Logic for merging trips has been implemented [req. 1761].

• In the parcel ship, the hopper volume for settlement purposes on M3BU can be recorded. [req. 2027].

Additionally, all actions are logged in an audit log [req. 1940, 1941, 1943, 1987, 1997, 2302, 2084].

2.    Indicating and routing validation Findings

After corrections have been made, a trip can be validated by the MARS Support Group. Advice can be given to the contract supervisor, who can accept the advice or request further explanation. Subsequently, the corrected and validated data can be retrieved from MARS via reports.

3.    Enhancement of delay registration

Expansion of delay registration to better distinguish between what is and what is not chargeable according to the contract. [req. 2033]

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.

Within the trip, the version number of MARS that was in use at the time the voyage was created is now displayed.

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.

From this version onwards, an improvement has been made in approaching the trips in the Trips overview screen. A scroll bar is now available on the right side with which you can scroll to previous trips. Browsing per screen with only 20 trips at a time is therefore history.

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.

Under the working title BaRS, a new functionality will be added to MARS, allowing data from other vessels (excluding hopper dredgers) with production data to be uploaded via the web portal. The following changes and additions have been implemented for this expansion: 

• Block 1.2 Ship Data has been moved from the configuration to a new Vessels tab. This block is still present in the configuration, but is now read-only [req. 1854, 1859].

• Management of vessels will now take place in the Vessels tab [req. 1853].

• Production data can now be uploaded from the Vessels tab using a .csv file [req. 1855].

• The operation of the Parcel Ship feature has been adapted to the new possibilities. The current parameters are now only available for the vessel type "Hopper Dredger" [req. 1859].

The management of text in the user interface has now been moved from separate installation files to a table that can be directly managed within MARS. 

This allows for quick and easy corrections of language errors in the interface. This approach was already available for help texts and the "Information" tab. If you encounter an error, please let us know at mars@rws.nl, and we will take care of the adjustment. 

Additionally, the functionality for managing languages is being simplified. Instead of individual files, tables in the database will now be used. Work is also underway to enable the import of multiple languages, which will be available in future versions [req. 2064].

The role of OG_Toetser will be removed, and the associated user rights will be transferred to the OG_Projectleider role.

Documents are synchronized to the vessel from the following locations: 

• Documents tab

• Information tab under Manuals and Regulations

• Configuration, where all documents from the configurations are synchronized.

Only documents that are allowed to be accessed by users onboard will be synchronized [req. 1821].

Validation of MARS Data

The validation of MARS data currently takes place outside the functionality of MARS. Excel files are created to implement corrections. Based on these files, the performed work is reconciled and accepted. 

These enriched Excel data files are stored on a drive associated with the projects, but are not retrievable in MARS, which is inefficient. To better formalize the validation of the data and maintain transparency for the future, we want to implement data enrichment within MARS itself. The following functions are needed: 

1. Implement corrections to the data (this has been realized in the current)

2. Indicate and route validation findings (later than version 2.7.x).

1.    Implementing Corrections to the Data

The following corrections are necessary for the collected data in MARS: 

• Trips can be reassigned that were executed under the wrong project [req. 1681];

• Errors in providing the contractor status can be corrected [req. 1658];

• Trips can be split that have incorrectly been combined into one [req. 1656];

• Trip segments that belong to the same trip can be merged [req. 1657];

• A trip can be linked to a different configuration  [req. 1680];

• Trips can be recalculated based on the collected data (replay) using the modified data as a basis [req. 1659];

• Trips can be recalculated using different criteria for TDS or m³, such as ship value, volume, etc. [req. 1660];

To carry out these corrections, the original data will always be retained [req. 1789];

In addition, all actions are recorded in an audit log [req. 1755, 1942]. The timestamps of the performed recovery actions are also recorded [req. 1932].

2.    Indicating and Routing Validation Findings (later than version 2.7.x)

After any corrections have been made, a trip can be validated by the MARS Support Group. Recommendations can be made to the contract coordinator, who can then accept this recommendation or request further clarification. Subsequently, the corrected and validated data can be retrieved from MARS through reports.