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.”

This functionality¹ focuses on establishing the technical and functional foundation for the collection and availability data from freely definable sensors. The following components are within the scope of this release:

• Collection of Sensor Data

During dredging operations, data from freely definable sensors is collected. Data collection is performed via the existing MARS data string, which enables standardized reading and processing of sensor data.

• Synchronization to Shore

The collected data is automatically synchronized to the shore environment via a secure connection, enabling centralized processing and storage.

• Data Availability for Calculations

The stored data is made available for future use in the MARS functionality, dashboards, or reporting. In this release the data is only saved.

• Adding Sensors to the Vessel Configuration

Within the existing vessel configuration, contractors can add freely definable sensors. This means that new sensors — with specific properties and measurement types — can be easily included in the configuration without requiring technical modifications to the underlying data structure.

This flexibility allows contractors to expand the data collection and tailor it to the specific requirements of the project or operational context.

^¹ The use of this functionality is contractually prescribed. Whether it must be applied in a specific project depends on the agreements outlined in the applicable contract.

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.