WZL x GCX x IOTA — Status Report 01
About data acquisition and first transactions
Co-Authors: Semjon Becker, Sascha Kamps and Philipp Niemietz.
What’s this PoC about?
The subject of this Proof of Concept (PoC) is an industrial fineblanking machine type XFT 2500 speed from Feintool AG. Fineblanking is a metal cutting process designed for mass production, e.g. for the manufacturing of brake calliper carriers or belt straps. Fineblanked components thus often perform safety-relevant tasks, e.g. in automobiles. The following video shows the fineblanking machine, consisting of a decoiler, a leveler, a lubrication unit, and the press, as well as the press’ process kinematics during blanking.
Due to physical material fluctuations and process uncertainties, it is statistically impossible to produce components with identical metallurgical and geometrical properties. Although all components have to meet the same requirements, not all components can withstand these loads due to their individual properties. However, if it were possible to create a digital twin of the components and make this individual information publicly available, suppliers could adapt their downstream steps to specific components and increase end customers’ confidence in these components, assemblies or products.
The goal of this PoC is to extract production data of fineblanked components from the machine control in real time, store them encrypted in the tangle and retrieve them via a web-based frontend. The PoC is limited to selected data, such as the blanking force, the press stroke or the material name.
Focus of this article and sneak peek of the results
This article focuses on data acquisition as the first and most crucial step. But additionally some real test transactions are already stored in the official testnet. The following video shows that for each part produced a data set is queued firstly and then stored in the tangle.
Architecture of the PoC
The concept of the PoC is that any machine, in this case the Feintool press, has a protected MAM channel. Each part produced then adds a message to the MAM channel containing signed information related to its creation. Additionally, the raw data is stored in a seperate database. The recipient of the produced parts can read each message via an easy-to-use web interface and check the integrity of the data via the MAM channel.
Data Acquistion
An important prerequisite for setting up the proof of concept is the interoperability of the solution. The WZL uses piezoelectric sensors from Kistler to measure static and dynamic process forces. Force sensor type Kistler 9021A (Link) is used for the blankholder, type Kistler 9041A (Link) for the punch, and type Kistler 9031A (Link) for the counterpunch. Reaction forces measured by force sensors are the most important parameter for evaluating processes and machine characteristics.
Hardware
The Kistler LabAmp laboratory charge amplifier type 5167A (Link) was selected as the data acquisition device for the PoC. The amplifier has an integrated network interface which allows the acquisition of sensor data via a network stream. The data can be used for different applications in parallel to normal test operation. In addition, all sensors with analog voltage output and Integrated Electronics Piezo-Electric (IEPE) mode can be connected. The hardware is used worldwide in numerous application areas such as automotive, industrial process control and for many special applications, such as the examination of satellites or the construction of crash walls for high-speed trains.
Software
The developed software can be easily adapted to other manufacturers via easily interchangeable drivers and provides a broad platform for solving real world problems. Using LabVIEW 2018 by National Instruments as a graphical programming language provides a rich ecosystem. This LabVIEW ecosystem includes more than hundreds of thousands of developers and thousands of device drivers via the connected Instrument Driver Network. LabVIEW also works on Windows, Linux, Mac OS, Field-programmable gate arrays (FPGA) and real-time devices and is compatible with other modeling languages such as Matlab or Python. This allows high interoperability to solve real world problems with IOTA.
Signal processing
The data acquisition software connects to the device and reads unique data, which is assigned only once for each device, for example the serial numbers of various components. These properties together form a digital fingerprint. In the second step, the incoming sensor data is analyzed and identified via analog triggers. The following figure shows the full complexity of the process. In a very short period of time (0.5 s) , several forces act in the tool, all of which take on a defined task. With the aid of the addressed triggers, only the punch force is traced automatically and the punch stroke is also recorded.
The resulting signal is then transferred to the analysis queue together with other variables as a data set. This ensures that data acquisition continues in the background, even if the analysis would take longer than a single process. In the analysis, corresponding characteristic values such as the maximum force are extracted. A checksum is formed from all data together with the unique fingerprint and the private seed to ensure a high level of protection against manipulation. The raw data and characteristic values are also saved as a .json-file.
First transactions
To ensure that all processes are stored in the tangle, the hashs are transferred to Python via another queue. The data records are generated every second in a fineblanking system. However, calculating the Proof-of-Work on the device takes considerably more time and fills up the queue. During production breaks when material or tools are exchanged, the queue can be processed and written to the tangle with PyOTA (not using MAM for that test).
Testnet
The transactions are stored in the Testnet using the Tag WZL9GCX9IOTA9POC9IIOT999999. We stopped uploading data packages after approximately 500 workpieces. Click here to see a randomly chosen transaction.
Coming up
The next step is to work on the backend to achieve a significantly higher rate of transactions per second, but also to outsource the PoW and to verify the data integrity using a web-based frontend.
Acknowledgement
I would like to thank everyone involved for their support. Especially the team from grandcentrix GmbH: Sascha Wolf (Product Owner), Christoph Herbert (Scrum Master) and all gcx-reviewers and gcx-advisers; some testnet-nodes-operators, who were intensively used for above transactions: iotaledger.net; the team from WZL: Julian Bauer (Graduating student, Service Innovator), Semjon Becker (Student assistant, Design Engineer and Product Developer), Dimitrios Begnis (Student assistant, Frontend Developer), Henric Breuer (Machine Learning Engineer, Full-Stack Developer), Niklas Dahl (Student assistant, Frontend Developer), Björn Fink (Graduating student, Supply Chain Engineer), Muzaffer Hizel (Graduating student, Supply Chain Engineer and Business Model Innovator), Sascha Kamps (Data Engineer, Data Acquisition in Data Engineering and Systems Engineering), Maren Kranenberg (Student assistant, Cognitive Scientist), Felix Mönckemeyer (Student assistant, Backend Developer), Philipp Niemietz (PhD student, Computer Scientist), David Outsandji (Student assistant), Anton Shirobokov (PhD student, Mechanical Engineer), Tobias Springer (Student assistant, Frontend Developer), Joachim Stanke (PhD student, Full-Stack Developer), Timo Thun (Student assistant, Backend Developer), and Trutz Wrobel (Student assistant, Backend Developer), and WZL’s IT: Thorsten Bröker and Dirk Hautermann.
Get in contact
You have questions or want to join/contribute in any way? Ask for Daniel or write an E-Mail | Follow me on Twitter | Or check WZL’s webpage.
