Blog

Limit Checking for fault detection in Photovoltaic plants

Limit checking of measured variables in a monitored system is a method frequently used for fault detection. 3E uses it as a first step on its protocol of fault detection and diagnosis to know at which stage of a Photovoltaic plant actions need to be taken before any further deep analysis on the characteristics of the problems. Here, 3E illustrates the methodology used to apply it in their use case.

Photovoltaic (PV) plants are energy conversion systems which convert sunlight into electricity that is fed into the public utility grid. The physical structure and the important process variables of a PV plant measured when monitoring the performance of a photovoltaic (PV) plant are illustrated in Figure 1. The input variables of the process model are: the solar irradiance in the plane of the PV array (GPOA) and the ambient temperature (Tamb). Output variables from the process model point of view are: the PV module temperature (Tmod); the Direct Current voltage(VDC) and current (IDC) at the output of the PV array; the Alternating Current voltage (VAC); the power factor (PF); and the electric AC power to the grid (PAC).

Energy flow in a grid-connected photovoltaic system
Figure 1: Energy flow in a grid-connected photovoltaic system

 

Implementation

Normalized performance parameters can be derived from the previously mentioned measurements and allow to quantify the energy flow and losses through the PV array per loss type. They are:

LA,I=YrYA, 

LA,T=YA,IYA,T

LA,V = YA,TYA

with LA,I, LA,T, LA,V, the conversion losses due to current, temperature and voltage, respectively and Yr, YA,I, YA,T, YA the normalized energy yield from reference yield (based on irradiation from the sun), array yield after current losses, array yield after temperature losses and array yield after all array losses, respectively.

The main variables used for limit checking are solar irradiance in the plane of the PV array (GPOA), ambient temperature (Tamb), PV module temperature (Tmod), DC voltage and current at the output of the PV array (VDC, IDC) and electric AC power to the grid (PAC). The AC voltage (VAC) and power factor (PF) are not used for limit checking.

For checking the operational performance over different energy conversion steps, a performance loss ratio per step is defined. This performance loss ratio is computed for a given time span, e.g., a day up to several months. It is the useful energy lost over the energy conversion step divided by the energy available, i.e. the incoming solar energy on the PV array as represented by the solar irradiance in the plane of the PV array (GPOA); all normalized to standard rating conditions of the PV array. Accordingly, the overall performance of a PV plant is described by the performance ratio (PR), i.e., 100% minus the sum of all performance losses.

In practice, we compare the performance loss ratios from measurements to model-based performance loss ratios and thresholds. The model is fed with measured values of GPOA and Tamb. The model parameters can be set from data sheet parameters of the devices in the PV plant or identified from measurements from the plant in a healthy state. Accordingly, adequate limits can be derived either from tolerances on the data sheet parameters or from choosing percentiles from the healthy plant. Both the model-based performance loss ratios and their limit values vary depending on the PV plant and the weather during the evaluation period.

Example of limit checking results for the energy conversion process in a PV plant before and after the maintenance action; performance loss ratios per conversion step are compared to the model for each conversion step
Figure 2. Example of limit checking results for the energy conversion process in a PV plant before and after the maintenance action; performance loss ratios per conversion step are compared to the model for each conversion step

 

Figure 2 illustrates this application of limit checking for a PV plant located in Belgium. The current-related array losses (‘Array (current)’) in Figure 2a by far exceed the threshold. During a thorough maintenance action after this problem was detected, several smaller PV module failures were fixed. After maintenance action, all performance loss ratios were back within their expected ranges, yielding a much higher PR of 82.9% (Figure 2b).

Exploiting intelligent data-driven technologies for failure detection and root-cause analysis: The Belgian work on MANTIS

In the frame of Mantis, the three Belgian partners (Sirris, Ilias Solutions and 3E) focused their work on exploiting intelligent data-driven technologies for failure detection and root-cause analysis. In this video we will show the work done and the results obtained within the Mantis project by the Belgian consortium:

Sheet Metal Working Machinery Use Case: Predictive Maintenance

Context

This use case studied the analysis of sensor data from a brake press in order to facilitate its maintenance. Brake forming is the process of deforming a sheet of metal along an axis by pressing it between clamps. A single sheet metal may be subject to a sequence of bends resulting in complex metal parts such as electrical lighting posts and metal cabinets.

These machines require very accurate control so as to ensure the required bending precision that is in the order of tens of microns. They have stringent safety requirements that also impose certain restriction on its operation. In addition to this, the production efficiency is also a very important factor in its operation.

Objectives

In order to ensure production quality under these stringent requirements, it is important to make sure that all of the machines’ components are in perfect working order. The goal of this use case in the MANTIS project is to use a set of sensors to detect failures and then inform the maintenance staff of these events. In this work we used a top of the line Greenbender model to implement and test a system that could accomplish these goals.

The Team

A multi-disciplinary team participated in the research and development of this use case. The use case owner is the machine tool manufacturer ADIRA that sells machines worldwide. ADIRA’s main goal is to improve the maintenance services they provide to their customers.

The researchers team consist of:

Research and development in the area of communications was jointly done by ISEP and UNINOVA. This included the IoT architecture, sensors, communication’s hardware and infrastructure deployment. Data processing and analytics was performed by INESC and ISEP. INESC focused on root cause analysis (RCA), remaining useful life (RUL) forecasting and anomaly detection. ISEP worked on knowledge based techniques for failure detection by developing and testing a decision support system. In addition to this ISEP also developed a Human Machine Interface (HMI) application that provides access to IoT infrastructure and several MANTIS services, which includes the notification of failures.

JSI and XLAB also provided valuable input and feedback concerning the initial research and design tasks of the communications infrastructure (real time data transmission) and the HMI (usability).

Results

The MANTIS project has provided INESC with the opportunity to research, test and apply machine learning techniques in a real-world setting. Tasks included the detailed study of the machine tools’ processes and components, eliciting requirements and information from the domain experts and evaluating several machine learning algorithms. Due to the many challenges that were faced in identifying, collecting and using sensor data, only anomaly detection is currently being deployed in this use case.

A set of 11 conditions are being continually monitored for anomalies. For each anomaly two thresholds are being used to identify respectively small and large deviations from the expected behavior. Whenever such a deviation is detected, an alert is dispatched to the HMI where the users are notified. These monitoring conditions should allow ADIRA to detect failures in the hydraulic system, numeric controller and several electric components. In addition to this, oil temperature and machine vibrations are also being monitored.

The MANTIS system, which includes INESC’s analytics module, has been deployed as a set of services in the Cloud. Initial tests show good false positive rates. We are now in the process of performing on-line evaluations of the detection rates. We are confident that these results will serve as an important firsts step for ADIRA to enhance its products by using more sophisticated and effective data analytics methods.

MANTIS: Conventional Energy Production Use-Case

The Finnish use-case under the MANTIS project concentrates on proactive maintenance solutions in the field of conventional energy production. The industry is moving towards smaller distributed plants with less on-site staff and thus, the ability to deploy conventional CBM strategies has declined. However, availability is still a major factor in power generation efficiency and plant feasibility. Therefore, new kind of energy production asset maintenance solutions applicable also for less critical components are required.

Five industrial and academic partners, namely Fortum, Lapland University of Applied Sciences (LUAS), Nome, VTT and Wapice, form the Finnish consortium in the MANTIS project. The Finnish use-case of conventional energy production is centered on a flue gas blower in Fortum’s Järvenpää power plant. Power plants have a large array of rotating machinery, whose reliability greatly affect on the overall reliability of the plant. As such, the blower offers a valid testing environment for collaborative maintenance solutions developed by the Finnish partners. The blower has been instrumented with vibration sensors, virtual sensors and local data collectors provided by Nome, Wapice and VTT. The measurement data is stored in the MIMOSA data model based MANTIS database via REST interface developed by LUAS. The collected data can be distributed to individual systems across organizational boundaries for analysis purposes. The partners of the conventional energy production use-case have integrated their own analytic tools, such as Fortum’s TOPi, Nome’s NMAS and Wapice’s IoT-Ticket, to the MANTIS database, as illustrated in figure 1, and tested the system architecture successfully in practice.

Pilot structure of the conventional energy production use-case
Pilot structure of the conventional energy production use-case

The MANTIS project has offered a great opportunity for the conventional energy production use-case partners to develop their own HMIs that can be integrated to different fields of proactive maintenance. The development work continues in the third and last phase of the MANTIS project, as some advanced visualization approaches, including virtual reality and augmented reality applications, are piloted and integrated to the HMIs. The piloted cloud architecture from Fortum’s Järvenpää power plant will also be tested in larger scale in another entire power plant. The data collection will be extended to cover a wider range of equipment and process variables to enable plant-wide monitoring of assets and proactive maintenance strategies. In addition, the partners are developing their analytic tools further to  provide solutions capable of diagnostics and prognostics required in advanced maintenance.

 

MANTIS Consortium Meeting at SIRRIS (Ghent, Belgium)

As we do very 4 months, we had a new consortium meeting in January. This time we met at the beautiful Ghent city, and were fantastically hosted by our partner SIRRIS.

Mantis Meeting participants
Mantis Meeting participants

We are approaching to the end of the project, and thus, decided not to make more parallel sessions, so everyone would perfectly be aware of the activities of all Work Packages. Also, the Open Sessions, where we always showroom our last developments in an interactive way, showed no posters but plenty of live demos.

 

MANTIS-OpenSpace
MANTIS-OpenSpace
Open Session - MANTIS
Open Session – MANTIS

Of course, we continue working hard till the end of April!

MANTIS-Meeting
MANTIS-Meeting

Next, and last meeting, in Budapest, hosted by BMU & AITIA!

 

Clustering machines based on event logs within the MANTIS project

Introduction

Liebherr participates in the MANTIS project as an industrial partner with the division Liebherr hydraulic excavators. As expected, the main expertise of Liebherr consists in developing and optimizing excavators under consideration of different information sources. However, after the delivery of the excavator to the customer, every excavator generates event respectively message data automatically, which are actually mainly used for fault diagnostics but not extensively for further investigations.

This event data logger records among other things basically:

  • timestamp, when an event occurs
  • type of event, e.g. info, warning or error
  • unique message identifier of this event class

In combination with anonymized data concerning service partner and customer the following questions are relevant:

  • Is there a relation between the message patterns and the corresponding anonymized service partner?
  • Is there a relation between the message patterns and the anonymized customer?

Analysis approach for clustering

The related analysis was performed by the University of Groningen (RUG) as a research partner within the MANTIS project by considering each excavator as a stochastic message generator. In the context of preprocessing, the different messages were first counted per excavator and afterwards normalized with the total amount of occurrence per unique message identifier.

Based on the computed message probabilities per machine a k-means clustering was performed. To overcome initialization influences the clustering was performed 100 times with random initialization. The relationship of the cluster assignment of each excavator with the corresponding service partner or customer for each ‘k’ was subsequently examined with the chi-square test. The average estimate of the significance of the 100 model estimations of each ‘k’ then represented the quality function.

Results of cluster analysis

As can be seen in figure 1, there is no tendency for a relationship between the service partner and the messages per excavator. The average significance level is obviously higher than 0.05 and all of the single levels have nearly the same magnitude.

Average p-significance levels as a function of k (number of groups), for the interaction clusters versus service partner
Average p-significance levels as a function of k (number of groups), for the interaction clusters versus service partner

In contrast to figure 1, figure 2 shows a clear minimum at k=7, indicating that for this number of groups, it is likely that the distribution of machines over customers is not likely to be random. Although the p_signif – value is with 0.0588 slightly above the significance level of 0.05, the magnitude at k=7 is obviously lower than at other k-values.

 

Average p-significance levels as a function of k (number of groups) for the interaction clusters versus customers.
Average p-significance levels as a function of k (number of groups) for the interaction clusters versus customers.

In order to explain the minimum at k = 7, Liebherr decoded the anonymized customers and tried to find manually a description of the clusters. The cumbersome work did actually not yield to the expected result, namely the detection of short cluster descriptions, but rather to the recognition of customer data mismatching.

In summary the carried out analysis pointed out, that with the skillful usage of analysis algorithms superficial unmanageable data can disclose insights. But one of the basic requirements for later usage of the results is the proper preparation of data.

General methodology of asset usage profiling for proactive maintenance prediction

When analysing sensor data, you are typically confronted with different challenges relating to data quality. Here, we show you how these challenges can be dealt with and how we derive some initial insights from cleaned data via exploration techniques such as clustering.

Nowadays, especially with the advent of the Internet of Things (IoT), large quantities of sensor data are collected. Small sensors can be easily installed, on multipurpose industrial vehicles for instance, in order to measure a vast range of parameters. The collected data can serve many purposes, e.g. to predict system maintenance. However, when analysing it, you are typically confronted with different challenges relating to data quality, e.g. unrealistic or missing values, outliers, correlations and other typical and a-typical obstacles. The aim of this article is to show how these challenges can be dealt with and how we derive some initial insights from cleaned data via exploration techniques such as clustering.

Within the MANTIS project, Sirris is developing a general methodology that can be used to explore sensor data from a fleet of industrial assets. The main goal of the methodology is to profile asset usages, i.e. define separate groups of usages that share common characteristics. This can help experts to identify potential problems, which are not visually observable, when the resulting profiles are compared with the expected behaviour of the assets and when anomalies are detected.

In this article, we will describe the methodology of asset usage profiling for proactive maintenance prediction. The data used in this article is confidential and anonymised; we therefore cannot describe it in detail. It mainly consists of duration and resource consumption as well as a range of parameters measured via different sensors. For our analysis, we used Jupyter Notebook with appropriate libraries such as pandas, scipy and scikit-learn.

Data preparation

Sometimes data can be polluted, as it is collected from different sources and can contain duplicates, wrong values, empties and outliers, which should all be considered carefully. Therefore, the first natural step is to conduct an initial exploration of the data and to prepare a single reference dataset for advanced analysis, by cleaning the data, by means of visual and statistical methods, then by selecting the right attributes you wish to work with further.

In our example dataset, we find negative or zero-resource consumption, a situation that is obviously impossible, as shown in Figure 1. In our case, since there are few outliers of this type, we simply remove them from the dataset.

Figure 1 Zero or negative consumption

Another possible example is that of an erroneous date in the data. For example, dates may be too old compared to the rest of your dataset; future dates can even exist. Your decision to maintain, fix or remove wrong instances can depend on many factors, such as how big your dataset is, whether an erroneous date is very important at the current stage, etc. In our case, we maintain these instances since, at this moment, the date is not important for analysis and the percentage of this subset is very low.

Outliers are extreme values that deviate sufficiently from other observations and also need to be dealt with carefully. They can be detected visually and using statistical means. Sometimes we can simply remove them, sometimes we want to analyse them thoroughly. Visualising the data directly reveals some potential outliers; refer to the point in the upper right-hand corner in Figure 2. In our case, such high values for duration and consumption are impossible, as shown in Figure 3. Since it is the first record for this type of asset, it may have been entered manually for test purposes; we consequently choose to remove it.

Figure 2 Visual check for outliers

Figure 3 Impossible data

In Figure 4, we can see a positive linear correlation between consumption and duration, which is to be expected, although we still may find some outliers using the 3-sigma rule. This rule states that, for the normal distribution, approximately 99.7 percent of observations lie within 3 standard deviations of the mean. Then, based on Chebyshev’s Inequality, even in the case of non-normally distributed data, at least 88.8 percent of cases fall within 3-sigma intervals. Thus, we consider observations beyond 3-sigmas as outliers.

Figure 4 Data after cleaning

In Figure 5, we see that our data is quite normal, centred around 0, most values lying between -2 and 2. This means that the 3-sigma rule will show us more accurate results. You must normalise your data before applying this rule.

Figure 5 Distribution of normalised consumption/s

Results are shown in Figure 6. The reason for such a significant deviation from the average in consumption and duration of certain usages is to be discussed with a domain expert. One instance with very low consumption for a long duration raises particular questions (Figure 7).

Figure 6 3-sigma rule applied to normalised data

Figure 7 Very low consumption for its duration

Advanced data exploration

As previously stated, we are looking to profile asset usages in order to identify abnormal behaviour and therefore, along with duration and resource consumption, we also need to investigate the operational sensor data for each asset. This requires us to define groups of usages that share common characteristics; however, before doing so, we need to select a representative subset of data with the right sensors.

From the preliminary analysis, we observed that the number of sensors can differ between the assets and even between usages for the same asset. Therefore, for later modelling we need to exclusively select usages which always contain the same sensors, i.e. training a model requires vectors of the same length. To achieve this, we can use the following approach, as illustrated in Figure 8.

Figure 8 Selecting sensors

Each asset has a number of sensors that can differ from usage to usage, i.e. some modules can be removed or installed on the asset. Thus, we need to check the presence of these sensors across the whole dataset. Then, we select all usages with sensors that are present above a certain percentage, e.g. 95 percent, in the whole dataset. Let’s assume our dataset contains 17 sensors that are present in 95 percent of all usages. We select these sensors and discard those with lower presence percentages. This way, we create a vector of sensors of length 17. Since we decided to include sensors if they are 95 percent present, a limited number of usages may still be selected although they do not contain some of the selected sensors, i.e. you introduce gaps which are marked in yellow in the figure. To fix these gaps, you can either discard these usages or attribute values for missing sensors. Attributing can be complex, as you need to know what these sensors mean and how they are configured. In our case, these details are anonymised and these usages are consequently discarded. You may need to lower your presence percentage criteria in order to keep a sufficiently representative dataset for further analysis.

After the optimal subset is selected, we check the correlation of the remaining sensors. We do this because we want to remove redundant information and to simplify and speed up our calculations. Plotting a heatmap is a good way of visualising correlation. We do this for the remaining sensors as shown in Figure 9.

Figure 9 Sensor correlation heatmap

In our case, we have 17 sensors from which we select only 7 uncorrelated sensors and plot a scatter matrix, a second visualisation technique which allows us to view more details on the data. Refer to Figure 10.

Figure 10 Scatterplot matrix of uncorrelated sensors

Based on the selected sensors, we now try to characterise different usages for each asset, i.e. we can group usages across the assets based on their sensor values and, in this way, derive a profile for each group. To do this, we first apply hierarchical clustering to group the usages and plot the resulting dendrogram. Hierarchical clustering helps to identify the inner structure of the data and the dendrogram is a binary tree representation of the clustering result. Refer to Figure 11.

Figure 11 Dendrogram

On this graph, below distance 2 we see smaller clusters that are grouping ever closer to each other. Hence, we decide to split the data into 5 different clusters. You can also use silhouette analysis for selecting the best number of clusters.

In order to interpret the clustering, we also want to visualize them, but 7 sensors mean 7 dimensions and because we can’t plot in multidimensional space or it is too complex, we apply Principal Component Analysis or simply PCA in order to reduce the number of dimensions to 2. This allows us to visualize the results of clustering, which is shown on Figure 12. Good clustering means that clusters should be more or less well separated, i.e. similar colours are close to one another or not mixed too much with other colours, and this is what we also see in the figure.

Figure 12 PCA plot

After the clustering is complete, we can characterise usages. This can be done using different strategies. The simple method consists in taking the mean of the sensor values for each cluster (i.e. we calculate a centroid) to define a representative usage.

The last step involves validating the clusters. We can cross-check clustering with the consumption/duration of usages. For instance, we may expect all outliers to fall within one specific cluster, or expect some other more or less obvious patterns, hence rendering our clusters meaningful. In Figure 13 below, we can observe that the 5 clusters, i.e. 5 types of usages, correspond, to an extent but not entirely, to consumption/duration behaviour. We can see purple spots at the bottom and green spots at the top.

 

Figure 13 Relationship between clusters and consumption/duration

Conclusion

At this stage, some interesting outliers were detected in consumption/duration relationships, which can be stressed with the objectives the assets were used for. We have found clusters that represent typical usages according to data. Result validation can be improved by integrating additional data, such as maintenance data, into analysis. Furthermore, results can be validated and confidently concluded by the domain experts from Ilias Solutions, the industrial partner we are supporting for their data exploitation.

 

Contact: andriy.zubaliy@sirris.be

Providing reliability of components to customers with the MANTIS Maintenance Architecture

Goizper S. Coop., smart components’ manufacturer

Goizper S. Coop’s products are mechanical components (clutch brakes, gear boxes, indexing units…) installed within different kind of productive machines. These machines are designed to produce continuously and unplanned downtimes generate high costs. These components are the key part of some of the mentioned productive machines and the relevant component’s health influences directly within the machine status.

Clutch Brake Component located within a mechanical press machine

Breakdown of Components

Furthermore, if one of these components fails, it takes a long time while a new one is sent to the customer’s facilities, removed the old one and set up the new one. In these cases, the production asset maintenance means lot of expenses for customers and suppliers.

MANTIS for predictive maintenance

MANTIS platform provides an online and future view of these components’ health. Smart sensors installed at the mechanical component are connected to Monitoring and Alerting, which is performed automatically, within the smart-G box located next to the mechanical component. Then, this Big Data is processed in the Cloud and through different Maintenance data analytics the status and future trend of the component health is obtained as an output.

Smart-G box and rotary union with sensors

Obviously, the introduction of this Cyber Physical System will not eliminate all machine breakdowns, but it will help in order to reduce considerably machine unplanned downtimes, so that the customer and supplier will be able to plan their maintenance tasks and reduce these kind of stops.

MANTIS Collaboration

Within the MANTIS ECSEL project, Goizper has collaborated close to one of its customers, Fagor Arrasate, trying to improve the real inconveniences and reduce expenses that unplanned downtimes cause in both firms.