Skip to main content

Hoppe Signal Quality

Disclaimer

We are continuously working to enhance our signal quality checks by implementing additional criteria and new rules. As a result, the information provided below, issued on March 25, 2025, may not reflect the latest updates or status.

Overview​

With our continuous signal quality evaluation, we aim to provide comprehensive insights into the current status of your Hoppe onboard system and its collected signals.

Our signal quality assessment is based on multiple criteria that can be applied to collected data. Some criteria apply universally to all signals, while others are specific to certain signals or groups of signals. For most criteria, we rely on a standardized and specific Hoppe Machine Code, see Signal Standard | API Developer Portal. However, for unstandardized or unspecific signalsβ€”such as Third-Party Signals (TPI)β€”only the most basic checks can be applied.

In addition to the different criteria, we have implemented a Mode Detection system to determine the operational state of the vessel and its machinery. This allows us to apply specific criteria only when they are relevant and meaningful.

Our approach is inspired by ISO/DIS 800-210 and enhanced by our extensive experience in maritime data collection and performance monitoring, taking into account the specific conditions of the maritime sector.

Basics of Signal Quality Evaluation​

To focus on the most critical signals, the signal quality evaluation is only applied to signals that have been marked as quality-relevant in the Signal List module. If the signal quality evaluation is missing for a certain signal or is being calculated for an unwanted signal, it needs to be properly configured in the Signal List module.

For each criterion, signal, and vessel, we calculate a quality rating expressed as a percentage and displayed using a traffic light scheme:

  1. Good Good: 98% and above
  2. Moderate Moderate: Between 80% and 98%
  3. Poor Poor: Below 80%

To determine a quality indicator for an individual signal and an overall signal quality for the vessel, we apply different summarization methods:

  1. Summarizing criteria to specific Signal Quality: The signal quality for a given signal is determined by the worst-performing criterion.

    Example:

    If a signal has 68% Completeness and 12% Validity, the final signal quality is 12%.

  2. Summarizing criteria and specific Signal Quality to a ship wide summary: The signal quality across all signals and criterion is aggregated using a weighted rating system:

    • Good signals Good contribute 1
    • Moderate signals Moderate contribute 0.5
    • Poor signals Poor contribute 0
  3. The final percentage is calculated by summing up these values and benchmarking against the target for 100% signal quality.

    Example:

    If you have 5 signals rated as good, 2 rated as moderate, and 3 rated as poor, the total score is 6 out of 10 points, resulting in an overall quality of 60%.

Signal Quality Criteria​

The following criteria serve as the foundation for signal quality assessment:

1. Completeness​

Definition:​

Measures whether the expected amount of data is received by the shore server. The percentage indicates the availability of the expected data. This criterion can be applied to any signal received by our server.

Example:

For a data aggregation interval of 1 minute, we expect 1,440 data points over a 24-hour period. If 3 hours of data (180 data points) are missing, the completeness would be 87.5%.

Common Issues:​

  • Disconnected or faulty sensors/interfaces
  • Malfunctions in the data collection system or database

Resolution:​

Check for active notifications related to connection issues in the Notifications module in Fleet Connect or any other onboard notifications.

2. Validity​

Definition:​

Compares signal values against predefined minimum and maximum thresholds. If no minimum/maximum values exist or signal standards have not been applied, validity cannot be assessed. Missing data points are automatically counted as out-of-limit values.

Examples:

  • A flowmeter's temperature should be between 0Β°C and 150Β°C (experience-based). If 30 out of 1,440 expected data points exceed the threshold, the validity would be 98%.

  • A course signal must be between 0Β° and 360Β° (physical/practical limit).

Common Issues:​

  • Faulty sensors
  • Incorrect scaling in interfaces
  • Misconfigured parameters in the onboard system

3. Consistency​

Definition:​

Checks if the signal behaves as expected. For signals generated by a sensor, there should be at least slight variations over time due to noise or measurement inaccuracies. If no variation is detected, the signal is considered "stuck". On the other hand, counter signals should never decrease in value. Decreasing counter values are treated as an error.

There are certain exceptions in place for the consistency metric. If a signal is stuck near zero, it is not considered "stuck" because disabled equipment often results in a zero signal. Also, a few navigation signals are not flagged as stuck if the ship speed over ground is below 4 knots.

Examples:

  • For half a day, Main Engine Power remains constant at a value of 12,500 kW. This results in a consistency rating of 50% (poor) for that day.

  • For half a day, Main Engine Power remains constant at a value of 2 kW. This results in a good consistency rating because the main engine was most likely turned off.

  • GPS position is constant for a whole day and the speed over ground stays at 0 kn. This results in a consistency rating of 100% (good) for that day.

  • Due to invalid device configuration, an actual sensor is mapped to a counter value. Due to this invalid mapping, the "counter" will not report increasing values, resulting in a poor quality rating.

Common Issues:​

  • Faulty sensor
  • Broken or loose cable connection
  • Invalid software configuration or signal mapping

Consistency metric has been introduced in March 2025 and is typically not available for historic data evaluation.

4. Dissimilarity​

Definition:​

Evaluates the correlation between two or more related signals using statistical methods. Certain signals should behave similarly (e.g., engine output power and fuel consumption). This check can be disabled for signals that are not expected to correlate due to different system designs or operational behavior.

Example:

The Fuel Mass Supply to the Main Engine should correlate with the Power Output of the engine. If power output increases, we should expect a corresponding increase in fuel mass supply.

Common Issues:​

  • Faulty sensors
  • Incorrect or unexpected system design
  • Operational deviations (e.g., bypassing fuel flow meters)

5. Rule Validations​

Definition:​

Implements anomaly detection rules that cross-validate signals and sensor metadata. These rules are highly specific and apply only to certain signals or signal sets.

Implemented Rules:

MAIHAK Delta Frequency​
  • Applies only to the MAIHAK Shaft Power Meter when operational frequencies (sa[n].fre[m]op.act.hz@avg) and standstill frequencies (sa[n].fre[m]ss.act.hz@avg) are available.
  • Similar to the onboard Shaft Delta Frequency Limit Violation notification.
  • Evaluates frequency consistency across sensors, considering zero-point frequencies.
  • If deviations are too large, a zero-point calibration of the MAIHAK Shaft Power Meter is required, as described in the System Manual.
Zero Fuel Flow​
  • Checks the fuel mass supply (e.g., me[n].fms.act.tph@avg) for the Main Engine while the machinery is at standstill.
  • Standstill is determined by mode detection (see the following paragraph).
  • A minimal fuel mass supply during standstill may be acceptable, adjustable by a reasonable threshold.
  • Thresholds for reasonable fuel flow during standstill can be configured in the Signal List module.
  • Possible Causes of High Zero Flow:
    • Technical Issues:
      • Bypass valves not properly closed or leaking
      • Non-zero-calibrated flow meters
      • Using emergency fuel lines not covered by the measuring system
      • Incorrect system connections or design
    • Operational Issues:
      • Maintenance on the fuel system, leading to drainage and refilling
      • Intentional bypassing of a mass flowmeter
Speed Validation & Course Validation​
  • Cross-checks whether course (v.cog.act.deg@avg), speed over ground (v.sog.act.kn@avg), and positions (v.gpslat.act.deg@avg and v.gpslon.act.deg@avg) align with each other.
  • Implausible values may arise if signals are received from different onboard devices that are not synchronized or malfunctioning.

Mode Detection​

Mode detection enhances quality checks by filtering out expected behaviors under specific conditions.

Examples:

  • The Echo Sounder is typically switched off when the vessel is in port, which would result in a low signal completeness.

  • When the Main Engine is switched off, Specific Fuel Oil Consumption (SFOC) cannot be calculated.

  • When the vessel is at standstill, the Zero Fuel Flow rules are applied.

Currently, we have two mode detection mechanisms in place:

  1. Vessel & Main Engine Standstill Detection

    Definition:​

    This detection method evaluates whether the vessel is currently being driven by the main engine(s) and is actively moving. When this mode is active, it indicates that the vessel is either in port, at anchorage, or experiencing another stoppage.

    Indicators:​

    The following rules are applied in descending order of priority. If all signals for a specific rule are available, the mode determination is based on that rule.

    • Rule 1: If the Main Engine Running Mode Signal (MEe[n].run.act.nodim@avg) is available, it directly determines the mode.
    • Rule 2: If one of the following signals is available and meets the criteria, the running mode is classified as "underway":
      • Power Output: me[n].pow.act.kw@avg β‰₯ 10 kW
      • Speed: me[n].spd.act.rpm@avg β‰₯ 5 rpm
      • Fuel Flow: me[n].fms.act.tph@avg β‰₯ 1 t/h
      • Torque: me[n].tqu.act.knm@avg β‰₯ 10 kNm
    • Rule 3: If none of the above signals are available, the vessel's speed alone determines the mode:
      • v.sog.act.kn@avg > 4 knots β†’ Vessel classified as "underway".
  2. Auxiliary Engine Running Mode Detection

    Definition:​

    This mode detection determines whether one or more Auxiliary Engines (AEs) are currently operational.

    Indicators:​

    The following rules are applied in descending order of priority. If all signals for a specific rule are available, the mode determination is based on that rule.

    • Rule 1: If the Auxiliary Engine Running Mode Signal (AE[n].run.act.nodim@avg) is available, it directly determines the mode.
    • Rule 2: If one of the following signals is available and meets the criteria, the running mode is classified as "underway":
      • Power Output: AE[n].pow.act.kw@avg β‰₯ 10 kW
      • Speed: AE[n].spd.act.rpm@avg β‰₯ 5 rpm
      • Fuel Flow: AE[n].fms.act.tph@avg β‰₯ 1 t/h