This paper introduces a suite of sophisticated software tools, developed in the context of the i4Q European project, and tailored for the white goods industry with a specific focus on dishwasher manufacturing. Employing artificial intelligence and data-driven methodologies, these tools automate quality control procedures during production, ensuring meticulous scrutiny of product quality conformity. The proposed tools aim to conduct full examination of the production, thereby enhancing the statistical relevance of conformity monitoring and reducing reliance on human labor for sampling, resulting in significant cost savings. Also, by minimizing the need for extensive investments in traditional factory laboratories, these solutions present a transformative opportunity for white goods manufacturers to enhance efficiency and reduce operational costs. This research explores the technological nuances of these AI-driven tools and their potential to redefine quality control paradigms in the context of white goods manufacturing and beyond.
centers, more than 1 billion investment and about 20 billion in sales. Whirlpool EMEA is a relevant part of this business producing and distributing around 20M appliances in a challenging business, with strong competition that can be dealt with only through cost and quality. Whirlpool EMEA counts 10 factories located between the UK, Italy, Slovakia and Poland and distribution/commercial channels all through Europe, covering 5 brands (Whirlpool, Indesit, Hotpoint, Bauknecht and Kitchen Aid).
Within quality management, product conformity verification is one of those which may have the higher benefit from structural data integration, envisioning the possibility to create a dynamic framework for the product's test.
AS-IS Business Process: Currently, the product conformity test is based on a statistical verification in the laboratory applied to pre-series products in case of new products introduction or of meaningful product changes. The products are selected randomly, according to specific and fixed percentages, and moved to dedicated labs, which test the marketing key features (e.g. energy consumption, capacity, product dimension, water consumption, performances, etc.). This phase is mandatory to proceed to mass production but it is, generally, not replicated during normal product lifecycle: due to test duration, these characteristics are, generally, not fit to be evaluated during the EoL functional test and may be, partially, addressed only through the so called zero-hour test, that is still on statistical base but focused only on some of these features.
The main challenge of the Whirlpool use case is virtualizing some manual testing operations. This virtualization relies on the hypothesis that product conformity on all (or a subset) performance parameters can be inferred by the analysis of data gathered along the production line. Datasets: Five different databases, from the Quality Control process, have been analyzed. The analysis and interpretation of the data sets has been crucial to identifying the relevant parameters that allow the predictive quality control along the manufacturing process. The datasets used are: 1. CPM (Critical Parameters Management): it contains detailed results of product tests performed on a sample basis of production. 2. EOL (End of line): it contains the result of the End-Of-Line functional test, which is performed on each product produced. 3. SPC (Statistical Process Control): it contains the results of Statistical Process Control executed in the primary process department on critical parts internally produced (e.g. the tub). 4. SR (Short-term reliability) Lab: it contains the results of the Short-term Reliability Laboratory where a statistical test on several quality aspects and executed on the finished product (e.g. aesthetical control, main functionalities, etc.). 5. LR (Long-term Reliability) Lab: it contains the results of the Long-term Reliability Laboratory where a statistical test on several other quality aspects, which are related to durability and performance stability, and executed on the finished product (e.g. door opening resistance, etc.). TO-BE Scenario: In the TO-BE scenario the physical test is substituted by a Virtual Test performed by an AI enabled set of i4Q solutions. The i4Q Virtual Test has these advantages: ● Can be performed on 100% of production, improving the statistical relevance of conformity monitoring; ● Can speed up the process of alerting, allowing to take decisions faster; ● Can reduce the amount of sampling with a significant cost reduction in Human Labor; ● Can reduce the investment in factory laboratory equipment.
The virtual test system is expected to generate prediction of potential non-conformity on all the production and keep track of the results: these data will be used to generate automatic alerts to the Central Quality Team that will help decision makers on final actions about the products.
As part of the i4Q Project, the technical partners of consortium (ENG, CERTH, UNINOVA, ITI) have developed a series of individual solutions to meet the primary goals outlined by Whirlpool. These solutions consist of standalone microservice applications designed to efficiently manage, process, and analyze historical and real-time manufacturing data, with primary objective being the provision of insights and alerts product and manufacturing quality control processes.
The i4Q solution suite aims to deliver a set of versatile and interoperable tools that are intended to seamlessly integrate with existing legacy data acquisition systems and infrastructure analytics systems, enhancing the overall compatibility and efficiency within the manufacturing environments.
In summary, the i4Q contribution lies in the realization of a set of i4Q solutions that will: 1. Employ machine learning prediction mechanisms that exploit historical data associated with each product under production, to correlate them with their respective conformity potential. The developed supervised machine learning models will be assisted by an extensive availability of proven correlations already studied and experimented in Whirlpool; 2. Embed the inferring algorithm in a system that will be used in production: after the final phase of production (End-of-Life testing), all the relevant data gathered during assembly will be evaluated to predict the conformity of the products under test. The results of this analysis will automatically be stored and made available through a database for further study; 3. Analyse the Virtual Test results and, according to some rules (imposed by the user and the predictive system), will trigger an alert to the decision tree that will act according to the BP; 4. Provide a Data Visualization and Analytical tool that will support the Quality Task Force in decision making processes.
Figure 1 depicts the pipeline of i4Q solutions that has been put in place for Whirlpool Pilot. The pipeline is divided into two tiers that respectively focus on different aspects and purposes based on deployment scenario:
Edge tier focuses on the collection, the cleaning and the analysis of data coming from the field to develop AI models; Cloud Tier focuses on the execution of above-mentioned models on production data in Cloud.
The i4Q solutions that were tested and integrated in the Whirlpool environment are: ● i4QDR Data Repository: containing results of prediction and normalized data from legacy system. ● i4QDIT Data Integration and Transformation Services: to interface legacy data and provide basic services such as cleaning, normalization ● i4QDA Services for Data Analytics: to perform learning and deep learning on the dataset in input and embed the prediction engine. ● i4QBDA Big Data Analytics Suite: to provide tech mechanism to run efficiently data analytics. ● i4QAD Analytics Dashboard: to visualize and analyze both legacy data and results of predictions ● i4QIM Infrastructure Monitoring: to provide monitoring tools and predictive failure alerting mechanisms to inform machine operators.
In this context, we will focus only on the main solutions that produced a tangible output, leaving aside the solutions that only contributed through intermediate steps.
Before delving into the analysis of industrial data, it is crucial to establish a clearly defined and standardized data schema. This schema should encompass all the necessary information required to make accurate predictions regarding the quality of the production process. This requirement is met with the introduction of the “i4Q Data Integration and Transformation Services” (i4QDIT) solution. The i4QDIT solution offers a platform dedicated to the streamlined processing of manufacturing data, and includes crucial features for handling data streams, such as reading, cleaning, storing, indexing, enriching, while ensuring seamless compatibility with APIs. The solution provides a range of preprocessing functions that convert the intricate raw data from manufacturing processes into formats suitable for subsequent analysis. In the case of the data pertaining the EOL product testing, the provided information was fragmented and organised into distinct data catalogues. Therefore, the i4QDIT was utilised to harmonise the available data to create a consistent unified dataset containing all the necessary sensor information (temperature, voltage, power, current, etc.), that adheres to a standardized format. Due to the high data collection frequency, many measurements were redundant, and thus processing scripts for rolling window mean estimations were used, transforming the collected sensor values into a more manageable size and form. Following the merging of the initial data catalogues, several data pre-processing techniques were employed to correlate data fields, to resolve missing values, and to enrich the dataset with descriptive analytics. The i4QDIT solution was also responsible for the examination of the SPC data through pre-processing and analytics steps. These steps encompass functions for eliminating incorrect entries, merging data based on a key feature and generating boxplots to verify, via descriptive analysis, if the variables of interest are inside the desired limits set by Whirlpool.
Following the i4QDIT, the resulting pre-processed EOL data are being exploited through the “i4Q
Infrastructure Monitoring” (i4QIM) solution for further analysis, to unearth the latent information that
explain the correlation between sensor signals and the manifestation of a product quality problem.
In order to achieve an accurate detection of quality conformity, the i4QIM solution employs a Light
Gradient Boosting Machine (LGBM) model, which is scalable and efficient framework constructed
upon an ensemble of tree-based classifiers [
In the end, once the LGBM classifier training concluded, the model was handed over to i4QDA for execution on historical data directly retrieved from WHR Google Cloud Platform. The results were then showcased on the provided i4QAD dashboard.
In i4Q Project, one of the main challenges, above the definition of the proper pipeline of solution to reach the pilot’s goal, was the deployment and the integration of the abovementioned pipeline. In Whirlpool case, in particular, the main challenge has been the shift of orchestration paradigm from Docker to Kubernetes as Whirlpool is relying on Google Cloud Platform for their cloud infrastructure, and more specifically on Google Kubernetes Engine.
Google Kubernetes Engine (GKE): GKE is a managed Kubernetes service provided by Google Cloud that abstracts the complexities of deploying, managing, and scaling containerized applications using Kubernetes. On the other hand, i4Q solutions were meant to be deployed using Docker Compose. While Docker Compose let you define and run multi-container applications with ease, it lacks the advanced features and scalability of a full-fledged orchestration platform like Kubernetes as well as some other critical features in production environments like high availability and zero down-time. Migrating Docker containers to a Kubernetes (K8s) cluster is a complex process that forced us to face many challenges during the migration: ● Orchestration Paradigm Shift: While Docker containers are usually orchestrated using Docker Compose, Kubernetes follows a totally different orchestration model that involved a shift in mindset from single-host orchestration to a cluster-based approach as well as facing of a steeper learning curve, compared to Docker. ● Networking Challenges: Docker containers typically communicate through Docker's internal bridge network, while Kubernetes uses its networking model which is way more complex and powerful (in terms of functionalities offered). Ensuring proper communication and handling network policies between containers in a Kubernetes cluster required a strict collaboration between Engineering and Whirlpool’s IT Department as network rules and firewalls needed to be defined to ensure compliance to WHR’s security policies. ● Persistent Storage: Docker and Kubernetes handle persistent storage differently. Migrating applications with persistent data requires reconfiguring storage solutions to fit Kubernetes standards. This involved defining storage classes, volume mounts and storage providers to properly fit a cluster-based implementation with data servers dislocated across Europe. ● Resource Definitions: Kubernetes uses a different resource model for defining CPU and memory limits, compared to Docker, that lets you exploit auto-scaling functionalities. This is possible by implementing HPAs (Horizontal Pod Autoscaler) and VPAs (Vertical Pod Autoscaler) that automatically scale up and down both pods and nodes of the cluster following the resource specifications defined in the manifest file of each deployment. ● Container Images and Registries: While Docker images can be used in Kubernetes, tools like Helm let you manage Kubernetes Charts with ease. Charts are a collection of files that describe a related set of Kubernetes resources. A single chart might be used to deploy something simple, like a memcached pod, or something complex, like a full web app stack with HTTP servers, databases. In our case, Helm Charts came in handy as they let us configure a particularly difficult stack of services (e.g.: Data Analytics solution) with some more ease. ● Integration with GCP: Finally, Whirlpool hosts its services and stores its data on GCP thus to make the integration seamless and be able to fetch data directly from production processes we had to develop a custom component that relies on Service Account to fetch data from views defined in BigQuery.
Thanks to i4Q Solutions it has been possible to build the patterns that end on quality or process issues and to identify the relations among the variables and data. Moreover, the implemented system can receive, store, and serve the data properly to the other components in the architecture. And the visual analytics tools provided can be easily used by the end users.
The proactive approach to Quality ensured by i4Q RIDS will enable the possibility to predict quality issues and then anticipate the root cause analyst to definitively address and solve them. This solution will then in the long term enable the possibility to eliminate statistical control in the various phases of the product life cycle with a strong impact in terms of cost and process efficiency.
In terms of the transformation process, the expected output is a prediction of bad quality which is communicated in real time to the product manager in order to properly set up detection and mitigation plans. The output is then represented by a forecast of defects with a related accuracy for any product which is in the production scope. All the above-mentioned benefits will impact the Whirlpool Quality KPIs; in particular, to increase the number of finished goods without reprocessing, to reduce the number of potentially faulty and defective appliances, to reduce number of Service Interventions in 1st month, to reduce the number of negative feedbacks, to reduce the expenses and capital used for quality control and reprocessing, to reduce the time to go to regime production, to reduce the time to introduce new product on the market, to increase accuracy in predicting any defect.
The author(s) have not employed any Generative AI tools.