IILA x IOTA — Finite Element Method As A Service
M2M between FE Server and an Industrial Fineblanking Press
Co-Authors: Ashri Anggia, Semjon Becker, Joachim Stanke
What’s this about?
Imagine a scenario in which a machine would autonomously have an FE twin for each workpiece, with data that could not be physically measured. This opens up completely new possibilities for AI in mechanical engineering. That’s huge in my field of expertise.
1. Introduction
We are developing a way to establish a Machine-to-Machine (M2M) communication between an industrial fine-blanking press and a finite element (FE) server to generate a digital twin for each physically manufactured workpiece. We will discuss the basic of FE modelling before jumping into the technical aspects and processes in the background of FE simulation We will show a user-friendly API which allows for an autonomous digital FE twin production. Now thin
A finite element simulation is used to model and compute physical values, that cannot be measured in real-life. For instance, video 1 shows the distribution of mechanical stresses during fine-blanking. Mechanical stresses cannot be measured in the shearing zone since there is simply no space for a sensor. However, these stresses are normally very useful for designing components and assemblies, because high stressed values may damage workpieces. Thus, FE simulations are very important in mechanical engineering.
Furthermore, FE simulation is used to predict material behaviour and geometric aspects like die roll and the quality of the shearing surface. However, because the finite element method is mostly used prior to production, the results of a FE model, even if they are validated by real experiments, vary quite a lot from the final production.
If you think of all WZL x GCX x IOTA PoC Status Reports, you may be able to connect the dots. We have extracted real machine data from every manufactured part and stored that data in the tangle. It is an obvious step to combine this machine data, the Tangle and a FE server to allow for machine triggered FE simulations. As it is most likely that these FE servers belong to third parties, it makes a perfect business case in using IOTA as a currency.
2. Finite Element Method in a Nutshell
Finite element method is a numerical method to solve complex nonlinear engineering problems. This is done by dividing the problem into smaller, easier solvable parts. Those parts are called finite elements (FE). Because the problem is easily solvable on those finite elements, complex problems can be solved by just combining the solutions of the small finite elements to a combined solution of the entire structure. A finite element analysis (FEA) is mostly performed to compute physical values, that cannot be measured non-destructively in the real world. For instance, regarding the fine-blanking Proof of Concept (PoC), we cannot measure the temperature, stresses or die roll in the shearing zone during fine-blanking, but with FE simulation we can compute these values easily, see Figure 2.
How is a finite element simulation set up?
Setup of a FE model might be different in detail depending on your FE software, but most steps are always the same, including a) Modelling, b) Pre-Processing, c) Processing and d) Post-Processing, see Figure 3.
- a) Firstly, either a geometrical structure is setup using a Computer Aided Design (CAD) software and imported via interfaces or directly modelled in the FE software. We use the FE software Abaqus, which has a built-in native CAD modeler, see Figure 4. For efficiency reasons, we only modelled in 2D and due to the symmetry, we are focusing only half of the problem. You might notice that the blank-holder and die on the left side are missing.
- b.1) Secondly one must assign material characteristics to the modelled CAD structure. Some parts, like the blank, must be described by an elasto-plastic behaviour. Elasto-plastic behaviours allow for the modelling of a plastic metal forming behaviour and elastic spring back effects.
- b.2) Thirdly, choosing the right finite elements is very difficult, see Figure 5. Either one chooses one-dimensional elements (linear elements like straight lines) or two-dimensional elements (like planar faces) or three-dimensional elements (like volumetric cubes) to precisely describe the geometry. However, the more elements or the higher the order or the more-dimensional the modelling, the longer it takes to solve a problem. Sometimes FE simulations take days, weeks, even months to complete.
- b.3) Fourthly, one defines process kinematics and boundary conditions and how different parts of the model interact. In fine-blanking, the punch and blank-holder move downward, while the counterpunch moves first upwards, then downwards. The cutting die does not move at all. Finally, the FE simulation type itself needs to be defined. To improve computation time, especially designed pre-configured simulation types improve the FEA, we are not taking into account thermal effects, static behaviours etc.
- c) And now the FE solver starts to calculate each element one after another until the entire structure is finished.
- d) Post-Processing describes the analysis of the FE results, like analysing the temperature or stress distribution like shown in Video 1.
What does a finite element software do in the background.
Most FE software were initially developed decades ago. Therefore, the backend of such tools is mostly based on FORTRAN. Fortunately, the Abaqus Frontend is realised in Python. Moreover, Abaqus provides a Python API, that could be used to setup and control a FE simulation.
Initially, we have set up a parameterised FE model, which is controlled by a Python file, see Video 2. After changing some values in the Python file, the source code is compiled, which means it set ups the FE model based on the values and automatically starts the FE solver defined in the Python files. Using the Abaqus Frontend one can check the simulation progress.
Based on that Python file, one must only find a way to change the values in the file remotely.
3. Development of a web-based API
The easiest way to modify files remotely is by using any kind of a web-based service, see Figure 6. Therefore, we developed a web-form, which covers all parameters implemented in the Python file. The web-form provides a user registration, but for the time being, the web-form is only used internally.
- When the user submits the form, a new database entry with the parameters is created. On the FE server, which is different from the Web server, a cron job (scheduler job) checks for new database entries in defined time intervals. If a new entry is found, a script updates the Python file with the database parameters and runs the file afterwards. The Python file is designed to setup the FE model firstly and starts the simulation automatically afterwards.
- While the simulation is running, interim results can be requested by the webpage. After requesting interim results or after the simulation is finished, screenshots of the finished FE model are automatically uploaded to FTP server and presented in the webpage’s dashboard.
- Besides screenshots animation videos like in Video 1 can be requested for completed simulations too. These are also uploaded via FTP and presented in the dashboard.
The web-form works as a standalone tool. However, thinking of a machine economy, it would be useful if the parameters, which are currently typed by the user, are defined by the fine-blanking press itself. IOTA would be the perfect backbone for such a task, ensuring immutable data records and allowing for micropayments as well.
4. Handshake between IOTA and the web-based API
In Step 2 we will combine the IOTA infrastructure from the WZL x GCX x IOTA PoC and the serverless Web-form for initiating Finite Element simulations from Step 1 to get one step closer to a serverless autonomous FEM as a service. Figure 7 illustrates the architecture.
- 1) Firstly, we assume that the infrastructure is from the WZL x GCX x IOTA PoC. Meaning for each physically manufactured workpiece a digital machine twin is stored in a database (1a) and the IOTA tangle (1b). The database stores the data itself. The tangle only stores the hash and signature of the data sets.
- 2) As already introduced in the WZL x GCX x IOTA Status Report 4 users can request access to the digital twin via a Frontend. The Frontend takes care of the integrity and validity check, which is necessary to match Tangle data (2a) and database data (2b).
- 3) Moreover, the user can now request a finite element simulation for any digital twin. Pushing the Buy FEM button initiates the serverless FEM as a service management in the background, see Figure 8:
- 4 ) The FE data is extracted from the database (4). If this simulation is not already existed, the simulation is started in the FE server (5).
- 5) On the local FE server resources are allocated to the simulation.
- 6) Once the simulation is completed, a new entry in the Tangle (6a) is made while the database entry (6b) is modified.
Demonstration of the Handshake
In the following video we are demonstrating the handshake process between the IOTA network and the FEM server. After submitting a FE job via the blue button, the Database gets updated and detects the FE job. Unfortunately, we are not working with the push-principle, rather than a scheduler. Because of the scheduler principle, the submission date is first set to the beginning of the UNIX timestamp, but once the scheduler ran, the submission date is shown correctly. Nevertheless, this successfully shows the handshake between two physical OT devices, the Fine-blanking Press and the FE server, via the IOTA network.
5. Outlook
The development of the interface between the machine and the FE server will take a lot of time and is far from finished. However, we will continue to work on it and share it as soon as major progress has been made. But the proof of concept is complete. Couldn’t be prouder of the team. Very good work!
Donations to the IILA
The IILA is a non-profit community. We appreciate every help we can get.
YAEIESUZBAQNKACLQOIHWZMWEGOCBGSYXSCMBUXXQOXNZUPU9QGEKZWMCMXKSTATAVS9EFHMLW9IRNYKDBXUAOK9DZCheck our address on thetangle.org.
Acknowledgement
I would like to thank everyone involved in this project for their incredible support. Especially the team from WZL: Ashri Anggia (Software Developer), Julian Bauer (Service Innovator), Semjon Becker (Design Engineer and Product Developer), Dimitrios Begnis (Frontend Developer), Henric Breuer (Machine Learning Engineer, Full-Stack Developer), Marcel Coenen (Finite Element Engineer), Niklas Dahl (Frontend Developer), Björn Fink (Supply Chain Engineer), Muzaffer Hizel (Supply Chain Engineer and Business Model Innovator), Sascha Kamps (Data Engineer, Data Acquisition in Data Engineering and Systems Engineering), Maren Kranenberg (Cognitive Scientist), Felix Mönckemeyer (Backend Developer), Philipp Niemietz (PhD student, Computer Scientist), David Outsandji (Student assistant), Tobias Springer (Frontend Developer), Joachim Stanke (PhD student, Full-Stack Developer), Timo Thun (Backend Developer), Justus Ungerechts (Backend Developer), Jessica Wieczorek (Software Developer), and Trutz Wrobel (Backend Developer), and WZL’s IT.
