WO2021246970A1 - System to acquire and process signals for monitoring performance of vessel parts using rule-based anomaly detection - Google Patents

Abstract

According to one aspect of the invention, there is provided a system for monitoring vessel part operation, the system comprising: a signal acquisition module to receive a plurality of data streams, each data stream being from a sensor monitoring performance of a vessel part; a data processing and analysis module coupled to the signal acquisition module, the data processing and analysis module configured to: analyse metrics extracted from the plurality of data streams for violation of one or more applicable rules, each rule establishing a threshold range for anomaly free performance of the monitored vessel part providing the analysed metric; and trigger an alert event providing details of the violated rules, in response to detection of violation of one or more of the rules; and a library storing rules establishing threshold ranges for anomaly free performance of vessel parts under different vessel operation conditions, to which the data processing and analysis module interrogates to obtain the one or more applicable rules.

Description

System to acquire and process signals for monitoring performance of vessel parts using rule-based anomaly detection

Field of invention

[001] The present disclosure relates to acquiring, compressing, analysing and transmitting data on ship engine performance to monitor and optimize fuel consumption, combustion, emissions and ship operation efficiencies.

Background

[002] Data acquisition of sensor readings on vessel equipment using legacy systems and the upload of acquired data is difficult due to several reasons. Their sensors do not provide data in a digital form and as a continuous stream. Each sensor output is proprietary making it difficult to perform aggregate analysis on the output of all the sensors.

[003] While newer vessel systems may provide sensor data in a digital form and as a continuous stream, they also suffer from the same proprietary setback as legacy systems. The sensor data upload for analysis by onshore vessel staff such as superintendents is not necessarily available on a timely basis. [004] Even when data is acquirable from sensors by different manufacturers, only simple analytics on their data stream is applied on vessel in real time. More complex analytics are done on the cloud. As there are breaks in the vessel connectivity to the cloud, analytics on the cloud results in a delay in providing information that can be used to alert staff of unusual or unexpected behaviour.

[005] An object of the present invention is to provide a solution that addresses the above shortcomings.

SUMMARY OF THE INVENTION

[006] According to a first aspect of the present invention, there is provided a system for monitoring vessel part operation, the system comprising: a signal acquisition module to receive a plurality of data streams, each data stream being from a sensor monitoring performance of a vessel part; a data processing and analysis module coupled to the signal acquisition module, the data processing and analysis module configured to: analyse metrics extracted from the plurality of data streams for violation of one or more applicable rules, each rule establishing a threshold range for anomaly free performance of the monitored vessel part providing the analysed metric; and trigger an alert event providing details of the violated rules, in response to detection of violation of one or more of the rules; and a library storing rules establishing threshold ranges for anomaly free performance of vessel parts under different vessel operation conditions, to which the data processing and analysis module interrogates to obtain the one or more applicable rules. BRIEF DESCRIPTION OF THE DRAWINGS

[007] Representative embodiments of the present invention are herein described, by way of example only, with reference to the accompanying drawings, wherein:

[008] Figure 1 shows a schematic of a system, in accordance with an embodiment of the invention, to provides information on operation of vessel parts.

[009] Figure 2 shows a schematic of elements present in a data processing unit used by the system of Figure 1.

[010] Figure 3 shows a data pipeline providing an overview of data flow within the vessel and data flow from the vessel to a cloud 180.

[011] Figure 4 shows a list of sensors, along with their respective monitored vessel parts, that provide a plurality of data streams in the system of Figure 1.

[012] Figure 5 provides an example engine schematic to illustrate the possible layout of sensors found within a vessel.

[013] Figures 6 to 14 show data streams from sensor readings in the system of Figure 1 which are directed at pressure, temperature and rotational speed.

[014] Figure 15 shows combustion cycle analysis against timing chart of other signals.

[015] Figure 16 shows pressure-curve analysis and cycle-metrics.

[016] Figure 17 shows an alerts dashboard which is displayed on an interface provided by the system of Figure 1.

[017] Figure 18 shows cylinder pressure anomaly and cylinder compression imbalance.

[018] Figure 19 shows examples of late injection pressure cycles.

[019] Figure 20 shows an algorithm used by a data uploader module of the system of Figure 1.

[020] Figure 21 shows examples of visualisations or analyses that a local HMI (human machine interface) and remote HMI in the system of Figure 1 are configured to display.

[021] Figure 22 shows asset data displayed on an HMI presented on a mobile device.

[022] Figure 23 shows querying of a vessel asset using the mobile device of Figure 22.

DETAILED DESCRIPTION

[023] In the following description, various embodiments are described with reference to the drawings, where like reference characters generally refer to the same parts throughout the different views.

[024] The present application, in a broad overview, relates to vessel management to monitor and optimise operation parameters, such as but not limited to fuel consumption, combustion and emissions, to improve ship operation efficiency. To this objective, a system that resides on a vessel or a cloud and monitors operation of vessel parts is disclosed. When the system belongs to a network including other vessel systems and on shore systems, the system provides edge computing capability to the network. The system provides a means to acquire, compress, analyse and transmit data on vessel engine performance. When hosted in a vessel, the acquisition, compression and analysis are performed on vessel so as to prepare the data for transmission to a cloud, where further analysis may also be performed. When hosted in a cloud, the system receives for analysis uploaded data streams of sensor readings for vessel parts, the data streams having been acquired on vessel.

[025] The system allows for continuous and automatic acquisition of sensor readings from the monitored vessel parts, whereby the multiple readings are processed simultaneously using a rule-based algorithm to flag anomalous performance, i.e. unusual or unexpected behaviour of the monitored vessel parts. A notification providing detail on such unusual or unexpected behaviour is triggered upon detection, whereby one or more of these notifications is captured under an alert event. Alert events, along with user response (if any), is recorded for purposes such as documentation, review or expert investigation for developing troubleshooting strategies that include recommendations to rectify the anomaly or modification of rules to re-categorise the anomaly as normal behaviour if supported by a data trend.

[026] The system has several modules working in conjunction to meet the system objective. Each module can be realised as either a hardware or software component, with one or more logically discrete routines that when executed perform the function for which the module is programmed. One or more modules may interact with other modules, especially when the output of one module serves as input for another. The computer architecture (such as a single computer server or several computer servers) that hosts the system has at least one memory to store programming code for these discrete routines and one or more processors that provide the necessary partitions to execute the discrete routines. As such, while each of the modules may be assigned a dedicated partition, electronic circuitry belonging to the one or more processors may execute the discrete routines of these modules. The various module names (e.g. signal acquisition module, data processing and analysis module) are coined terms, whereby it is possible that differently named modules are being realised by a same set of processors. For instance, in the implementation where only a single processor is deployed, that processor then provides all partitions for the modules.

[027] A signal acquisition module facilitates the receipt of data streams into the system, each data stream being output by a sensor monitoring performance of a vessel part. A vessel part may refer to a portion of a vessel component (e.g. a valve of a compressor), with that vessel component being monitored by a plurality of sensors (e.g. one sensor per valve of the compressor), so that a subset of the data streams may be readings from a same vessel component. The vessel part may also refer to an entire vessel component; or vessel parts may refer to portions of different vessel components, so that another subset of the data streams may be readings from different vessel components. [028] A data processing and analysis module, coupled to the signal acquisition module, serves as a processor for the plurality of data streams received by the system. The data processing and analysis module uses rules to analyse metrics extracted from the plurality of data streams.

[029] Metrics refer to parameters obtained from the sensor readings which are used to assess the performance of a vessel part. As an example, the output of a pressure sensor may provide an instantaneous pressure reading at each point where its entire data stream is sampled. Extracted metrics from such a data stream would include a maximum pressure, a deviation of an instantaneous maximum pressure against a mean maximum pressure and an ignition ratio (a ratio of the maximum pressure against pressure at the start of a compression stroke). Similarly, metrics may also be extracted from data streams that are directed at, but not limited to, one or more of fluid flow; rotational speed; and relative angular position, where the extraction approach used for pressure is adapted accordingly. In this disclosure, the term “readings” when used with sensors refer to measurements that the sensors take (which are, for example, current and voltage), while the term “metrics” refer to parameters extracted from data streams and are derived from sensor measurements, being in units of the parameter being measured, such as Celsius for temperature or bar for pressure. A metric may be derived from a single data stream, or from multiple data streams.

[030] Briefly, one or more rules are used to determine whether a vessel part is working normally, i.e. providing anomaly free performance. There is a rule for each metric that is used to evaluate the performance of the vessel part. Whether the rule is being followed or violated depends on, for example, how the value of the metric (as obtained from the relevant data stream) compares against a threshold range established for the same metric, specifically whether the value of a metric is within set thresholds established for that metric. The data processing and analysis module is then configured to trigger an alert event providing details of the violated rules, in response to detection of violation of one or more of the rules.

[031] Figure 1 shows a schematic of a system 150, in accordance with an embodiment of the invention. In one implementation, the system 150 is provided in a vessel 111. Alternatively, the system is provided in a cloud 180. The system 150 provides information on operation of the vessel parts 103 (interchangeably referred to as assets or equipment) that allows an operator to decide on vessel maintenance actions. The information received to decide on operator action may be provided from the output of processing done within the vessel 111, for example by a data processing unit 100 on which a data processing and analysis module for the system 150 is implemented; or from output of processing done external of the vessel, for example a remote cloud 180 with which a data uploader module of the system 150 is in communication over a wireless network 106 like VSAT/LTE. The data processing and analysis module and the data uploader module are described in greater detail later with reference to Figures 2 and 3. [032] The system 150 allows for the management of large datasets with high level of detail to assist analysis of the vessel assets/equipment 103. The system 150 includes the following components: vessel assets/equipment 103 identified by its respective asset tag 104; a sensor network 102 that provides an array of sensors, where one or more the sensors is configured to monitor operation parameters of the vessel assets/equipment 103 with which they communicate so that a plurality of data streams is output, with each data stream being from a sensor monitoring performance of a vessel part; a signal conditioning and acquisition module 101 to receive the plurality of data streams and convert the sensor signals from the sensor network 102 into a suitable data format for processing; a data processing and analysis module, provided by the data processing unit 100, to process the data received from the signal conditioning and acquisition module 101 ; and data storage 108 to store the processed data from the data processing unit 100 and/or raw data from the signal conditioning and acquisition module 101. Communication with the data processing unit 100 is facilitated by the local HMI 107 (human machine interface) 107, where the local HMI 107 is used to display data processing results through a desktop interface. The local HMI 107 is also accessible through portable interfaces, such as an application running on a mobile device 105, where this application is also configured to query the vessel assets/equipment 103 through their respective asset tag 104, for example, over a NFC (near field communication) channel.

[033] The cloud 180 also has a data processing unit 112 on which a data processing and analysis module (similar to the data processing and analysis module of the data processing unit 100) is implemented to perform combined data analytics on the received data from the vessel 111 and data from other sources - such as data streams from other vessels (not shown), vessel part manufacturer data and past received data - in accordance with algorithms and data storage 109 to store all such data. The data processing unit 112 may also be coupled to a signal conditioning and acquisition module (not shown) that performs the same functions as the above mentioned signal conditioning and acquisition module 101. Communication between the cloud 180 and the vessel 111 is via a data uploader module in the vessel 111. On-shore communication with the cloud 180 may be through a remote HMI 110 (i.e. not located on the vessel 111).

[034] Various components of the system 150 of Figure 1 are described in greater detail with reference to Figures 2 to 5, 22 and 23.

[035] Figure 2 shows a schematic 200 of the hardware and software elements in each of the data processing units 100 and 112. A main processing unit 201 is assisted by dynamic memory block 202 on which a resident operating system is installed 206. The data processing units 100 and 112 is connected to a network on vessel via network interfacing cards 205 and to other peripheral components such as keyboard and monitor interfacing cards 210. The operating system 206 has resident services running concurrently handling the algorithms 203 that operate over the sensor data stored locally on solid state drive units 207, 209 to support requests served on different HMIs, which are either local 107 (such as the desktop and portable interfaces that are vessel based) or remote 110 (which are based on shore). The portable interface is described in greater detail with respect to Figure 22.

[036] Figure 3 shows a data pipeline providing an overview of data flow within the vessel 111 and data flow from the vessel 111 to the cloud 180. The emphasis in Figure 3 is to illustrate data flow, rather than a detailed description on the analysis performed during its flow. The data collected from sensor network 102 is acquired and conditioned by the signal conditioning and acquisition module 101. This provides the signal conditioning and acquisition module 101 with a plurality of data streams as output, with each data stream being from a sensor monitoring performance of a vessel part. The data streams are processed by the data processing unit 100 on-board (i.e. on the vessel) and stored in data storage 108, on-board. The stored data may be viewed in the local FIMI 107. Additional data, such as user input to supplement the received plurality of data streams, may also be input through the local HMI 802. A data uploader module 306 may then effect the transmission or upload of data stored in the vessel data storage 108 to the cloud 180 via VSA/LTE. The uploaded data is stored on the cloud in its data storage 109, where it may be further processed. The data on the cloud may be viewed by the remote HMI 110, allowing onshore users to monitor and interact with the information via a standard browser connected to internet. Algorithms are deployed 311 and updated periodically from the cloud 180 to the vessel 111.

[037] Figure 4 shows a list of sensors, along with their respective monitored vessel parts, that provide the plurality of data streams to the signal conditioning and acquisition module 101. The sensors fall under three groups: airpath sensors 401, combustion sensors 402 and cooling sensors 403, whereby the metrics extractable from the their output plurality of data streams include one or more of pressure; temperature; fluid flow; rotational speed; and relative angular position. The readings that the airpath sensors 401 take include: turbocharger turbine inlet and outlet pressures and temperatures; turbocharger compressor outlet pressure and temperature; air cooler outlet pressure and temperature; ambient pressure and temperature; and scavenger port pressure. The readings that the combustion sensors 402 take include: cylinder pressure; exhaust valve position; exhaust gas temperature and fuel and emissions sensors. The readings that the cooling sensors 403 take include cylinder liner temperature; piston cooling oil temperature; and jacket cooling water temperature. The list of sensors shown in Figure 4 is non-exhaustive and there may be further sensors (see the labels 404, 405 and 406). For instance, the vessel 111 has a flywheel tacho sensor 540 (see Figure 5) to measure the exact time of engine rotation and to calculate engine rotational speed.

[038] Figure 5 provides an example engine schematic to illustrate the possible layout of sensors found within the vessel 111. The location of pressure (P) and temperature (T) sensors relative to their monitored vessel parts, such as a turbo compressor 502, an air cooler 504, a scavenger port 506 and exhaust port 508, is shown.

[039] The various sensors shown in Figure 4 and possible conclusions discernible from their output data streams is described below.

[040] The cylinder pressure sensor measures the pressure in the cylinder at a high frequency (approximately 10,000 samples per second). The measurements are used to derive the maximum combustion pressure (Pmax) per cylinder and as an average across the cylinders of the main engine, along with other useful metrics through a cycle metric algorithm, described in greater detail below after the description for Figures 6 to 14. The system 150 captures the information in regular periods and is configurable to process the data onboard the vessel 111 to be directly visualised by a user in any one of the HMI 107, 110 or the mobile device 105. By inspecting Pmax value, the user can contrast a working RPM/Engine Load reference values in combination with sea trial tables. Simultaneously, the user can compare the Pmax across the cylinders and identify any imbalance between the cylinders, allowing technical staff to re -balance the engine and reduce fuel consumption. The Variable Injection Timing (VIT) can be used to balance the Pmax and to adjust all cylinders simultaneously to optimise the Pmax values. Sample readings for cylinder pressure 602 over an interval are provided in Figure 6A and maximum cylinder pressure 604 are provided in Figure 6B.

[041] The exhaust valve position sensor observes operation of exhaust values, from which a timing chart presenting all cylinder exhaust valves in firing order sequence, with a default time span of the last 5 seconds. A user can identify quickly the state of exhaust valves (open/ closed), inspect the firing order and TDC (top dead centre) alignment. Furthermore, through any one of the HMI 107, 110 or the mobile device 105, the user can zoom-in/shift to a region of interest to identify lag between for example due to resistance or anomalies in the exhaust valve and drive assembly. This includes the valve guide and spindle, air spring, hydraulic actuator and interconnecting pipework. A deviation in the opening timing could be an indication of the hydraulic drive system condition (damage, wear) and valve guide or spindle. A deviation in the closing timing is an indication of damage or wear on the air spring, damping system or valve guide/spindle. In addition to the exhaust valve opening phase the exhaust valve rotation can be monitored by means of a slot in the sensor reference surface, when the slot coincides with the sensor no axial movement is detected until the reference surface rotates allowing for the axial movement to be detected. Sample timing charts derived from exhaust valve position sensor readings are provided in Figure 7.

[042] The exhaust gas temperature sensor measures quality of the combustion and dynamics on engine load regime. These readings may be contrasted with engine room (Ambient) / PScav temperature sensor readings, as a rise in ER (engine room) temperature will see a rise in exhaust gas temperature readings. A sample historical timeline derived from exhaust gas temperature sensor readings is provided in Figure 8.

[043] The turbo compressor pressure sensor comprises sensors at the turbine inlet and outlet, providing the pressure readings before and after the turbine. The pressure difference, in conjunction with the temperature difference, across the turbine is an indication of the energy extracted from the exhaust gas (kinetic and potential i.e. velocity and temperature). The turbine efficiency can be calculated, and any reduction would be an indication of fouling or damage to the turbine or nozzles. A sudden drop could be an indication of mechanical damage and a gradual drop an indication of fouling. [044] The turbo compressor temperature sensor comprises sensors at the turbine inlet and outlet, providing the temperature readings before and after the turbine. The temperature difference, in conjunction with the pressure difference, across the turbine is an indication of the energy extracted from the exhaust gas (kinetic and potential i.e. velocity and temperature). The turbine efficiency can be calculated, and any reduction would be an indication of fouling or damage to the turbine or nozzles. A sudden drop could be an indication of mechanical damage and a gradual drop an indication of fouling. [045] The compressor outlet pressure sensor comprises a sensor after the compressor (Outlet), providing the pressure readings. The pressure ratio of the turbo-compressor (TC) unit is measured by comparing inlet and outlet. A loss of compression ratio could indicate loss of impellers fouling or filters on TC inlet. The TC Outlet readings may be compared with the compressor readings, to verify the compressor is working correctly.

[046] The air cooler pressure sensor comprises sensors at the air cooler inlet and outlet, providing the pressure readings before and after the turbine. A decrease of differential air cooler pressure indicates fouling or damage to the air cooler or the air cooler filter. A sample reading is provided in Figure 9. [047] The air cooler temperature sensor comprises sensors at the air cooler inlet and outlet, providing the temperature readings before and after the turbine. The charge air cooler temperature difference is an indication of the cooler condition. A reduction in the cooler temperature difference may be an indication of fouling or damage. This value is compared to historical/shop test data to identify optimal condition. A sample reading is provided in Figure 10.

[048] The scavenge port pressure sensor measures scavenge air pressure, which is required for cylinder pressure computation. It is also an overall indication of the turbocharging system condition. [049] The cylinder liner temperature sensor comprises sensors on the liner of each cylinder, providing the temperature readings from the upper part of the cylinder liner. Cylinder liner temperature (CLT) is a vital indicator of cylinders and piston running performance, with high temperatures possibly leading to breakdowns. Similarly, both higher and lower temperatures than average can indicate issues with the fuel injector of the main engine. A periodic increase in the liner temperature is to be identified, which indicates that the piston rings are rotating. If this does not occur, this may indicate the rings are sticking and require attention. The liner temperature can also be used to optimise the cylinder oil feed rate. A sample temperature reading is provided in Figure 11.

[050] The j acket cooling water temperature sensor provides readings for the j acket water temperature, which is a measurement of optimal heat transfer to ensure engine performance (Fuel burn). Non-op timal performance of this results in high exhaust valve temperature and leads to higher fuel consumption. A sample temperature reading is provided in Figure 12 below.

[051] The piston cooling oil temperature sensor comprises sensors that monitor in cylinder combustion properties. An increased return temperature may indicate delayed combustion caused by a low(er) air flow or faulty fuel injection equipment. If these values are acceptable (Pcomp, Pmax, Exhaust Gas Temperature, Cylinder Liner Temperature) then the cooling chamber condition can be monitored, where a lower return temperature indicates that heat transfer has been impaired, resulting in a reduced piston assembly lifetime. A sample temperature reading is provided in Figure 13.

[052] The sensor network 102 has further sensors that are not shown in Figure 4, which are described below.

[053] A flywheel (tachometer) sensor is used to measure engine rotation speed. The flywheel sensor measures flywheel rotations per minute, as computed from a 5' time window moving average. A user can employ engine rotational speed (RPM) as a proxy for the engine load, and it is a key metric to contrast other metrics in the HMI. The speed stability is an indication of the governing system condition, whereas an unstable speed under steady and calm sea conditions will lead to an increase in the fuel consumption. A sample RPM reading is provided in Figure 14.

[054] Additional sensors where sample readings are not shown are briefly mentioned below.

[055] Fuel sensors use either a volumetric flow meter plus a temperature sensor or just a mass flow meter. This data is combined with other associated data, such as which fuel is being used and their properties - name of the fuel, density of the fuel at a standard temperature, its calorific value and its sulphur content. This additional information may be collected through the local HMI 107 or the remote HMI 110 or an external data source.

[056] The data from these sensors is used to calculate Fuel Oil Consumption (FOC) - the mass of fuel consumed per unit of time, and this information is collected on an ongoing basis, e.g. at a frequency of once every second. Furthermore, the Specific Fuel Oil Consumption (SFOC) - mass of fuel consumed per unit of power generated is calculated by using the FOC values and the indicated engine power values (described in the above cycle-metrics algorithm). Carbon and sulphur emissions can also be estimated from the FOC, based on approximate carbon content values and known sulphur content. If emissions sensors are available separately, accurate emissions may be calculated, rather than approximate values. [057] An engine room temperature and pressure sensor measures engine room operating conditions temperature and pressure, to derive metrics that can be used to benchmark the temperature and pressure readings from airpath values, particularly the metrics taken after turbine unit and air cooler, to understand the effectiveness of the Turbine and/or Air Cooler. ISO corrections (refer https://www.iso.org/standard/28330.html) are also important to consider environmental implications of vessel geographical location. The sensors are placed in the engine room, providing ambient temperature and pressure within the engine room.

[058] A fuel rack indicator feature provides a governor used as the engine regime setting and main control input. User can inspect the governor position and contrast its position with actual RPM. A slip on differential values from Fuel Rack to actual RPM may indicate possible maintenance required on the governor that could lead to increased fuel economy.

[059] Data from the sensor network 102 of each vessel 111 will be received by the cloud 180, which allows a fleet operator to remotely determine the operation status of a vessel from a drop-down menu accessible in the remote HMI 110. The remote HMI 110 provides several features to assist a fleet operator with the monitoring of vessel operation, which are described below.

[060] A time selection feature allows inspection of all datasets and metrics, with default timespan of last 7 days, although a user can select longer time periods. The user can zoom in on desired selected period of interest. By providing interactive time inspection, the user can focus an inquiry on a specific time bound and region of interest. For example, the engine regime changes or particular dates or times that the user wants to review details about engine performance indicators.

[061] The upload of data from the above sensors to which Figures 6 to 14 relate is managed with the uploader module 306 shown in Figure 3, which can account for 30-50 tags (sensor channels) of data in a daily upload of around 2 to 3 Gb of data. In contrast, prior art systems can only upload a few hundred kb of data daily based on 3 to 10 tags.

[062] One or more of readings of the above sensors is used to compute metrics using algorithms described below. These metrics are, for example, used to compute useful quantities regarding combustion and fuel consumption. These algorithms are discussed in greater detail below.

[063] Combustion analysis algorithm: The combustion sensors 402, which include cylinder pressure; exhaust valve position; exhaust gas temperature; fuel and emissions sensors collect data about the health and efficiency of the combustion process. The data from these sensors is processed using: (1) a cycle-metrics algorithm and (2) a fuel and emissions analysis algorithm. These algorithms operate on-board the vessel 111, enabling real-time analysis and visualization of the combustion process. The data is also uploaded to the cloud 180 systematically, for downstream analysis.

[064] Existing conventional engines (non-electronic engines) do not have cycle-metrics available on a continuous basis. They rely on periodic (e.g. monthly) measurements of cycle-metrics using a mechanical technique. Similarly, fuel flow measurements are not measured on an ongoing basis, but recorded manually once a day. While conventional electronically-controlled engines may have pressure monitoring and fuel-flow monitoring tools on-board, they lack a method to efficiently upload all measured data to a cloud for visualisation and analysis through HMIs in relation to data from other sensors.

[065] In contrast, the system 150 enables the availability of cycle-metrics, fuel consumption and emissions on a continuous basis for conventional engines, and makes this accessible on the local HMI 107 and the remote HMI 110 as well as local and cloud storages for both conventional and electronically controlled engines. This enables on-board and on-shore staff to monitor the engine health and efficiency more closely and can lead to quicker identification of problems, as well as enable a deeper analysis.

[066] Cycle-metrics algorithm: The cylinder pressure sensor provides regularly sampled, high frequency readings of the pressure inside each combustion cylinder. The cylinder pressure data is combined with data from the flywheel sensor for each cylinder and processed on-board using a cycle- metrics algorithm. Within this algorithm, the start and end of a cycle is identified by matching timestamps in the high frequency pressure data and the flywheel data. This is referred to as ‘framing’ . The pressure data for the cycle is processed using signal processing to obtain key metrics of the combustion cycle, namely, the maximum combustion pressure (Pmax), the cylinder pressure at ignition (Pignition), the cylinder pressure at the start of compression stroke (Pcomp) and the phase (degree) of the combustion cycle at which these events happen, as demonstrated in Figure 15, which shows combustion cycle analysis against timing chart of other signals. These metrics are obtained by carrying out operations such as noise filtering, numerical differentiation and peak identification. The Mean Indicated Pressure (MIP) can be calculated using the area under the pressure vs. timing curve. MIP and engine rotational speed are further used to calculate the indicated engine power.

[067] A separate set of cycle-metrics is captured for each cylinder at regular periods. Compressing high frequency signals to cycle stats is advantageous as the size required from one cycle at lOksamples/s is reduced to few bytes per second. Data size is further reduced by capturing combustion data only at designated points of operation, for example at steady engine conditions of high relevance, such as sable engine load. This focuses data capture to be only over intervals which provide the valuable detail to perform the required analysis, as opposed to capturing data over longer operational periods. Transitional data is discarded but can be saved for analysis to obtain additional insights, this includes the engine control system stability and response under constantly fluctuating operating conditions such as weather or sea wave transients.

[068] The cycle-metrics and related pressure data can be visually presented, as shown in Figure 16, providing an example of pressure-curve analysis and cycle-metrics shown on the local HMI 107 or the remote HMI 110. The data from this analysis is also stored on-board the vessel 111 and transmitted to the cloud 180. A rule-based vessel performance algorithm on-board the vessel 111 uses this data to trigger alerts.

[069] Examples of how metrics calculated from the algorithms discussed above may be used are provided below:

• Comparison with sea-trial reference data: A user can visualize various metrics such as Pmax and SFOC against engine rotational speed and/or engine load values. These can in-turn be compared against the metric values for that speed or load in the sea trial and shop-trial reference data. Such a comparison can be carried out for a range of speed and load values during engine normal operation. Changes in these values over time are physically related to degradation in the condition of various parts or vessel hull.

• Alerts based on cylinder metrics: Rules can be defined on combustion metrics, which when violated would trigger an alert, indicating possible deficiencies or faults in the engine.

[070] The manner that the system 150 uses rules is elaborated before detailing how they are applied on specific metrics, such as combustion metrics. Other metrics on which rules can be applied include, but are not limited to, one or more of pressure, temperature, fluid flow, rotational speed; and relative angular position.

[071] The metrics obtained or extracted from the sensor data are monitored automatically by a data processing and analysis module, realised by the data processing unit 100 (or the data processing unit 112), and analysed against rules that set a threshold range providing minimum or maximum thresholds on these metrics. Each rule sets a threshold on more or more metrics, such as:

• directly obtained metrics: from directly measured readings from raw sensor data provided by the sensor network 102 used to monitor performance of vessel parts

• first order derived metrics, such as cycle stats metrics and pressure curve analysis shown in Figure 16: the difference between the pressure or temperature after and before a vessel part (such as the turbo-compressor), specific fuel oil consumption. A first order derived metric is a derived metric that is calculated from directly obtained metrics, i.e. a first order derived metric is a derived parameter that is calculated from parameters that are directly measured by one or more sensors.

• second order derived metrics, such as deviation of Pmax of each cylinder from the mean Pmax over all cylinders: the difference in Pmax between any two cylinders, standard deviation of the engine speed over a fixed time-window, standard deviation of the engine load over a fixed time- window. Since a second order derived metric is derived from first order derived metrics, they are still considered as a derived metric that is calculated from directly obtained metrics and are calculated from parameters that are directly measured by one or more sensors. [072] Examples of rule violations that are based on first order derived metrics and second order derived metrics are provided below:

• Smoothed sensor reading threshold: Jacket Cooling Water 3 (95 C) is above maximum threshold 90 C.

• First order metric: Absolute difference between Exhaust Gas Temperature 2 (320 C) and mean Exhaust Gas Temperature over cylinders (390 C) exceeds maximum deviation from mean threshold 60 C.

• Second order metric (since Pmax is first order): Absolute difference between Pmax 2 (60 bar) and Pmax 1 (66 bar) exceeds maximum allowed Pmax spread 5 bar.

• Second order metric (since ignition ratio is calculated from first order metrics Pmax and Pcomp): Ignition ratio 3 (1.15) is below minimum threshold 1.2

[073] The monitoring performed by the data processing and analysis module is to analyse the extracted metrics, used to evaluate the performance of vessel parts, for violation of one or more applicable rules, as earlier explained. A threshold range is established for each rule in respect of a metric from a single data stream or a metric from multiple data streams, whereby the establishment of the threshold range arises from being found to provide anomaly free performance of the monitored vessel part. The data processing and analysis module interrogates a library storing rules establishing threshold ranges for anomaly free performance of vessel parts under different vessel operation conditions to obtain the one or more applicable rules. This library may be hosted in the vessel data storage 108 or the cloud data storage 109 (see Figure 1).

[074] The library serves to provide the system 150 with an updatable repository for storing rules used to analyse metrics extracted from the plurality of data streams. While compatible, it is not mandatory that any of the rules stored in the library has a different threshold for each vessel operation condition (e.g. a first threshold for stable vessel operation and a second threshold for unstable vessel operation). That is, the library accommodates for instances where the same rule applies for different vessel operation conditions and is also adapted to store rules with different threshold ranges for different operating conditions. As rules get updated, such as from aggregate data trends, the library provides a means to apply such updates in a consolidated manner. Thus, the advantage of having the data processing and analysis module interrogate the library is to ensure that the latest rules are being referenced when analysing extracted metrics.

[075] The detection of violation of a rule generates an alert, which results in the data processing and analysis module triggering an alert event for each of these alerts providing details of the violated rules. The details include any one or more of a start and end time of each rule violation, the sensors and/or metrics for which rules were violated, the name of each of the violated rules, an indication whether the violated rules are related, a history of past violations for each of the violated rules and links to visual tools allowing assessment of the data streams that violate the rules.

[076] An example of the name of violated rule refers to the actual rule that was violated, such as Pmax on cylinder 2 (80 bar) violating the maximum allowed deviation (5 bar) from mean Pmax (74 bar). An example of an indication whether the violated rules are related is an advisory such as ‘multiple rules relating to cylinder 2 combustion are violated, please check cylinder 2 fuel injector’. An example of links to visual tools allowing assessment of the data streams that violate the rules is the provision of one or more links to plots or tables of the relevant data streams within the local HMI 107 or the remote HMI 110. The duration of past violations for display can be preset (e.g. 2 months) or selected by a user. [077] The triggering of an alert event depends on the vessel operating condition and a degree of the violation, either or both applying on one or more of: a designated group of applicable rules being violated, an excessiveness of the violation of an applicable rule, whether a requirement for several instances of the violated rule to occur within a specified duration is present and met, and whether the manner in which the rules are violated characterise sensor failure.

[078] An example of whether the violated rules characterise sensor failure refers to an excessive violation for an extended period, which usually points to a sensor failure. Logic is applied to mute certain rules, where the alert event is a notification that a particular sensor may not be working correctly. [079] An instance of whether a requirement for several instances of the violated rule to occur within a specified duration is present and met refers to when same rule for stable operating condition and unstable operating condition (e.g. when the vessel is manoeuvring) applies. Under stable conditions, every violation might trigger an alert, while under unstable conditions, an alert is triggered only if the rule is violated several times over a specified duration.

[080] Each rule may have more than one threshold range, each associated with its respective degree of alert, which results in alert events having different tiers. For example, the violation of a first threshold results in a simple alert, while the violation of second and greater thresholds results in alerts of increasing intensity. A notification accompanying the alert event also depends on the presence of such tiered alerts. An alert event that only contains simple and low intensity alerts may only contain warning notifications, while an alert event that contains at least one high intensity alert may contain an urgent notification that immediate action needs to be taken.

[081] With reference to Figures 6 to 14, the plurality of data streams comprises readings which include, but are not limited to, one or more of fuel consumption; airpath sensors, combustion sensors and cooling sensors. The data streams might undergo pre-processing, performed by the signal conditioning and acquisition module 101, before applying thresholds to reduce the noise, such as taking a rolling mean and calculation of rolling standard deviation. [082] Setting thresholds: The thresholds may vary for each vessel and over time. These thresholds are set based on operational information provided in the vessel manuals, such as sea-trial data as well as based on statistical trends in the observed data from sensors. The data uploader module 306 provides the data, which enables the development and testing of rules by analysts and experts who are not on the vessel 111. The thresholds may be adjusted manually from time to time based on

• maintenance activities performed on the sensors or the parts being monitored,

• user feedback, and

• observed data from sensors.

Accordingly, the threshold ranges are derived from a non-exhaustive list of any one or more of the vessel part manufacturer data, expert input and past data stream readings; updatable from this non- exhaustive list; or a combination of both.

[083] Filtering alerts: One or more filters may be applied on a rule before triggering an alert. Here are three examples:

• Certain alerts are triggered only when the engine is operating under a “stable condition”. The rule for “stable condition” may be formulated as: if the standard deviation of the engine load or speed over a fixed time rolling window is less than a threshold value. For example, the engine may be said to be operating under a stable condition if the standard deviation of speed over a rolling window of 30 minutes is within 2 rpm.

• The alert for maximum deviation of exhaust gas temperature of a particular cylinder from the mean may only be triggered when the mean exhaust gas temperature across cylinders is above a certain threshold value.

• The earlier mentioned instance of the same rule applying for stable operating condition and unstable operating condition (e.g. when the vessel is manoeuvring). Under unstable conditions, an alert is triggered only if the rule is violated several times over a specified duration.

[084] Combining alerts into events: The details of one or more of the rules that are violated within the same interval may be combined into a single alert event. In more detail, multiple alerts that occur in related sensors at the same or nearby time-points are combined into a single “event”. An event is a period of time during which one or more related alerts are triggered and at least one alert is triggered at each time-point in the event. The grouping of alerts into events allows the user to consider multiple alerts simultaneously, which is advantageous for facilitating an inference into possible connections between them. Figure 17 shows an example of the alerts dashboard which is displayed on the remote HMI 110 and the local HMI 107. [085] The vessel data storage 108 may provide a database to store a log of the alert events, the log being adapted for transmission to the cloud 180.

[086] User feedback: The alert events and corresponding alerts are shown to on-board personnel via the local HMI 107 and the mobile HMI (e.g. the mobile device 105 of Figure 1) in real-time since the rules are applied on-board the vessel, independent of data connectivity to the cloud 180. The on-board personnel can provide feedback on each alert, stating whether it was useful and specifying which actions, if any, were taken.

[087] Accordingly, each alert event may be accompanied with one or more of: a prompt for investigation of one or more vessel parts related to the metrics for which one or more of the rules were violated; and a prompt for documentation of an outcome of the investigation. In addition, either or both of these prompts may be accompanied with one or more corrective action suggestions, derived from one or more of the rules stored in the library. The log of the alert events, stored in the database provided by the vessel data storage 108, includes user input or non-action in response to the alert event and a duration of each of the alert events, which is advantageous for providing a documentation trail.

[088] The same alerts are also shown to onshore personnel via the remote HMI 110 in near real-time along with any feedback on the alerts received by the on-board staff, subject to VSAT constraints. Each event is identified by a unique identifier, enabling the on-board and onshore staff to communicate about the status of events through various channels.

Additional examples of rule-based alerts

• As mentioned earlier, rules can be defined on combustion metrics. A maximum threshold maybe set on the second order metric ‘Pmax deviation’, which is defined as the absolute difference between Pmax of a particular cylinder from the average Pmax over all cylinders. If the Pmax deviation for a particular cylinder exceeds the maximum threshold, an alert is triggered, pointing to a possible imbalance between the cylinders. The on-board personnel can then examine representative pressure cycles, Pmax and related data from, for example the visualizations shown in Figure 18, which shows a graph 1802 of cylinder pressure showing an anomaly 1806 and a chart 1804 for cylinder compression imbalance with the anomaly 1806 of Figure 18 being present in cylinder 3 (see label 1808). The on-board personnel may opt to re balance the engine which could reduce fuel consumption.

• A minimum threshold may be set on a second order metric, e.g. the ignition ratio given by Pmax divided by Pcomp. For example, when the ignition ratio is less than 1, this may point to late- injection, as illustrated in the pressure curves shown in Figure 19, which shows examples of late injection pressure cycles, where Pcomp > Pmax. [089] Returning to the data pipeline of Figure 3, the data uploader module 306 sends vessel processed data, stored in the vessel data storage 108, to the cloud 180 (see Figure 1). Vessels are moving on open waters and experience network connectivity outages e.g. high latency, low bandwidth, package loss, or loss of network. Therefore, uploading of large datasets pose a connectivity challenge to the data uploader module 306. Conventional software solutions and tools are not built to handle such a network environment. To upload vast amounts of processed data from the vessel 111 to the cloud 180, a method to upload data that addresses network limitations, unstable connectivity, varying bandwidth, high latency and limited internet usage from the vessel is needed.

[090] The data uploader module 306 addresses the above challenges by using one or more of the following techniques:

Cache and backfill the data once network connectivity for the vessel improves Data sync, perfect/heuristic watermarking Pause and resume functionality Broker layer, regulate the traffic

[091] The data uploader module 306 has a transceiver (not shown) that manages downloading of data into the vessel 111 and uploading of data from the vessel 111. The data uploader module 306 allows upload of data to the cloud 180 in a progressive way, detecting the quality of network connectivity to decide the upload strategy, and prioritizing data based on its importance and available internet quota. [092] Figure 20 shows an algorithm used by the data uploader module 306 to assess and quantify the quality of the connection to the cloud 180 by considering the following elements that impact the connectivity and the quality in which the data is transferred through the network:

Goodput Package loss Errors Latency

Package delay variation Out-of-order delivery

[093] In step 2000, the condition of the network connectivity is detected and categorized as poor or good in step 2001. The strategy that the data uploader module 306 chooses to upload processed data stored in the vessel data storage 108 is based on the condition of the network connectivity. If the network connectivity condition is above a threshold score, the data uploader module 306 detects that a good network is present at step 2002 and proceeds to all upload all processed data in the vessel data storage 108 to the cloud 180 in step 2003, depending on whether this is supportable by an upload bandwidth cap and a current upload speed. If the network connectivity condition is below the threshold score, the data uploader module 306 detects that a poor network is present at step 2004 and proceeds to upload only high priority data in the vessel data storage 108 to the cloud 180 in step 2005.

[094] Data priority is decided according to the economic value and payload size of the following datasets:

• Raw sensor time-series data: Low/high frequency data, analog/digital data.

• Telemetric data, which includes server status, application logs, etc.

• Time-series of computed metrics derived from raw sensor data. For example, rotational crankshaft speed in rpm is a computed metric derived from the sum of the ticks over a minute from the tachometer sensor; cycle-metrics derived from combustion sensors.

• Alerts based on data analyzed onboard the vessel indicating potential issues or inefficiencies, along with user feedback on alerts.

• Data from other sources on-board the vessel which is not already available on the cloud 180. For example, data from on-board weather sensors and Planned Maintenance System (PMS) data. [095] Even in times of good network connectivity, network bandwidth is limited. Thus, an overall objective when uploading data is to reduce and prioritize the data being transmitted at all times. The following techniques of applying data quality filtering, which result in only portions of data streams from the sensor network 102 being uploaded may be employed to reduce the amount of data being transmitted:

Data corresponding to times when the vessel is stationary may be excluded from transmission. This may be done, by monitoring the engine rotation speed measured by the tachometer sensor. Furthermore, experts mostly care about analysing engine performance data when the engine is in stable operation. Thus data corresponding to times when the vessel is manoeuvring, i.e. not operating at a stable speed may also be excluded from transmission. This could be done by training a machine learning algorithm to identify manoeuvring operation from the engine rotational speed data.

Raw high frequency data, such as that from combustion sensors has a high payload but relatively low value. Instead of raw high frequency data from combustion sensors, data from only calculated cycle-metrics may be transmitted, which serves as a way to compress the data. When more bandwidth is available, representative samples of high frequency data may be transmitted for further analysis or visualization on the HMI.

If the remote HMI and remote algorithms can function with data at a lower frequency than collection frequency, the data may be downsampled to this lower frequency before transmission. Raw data may be down sampled without information loss Zipping data [096] As such, one possible implementation has the data uploader module 306 configured to, regardless of the network connectivity condition, prioritise the upload of one or more of the following: portions of the data streams from the sensor network 102 following data quality filtering; the extracted metrics from the plurality of data streams; the alert event and the user feedback on the alert event; and samples of high frequency raw data streams. In this implementation, upload of raw data from the plurality of data streams by the data uploader module 306 has a lowest priority and is dependent on whether supportable by an upload bandwidth cap and a current upload speed.

[097] The data uploader module 306 may also be further configured to upload data, untransmitted from a previous session, upon detection of sufficient upload bandwidth and sufficient upload speed. The data uploader module 306 is also further configured to download updates (per the deployment 311) to any one or more of the following: the rules stored in the library, and algorithms used to analyse the plurality of data streams to collect health data on the monitored vessel parts.

HMIs

[098] The local HMI 107 may be implemented as a desktop interface on the vessel 111 to display any one or more of a status of the monitored vessel parts, the received plurality of data streams from the sensor network 102; and notifications generated from a triggered alert event. This desktop interface is further configured to receive user input in response to the generated notifications.

[099] The remote HMI 110 provides a dashboard to visualize the same data streams shown in the local HMI 107 for the vessel 111 and other vessels. The data streams from all networked vessels, along with external data (such as vessel part manufacturer data and user input) provide a big data set that is used by algorithms hosted in the cloud 180 to establish threshold ranges for the rules used to evaluate the performance of the vessel part.

[100] Both the local HMI 107 and the remote HMI 110 show alerts raised by the violation of rules and a user can navigate to see further details about the alerts such as affected metrics.

[101] Figure 21 shows non-exhaustive examples 2101 of visualisations or analyses that the local HMI 107 and the remote HMI 110 are configured to display. The local HMI 107 and the remote HMI 110 are, for example, configured to provide visual tools (such as in the form of plots, tables, icons, symbols) providing: the status 2102 of the vessel 111 condition, combustion quality 2103 and performance indicators 2104. Information that the local HMI 107 and the remote HMI 110 can display for the vessel status 2102 include: vessel static metadata 1205, alerts 1206 from rules violation, a duration 2107 over which, for example, a data stream is being analysed and a duration 2108 over which, for example, different data streams are being compared. Information that the local HMI 107 and the remote HMI 110 can display for the combustion quality 2103 include: pressure analysis 2109, timing analysis 2110 and SFOC (Specific Fuel Oil Consumption) analysis 2111. As mentioned above, carbon and sulphur emissions can be estimated from FOC. Information that the local HMI 107 and the remote HM1 110 can display for the performance indicators 2104 include: cooling analysis 2112, airpath analysis 2113 and other indicators 2114.

[102] The mobile device 105 of Figure 1 provides for a portable interface with the same capabilities as the desktop interface (confer the local HMI 107). This portable interface is further configured to allow querying of an operation status of any one of the monitored vessel parts when in proximity (over wireless transmission protocol like NFC (near field communication) 2301, see Figure 23), described in greater detail below.

[103] Figure 22 shows one embodiment of displaying asset data via an HMI 2201 presented on a mobile device 105 by which a user inquires a vessel asset (103 in Figure 1 and 2300 in Figure 23) via an asset tag (104 in Figure 1 and 2304 in Figure 23). The asset tag identification can be encoded on an NFC tag to obtain asset condition information 2202 and visualization of recent data 2203. The information object 2203, with alarm data 2204 on HMI for example “excessive temperature increases over the last 5 minutes detected” can be represented in several time series embodiments after a database query -2305, as shown in Figure 23. The data processing unit 100 responds to the database query 2305 with data 2306 on the vessel asset 103, 2300. This data is presented 2202 in the HMI 2201 hosted on the mobile device 105. Depending on the asset health condition, an alarm 2204 may be raised based on operating ranges and visualized with specific HMI objects 2205.

[104] In summary, the disclosed system 150 (see Figure 1) provides a solution for: collecting real-time sensor data at high frequencies (up to 10000 samples per second) related to (but not limited to) main engine combustion and fuel consumption for vessels regardless of the engine manufacturer; extracting parameters related to combustion that depend on the processing of multiple metrics simultaneously, in real-time and on an ongoing basis for retrofit vessels; publishing this data in real time or near real-time to the shore via the cloud; continuous, automatic monitoring of engine performance and health using a rule-based algorithm to flag unusual or unexpected behaviour; two human machine interfaces (HMI) - a local, on-board HMI accessible on desktop and mobile and a remote HMI for desktop; o The HMIs provide an interface accessible to people other than the engine maker, such as vessel staff on board the vessel and on-shore that shows real time (on board) or near real time data (on-shore) for engine performance monitoring. They display alerts based on automatic and real-time monitoring of engine performance and health to on-shore personnel in real-time, and off-shore personnel in near real-time. Basic diagnosis of the triggered alerts is also displayed along with additional data and visualizations to enable the crew to diagnose and fix violated rules; o The on-board HMI enables the on-board users to provide feedback on the alert such as results from manual investigation and actions taken. The off-shore HMI displays this feedback to off-shore personnel in near-real-time; o The mobile version of the on-board HMI enables on-board users (technical crew) to interact, troubleshoot and discover engine (or other asset equipment) data in real-time, by directly inquiring the engine part/section via a QR, NFC or computer vision, providing details of any alerts that have been triggered, recent investigations carried out and actions taken, relevant to the part being queried;

• a method for retrofitting sensors in existing vessels that works for any 2-stroke internal combustion engine, irrespective of the manufacturer, and can be used to benchmark the performance of engines;

• compression and transmission of vessel data to on-shore staff in real time or near real-time, depending on the VSAT/LTE connectivity;

• processing of raw sensor data into meaningful metrics, and applying rules on multiple data streams of metrics simultaneously to alert the staff on-board the vessel in real time, and on shore in almost near real time (depending on VS AT connectivity coverage). We also transmit samples of raw data, computed metrics, triggered alerts and user feedback on alerts from vessel to the cloud to make this information available to on-shore personnel for visibility and to enable the development of more sophisticated performance and health monitoring algorithms such as those based on machine learning. There is downward deployment to update algorithms on the vessel via cloud, based on user feedback or any new information.

[105] In the application, unless specified otherwise, the terms "comprising", "comprise", and grammatical variants thereof, intended to represent "open" or "inclusive" language such that they include recited elements but also permit inclusion of additional, non-explicitly recited elements.

[106] While this invention has been described with reference to exemplary embodiments, it will be understood by those skilled in the art that various changes can be made and equivalents may be substituted for elements thereof, without departing from the spirit and scope of the invention. In addition, modification may be made to adapt the teachings of the invention to particular situations and materials, without departing from the essential scope of the invention. Thus, the invention is not limited to the particular examples that are disclosed in this specification, but encompasses all embodiments falling within the scope of the appended claims. Glossary of selected terms

Claims

1. A system for monitoring vessel part operation, the system comprising: a signal acquisition module to receive a plurality of data streams, each data stream being from a sensor monitoring performance of a vessel part; a data processing and analysis module coupled to the signal acquisition module, the data processing and analysis module configured to: analyse metrics extracted from the plurality of data streams for violation of one or more applicable rules, each rule establishing a threshold range for anomaly free performance of the monitored vessel part providing the analysed metric; and trigger an alert event providing details of the violated rules, in response to detection of violation of one or more of the rules; and a library storing rules establishing threshold ranges for anomaly free performance of vessel parts under different vessel operation conditions, to which the data processing and analysis module interrogates to obtain the one or more applicable rules.

2. The system of claim 1, wherein the plurality of data streams comprises readings from one or more of fuel consumption; airpath sensors, combustion sensors and cooling sensors.

3. The system of claim 2, wherein the metrics are directed at one or more of pressure; temperature; fluid flow; rotational speed; and relative angular position.

4. The system of claim 2 or 3, wherein the details comprise any one or more of a start and end time of each rule violation, the sensors and/or metrics for which rules were violated, the name of each of the violated rules, an indication whether the violated rules are related, a history of past violations for each of the violated rules and links to visual tools allowing assessment of the data streams that violate the rules.

5. The system of any one of the preceding claims, wherein the triggering of the alert event depends on the vessel operating condition and a degree of the violation, either or both applying on one or more of: a designated group of applicable rules being violated, an excessiveness of the violation of an applicable rule, whether a requirement for several instances of the violated rule to occur within a specified duration is present and met, and whether the manner in which the rules are violated characterise sensor failure.

6. The system of any one of the preceding claims, wherein details of one or more of the rules that are violated within a same interval are combined into a single alert event.

7. The system of any one of the preceding claims, further comprising a database, into which the data processing and analysis module is further configured to store a log of the alert events, the log being adapted for transmission.

8. The system of claim 7, wherein the data processing and analysis module is further configured to accompany the alert event with any one or more of: a prompt for investigation of one or more vessel parts related to the metrics for which one or more of the rules were violated; a prompt for documentation of an outcome of the investigation; and a prompt providing one or more corrective action suggestions, derived from one or more of the rules stored in the library.

9. The system of claim 8, wherein the data processing and analysis module is further configured to include in the log of the alert events stored in the database user input or non-action in response to the alert event and a duration of each of the alert events.

10. The system of any one of the preceding claims, wherein the threshold range for each rule is in respect of: a metric that is directly obtained from the data stream from a sensor monitoring performance of a vessel part; or a derived metric that is calculated from such directly obtained metrics.

11. The system of claim 10, wherein the derived metrics of a first order comprise any one or more of: pressure curve analysis, pressure difference across a vessel part, temperature difference across a vessel part, fuel oil consumption; and the derived metrics of a second order comprise any one or more of: deviation of a maximum pressure of each cylinder from the mean pressure over all cylinders, a difference in maximum pressure between any two cylinders, deviation of engine speed over a time window and deviation of engine load over a time window.

12. The system of any one of the preceding claims, wherein the threshold ranges are derived and/or updatable from any one or more of the vessel part manufacturer data, expert input and past data stream readings.

13. The system of any one of the preceding claims, wherein the signal acquisition module is further configured to pre-process the plurality of data streams, the pre-processing comprising any one or more of noise removal, application of rolling mean techniques and calculation of rolling standard deviation.

14. The system of any one of the preceding claims, further comprising a desktop interface to display any one or more of a status of the monitored vessel parts, the received plurality of data streams; notifications generated from the triggered alert event; wherein the desktop interface is further configured to receive user input in response to the generated notifications.

15. The system of claim 14, further comprising a portable interface with the same capabilities as the desktop interface, wherein the portable interface is further configured to allow querying of an operation status of any one of the monitored vessel parts when in proximity.

16. The system of any one of the preceding claims, further comprising a data uploader module to manage downloading of data into the vessel and uploading of data from the vessel, the data uploader module comprising a transceiver that facilitates the uploading and the downloading of the data.

17. The system of claim 16, wherein the data uploader module is configured to prioritise the upload of one or more of the following through the transceiver: portions of the data streams following data quality filtering; the extracted metrics from the plurality of data streams; the alert event and the user feedback on the alert event; and samples of high frequency raw data streams.

18. The system of claim 17, wherein upload of raw data from the plurality of data streams by the data uploader module has a lowest priority and is dependent on whether supportable by an upload bandwidth cap and a current upload speed.

19. The system of any one of the claims 16 to 18, wherein the data uploader module is configured to upload data, untransmitted from a previous session, upon detection of sufficient upload bandwidth and sufficient upload speed.

20. The system of any one of the claims 16 to 19, wherein the data uploader module is further configured to download updates to any one or more of the following: the rules stored in the library, and algorithms used to analyse the plurality of data streams to collect health data on the monitored vessel parts.

21. A vessel comprising the system of any one of the preceding claims.

22. A cloud comprising the system of any one of the claims 1 to 15.