Lombardy Champion - Zero-Hours Quality

At Whirlpool, statistical quality controls are done by the Zero Hours Quality department (ZHQ), where in-depth tests are performed on a significant sample of products as they leave the assembly line (Quality Gate). The objectives of ZHQ are to assess the average quality of the delivered product and to verify the correctness of the production process. Currently, ZHQ is implemented as a CPS where products under test are connected to a number of fixed workstations. Tests are driven by rules that are stored in a Factory database, and results are collected in the same storage facility.

The main problems with the current ZHQ implementation are physical constraints on the mobility of operators, per-station hardware costs, lack of integration with Factory and Corporate information systems, partial exploitation of data and hard-coded logic. The new-generation architecture developed in BEinCPPS leverages a lightweight Shopfloor infrastructure – based on a mix of custom-developed and commodity hardware on the product’s side (CPU and Power Board) and on Android mobile applications as the human-machine interface (HMI) – and a Cloud layer for cross-plant data storage and computationally-intensive data analysis tasks. The implementation of this new-generation design leverages the three BEinCPPS Platforms – i.e., SmartSystems, IoT and Future Internet – from which a selection of hardware and software components have been deployed across the three physical levels defined by the BEinCPPS Reference Architecture: Field, Factory and Cloud.

On the Field level, Whirlpool-specific hardware (Controller and Actuator boards) and software components (the Test Executor) are interconnected by the Deterministic Ethernet implementation (TSN by TTTech) provided by BEinCPPS’ SmartSystems Platform. A custom Android application on tablet devices (Test Front End) plays the HMI role. The Actuator board is custom-built on Whirlpool’s specs: its role is to interface the product under test, providing physical measurements to the Controller board and allowing the Controller board to operate and monitor the high-voltage appliance power supply. The Controller is a standard PC104 board that hosts a Windows operating system. The Controller runs the Test Executor software, which is a modified version of a legacy workstation-based application. The Test Executor embeds the local logic that drives the Actuator board: as the name implies, it executes test rules and collects results. In this new version, the software does not include the HMI and operates instead as a headless Field service that is exposed as an OPC-UA Address Space, thus enabling a tight integration of the Controller/Actuator bundle with the Factory and the Cloud levels. It is worth noting that the development of the OPC-UA Address Space used for in Whirlpool experimentation was entirely done by means of the UA Modeler tool, which is a Virtual World component.

The Field level is completed by peripherals that provide the physical connection with tested appliances and HMI functionality. One of them, the Bar-Code Reader, is directly plugged into the Controller board and is used for the fast identification of the product items under test. However, the key element of the system is the tablet device which provides the user’s Front End to three different applications: Test Operation, Test Results, and Rule Editor. All of them are Android applications that are developed in the scope of WP4, and are directly connected to the Cloud.

From an architectural perspective, however, the Test Front End belongs to the Field level, while the Results and Editor Front Ends are Factory level components, as their users play a different role in the ZHQ business process. In the new-generation ZHQ architecture, the Factory level is not merely a logical environment for the Result and Editor Front End mobile applications: its main role is to host the IDAS OPC UA Agent, which acts as a gateway between the Field and the Cloud levels. This component is a IoT Platform’s protocol adapter belonging to the Fast Lane – i.e., the FIWARE-based channel for Field-Factory-Cloud communications. The only customization required for the Whirlpool scenario is the configuration of specific mappings between the OPC-UA Address Space and the NGSI context used to publish and subscribe to the Field data stream. Such customization was easily done by editing a configuration file, and did not require any modification to the software.

Last but not least, the Cloud level is where most of the BEinCPPS value is delivered. This software layer is entirely deployed on external computing facilities. In this first iteration, this means the Common Cloud Environment (CCE) that is provided by the BEinCPPS project. The CCE hosts several components from the FI Platform: FIWARE Orion Context Broker, FIWARE Wirecloud, FIWARE Cosmos, FITMAN DyCEP and FITMAN CAM. Orion Context Broker is the middleware that provides publish/subscribe services using the NGSI standard, while Cosmos and DyCEP are generic Big Data Processing engines that run BEinCPPS-specific data analytics. In the context of the Lombardy demonstrator, Wirecloud is used as a provisional HMI to monitor the Field data flow during the execution of tests on appliances.