Game4Automation - A Unity asset to create digital twins

Main functionalities of Game4Automation: what we need for a digital twin in the industry

Game4Automation is a very complex and substantial asset, with lots of classes, layers and made to adapt to various situation. What is important for this article is not to do a commercial for the tool, but to evaluate what we need to create digital twins in the industry, which is entirely different of what we need for a digital twin of a living being in the medical sector for example. What you’ll read here is the presentation of a test scene that I made, so I will take you in a journey to my imaginary factory build with Game4Automation.

We can compare this example to use cases for simulation’s or CAD purposes, as we have no real model to which make a twin from. But this simulation is enough to chose the logical model, see that it works perfectly well and adjust speeds or synchronization.

Production chain

I won’t teach you anything if I say that in a factory, we mostly use machines to transform objects and then move them with another engine toward its next transformation’s place. So I decided to design a production chain that I will describe, and that you can play with the video above. My purpose was to test as many Game4Automation’s functionalities as possible when doing so, but also to test the free asset CADENAS part4cad which is included with Game4Automation but can be used independently. This asset gives access to models from a huge number of companies that the customer can directly import in his scene. That is where I found all my models- except for those from Game4Automation, like the can model for the object generated.

The cycle begins for a new object if the trolley is ready at its starting position. If this condition is true, a new can is generated. When an object is detected by a well-placed sensor, the trolley moves toward its second position, which is in front of the first articulate robot. Again, a signal is send when the object is detected by a second sensor, but this time it makes the 6-axes robot pick it up, and when the sensor is void again the trolley goes back to the starting position to generate a new object. The robot then turns to its second position to hand over the can to the next robot, before going back to its waiting position. This last robot turns around, tilts the axis at the extremity of its arm and let the object go on an inclined plane. It lends on a continuous chain of wagons that take the can away to the point an invisible sink suppress the can. As you can see, there are lots of ways to move objects around.

Logical model

I want to come back to the 6-axis robots: As you can see in this video, I didn’t used all axes for every machine and the speeds of their different axes are defined individually. The automation is controlled with a script that treats the robot like a state machine, and it is one of the few scripts not already written because it is inevitably linked to a use case. When the machine enters a state where some of the axes has to move, every axis is ordered to move until it meets a defined position, using a driving script. To control these kind of logical behaviors, Game4Automation provides us PLC components that can be used to control every aspect of the simulation, the robots as well as the UI components. A PLC in Game4Automation can be a boolean, a float or an integer.

Compatibility with IoT interfaces

Why are IoT technologies emerging so strong nowadays? Because it is very powerful to have the possibility to connect every machine from anywhere with each other. The potential of digital twins is endless because IoT increases steadily  its possibilities. But for that we need a good IoT platform, and access to data which is easy enough to have a substantial digital twin. Unity is an interesting platform for that, as it is open source and has a strong community, always searching to extend what everybody can do. I will now present two particular IoT platform as examples that I tested in my use cases for Game4Automation.

OPC UA

Game4Automation allows us to use various interfaces, one in particular is OPC UA, which is the subject of several posts on this blog. OPC UA, Open Platform Communications Unified Architecture, is a standard for industrial communication, maintained by the OPC foundation. It is nowadays used more and more in the industry, as a common communication solution for different systems and devices is the basis for Industry 4.0 and since it is independent of the programming language and has multi-platform capabilities. A more detailed description of OPC UA and an overview of the transport protocols used in the IoT can be found in German here (https://www.novatec-gmbh.de/beratung/datentransport/) on the Novatec website. Using Game4Automation’s interface for OPC UA, any user is able to receive information from a server and sent data back. So the user is able to create his machine on Unity before having it in the reality and test his OPC UA server before hand, monitor from anywhere what is happening real time, make tests to improve the productivity without stopping the production or any other activity presented in the use cases, with a parallel access to the real data all the time. The connection is as much secured between Unity and the OPC UA server as with any other platform.

I created numerous use cases for the OPC UA interface from Game4Automation, sometimes to read some nodes, or write on others, but also to do both actions at the same time on a node. This last option is a bit more difficult to apply but what you’ll need will depend on your use case: if you want to monitor what is happening in real time, you will read the nodes on your server, but if you want to test your server and a logical model using it you can prefer to write on your server.

Cumulocity

I also tested creating an interface for the IoT platform Cumulocity, which was  quite easy and efficient. I was able to access values as easily as with any interface from Game4Automation, and with the same advantages as above with an OPC UA interface. There are indeed existing scripts on the Internet, so that people new to the question are able to obtain results really fast. The only use difference is that I can only read what is on the server, I didn’t create it to be able to also send values back.

This use case is the only one for which I had an actual existing system as base: we indeed have a greenhouse in our office, and I was able to read the values of its temperature, humidity and CO2 rate.

The first use case with Cumulocity was to monitor the values from afar, then to use the HoloLens to monitor directly with the model in front of oneself, and ultimately I created a primitive system to regulate these values. For all these different applications, the same script for the interface was used.

Conclusion

The potential of digital twins is, as their name, not truly defined at the moment. But what I was able to see in my tests promise more than just a new gadget. It is perhaps not exactly the future, but at minimum a milestone on its path.