/ #PhD 

Robust motion control

My Phd research has started almost three years ago. These years have been rich in lessons and experiences. In this article I give an overview on these three years. I will show some of my research lines and some of the results of this research, but first, it is time for some introductions. I started as a PhD student at the Robotics and Mechatronics group (RAM) in September 2017. Fresh from my master in Electrical Engineering, which I finished at the same group. At that time there was a big project started in collaboration with a lot of groups. This project was funded by the then called STW organization, which is now known as NWO-TTW, a perspective program. The title of this project is “Robust Design of Cyber-Physical Systems” and the project is a collaboration between Twente, Eindhoven, Groningen, Nijmegen, Delft, Leiden and Amsterdam. Within this project there are a lot of different tracks, or maybe research lines, nine to be exact. I am part of the ninth line, which is “Robust motion control”. This line is a collaboration between Us and the Radboud University Nijmegen. This research line has been the basics for my research of the last three years. Next to being part of this perspective program, I have also spend quite some time of my PhD on educational affairs, more specifically module 6 of the Electrical Engineering Bachelor. This article will however focus on my research.

Based on the title of the project and research line you might already have some inclination on the subject of my work. My work focusses on “Robust motion control”. More specifically we focus on the design of cyber-physical systems in such a way that we can design motion systems in a robust and reliable way. If we take a step back and look at the concept of a cyber-physical systems (CPS) we can see that it is a very broad subject. Any system that can be said to interact with both the cyber world, by including some sort of computation, and to interact with the physical world can be called a cyber-physical system. This dual nature of these systems creates a set of design challenges. These challenges are already described by (Lee 2008). A particular set of challenges arises from the fact that the physical part of the system introduces safety and reliability considerations that are very different from the ones in general computing. Even if we only take into account the cyber physical interface of the system, and thus ignore the purely mechanical and software design there are a lot of aspects that need to be taken into account. An overview of these steps was presented by (J. F. Broenink and Ni 2012) and can be seen in Figure 1. There exist some strategies to help overcoming these challenges. This can be done using smart development approaches, simulation tools and physical prototypes. Approaching the development of CPS using a model driven approach can work. But as you can already see coming, the fact that the system covers different domains and different models of computation results in a lot of different aspects of the system that have to be modelled and simulated. This modelling and simulation of CPS is not a trivial problem and is also part of this research. The rest of this article will focus on our solutions for modeling, simulation, designing, and maybe a bit of testing of these cyber-physical systems.

Figure 1: An overview of the design flow of the cyber physical systems as presented by Broenink and Ni 2012.

Figure 1: An overview of the design flow of the cyber physical systems as presented by Broenink and Ni 2012.

So step 1, the simulation of these cyber physical systems. It is not as trivial as you might expect. There are a fe7w ways to simulate a system that exists in different domains, or to be more specific with different models of computation. The first one is to approximate one domain in the model of computation of the other domain. This way you effectively make a single model. The advantage of this method is that it is very easy to implement. The disadvantage is that it becomes more complex when more models of computation are used, and when the system (thus the part of the model that needs to be transformed) becomes larger. Now you might think, how many different models of computation can you have? But let’s take a look at a computer program for embedded control software. The layered control structures as posed by (Ni and Broenink 2014) shows multiple different layers. These layers, as shown in Figure 2, have already multiple models of computation. Where the loop control and safety layers are discrete time based, the supervisory control and user interface will probably be based on discrete events. This shows that even in the cyber part you might need more that one model.

Figure 2: Layered control structure of embedded control software (Broenink and Ni 2014).

Figure 2: Layered control structure of embedded control software (Broenink and Ni 2014).

The second option is to simulate all the models within their own model of computation, and then use a communication layer to synchronize these models. This principle is known as co-simulation. The advantage of this method is that all parts of your system can remain within their own model. You will however require some sort of extra software/information to control the complete simulation. You would need to specify what models to simulate together, how to simulate them and also what in and output to provide. This is still a difficult problem. Luckily for my I worked together with a computer scientist in Nijmegen who worked on this problem. He designed a domain specific language to generate these co-simulations, called CoHLA. The design and development of this system is shown in (Nägele et al. 2018). How a simulation would be structured is shown in Figure 3. As you can see, there is an interface to communicate with all the different simulators, the RTI. And there is a implementation of simulators for different models. This way you can simulate the multiple models you need for a cyber-physical system together.

Figure 3: The structure of a simulation made in CoHLA(Nägele and Hooman 2017).

Figure 3: The structure of a simulation made in CoHLA(Nägele and Hooman 2017).

But simulating all these models together is not the only thing required. When you start the design of your system, you will hardly have any models at all. During the design process, you will make decisions which will influence the final product. This results in a different design, and thus in different models. When you want to know which decision is better, you might even wat to simulate the different choices both. So you will get a lot of different simulation during you design. For every new simulation that you want to do you will need to construct a new co-simulation. Okey, maybe not for every simulation. If your overall model structure of the system remains the same and only the internals of these models change, you might be able to use the same co-simulation.

This is why it is important to think about in what structure you model your system. You want to make sure that the top level of your system keeps the same structure, independent of where you are in the design process. Of course this might not always be possible, but you must try to achieve it. If you want to keep your model structure as constant as possible, you will need to choose your model interfaces in a smart manner. You need to base them on physical signals, or at least representations of physical signals. These physical signals are mostly invariant of the amount of detail present in your models. Thus while the implementation of a part of your system will change, it’s outside will remain the same. An example of this I show in (Broenink and Broenink 2018). An example from this publication is shown in Figure 4. This shows two models of a sensor system. The first model (a) shows the complete model of this sensor. With all extra behavior included. The second one (b) shown a simpler version of the same sensor, with different behavior. However the interfaces of both of these models are the same, and both of them could be used in the same co-simulation.

Figure 4: A simple and complete implementation of a sensor system, with the same interface.

Figure 4: A simple and complete implementation of a sensor system, with the same interface.

With these tools we can effectively design simulations of a cyber-physical system. This does however, tell us nothing on how to design these systems effectively. The rest of my research has focusses not on how to simulate these systems, but on how to design them. During this design we of course want to leverage the capabilities provided to us by the previous work on co-simulation.

This is why we have developed a method of designing cyber-physical systems in a structed way based on a iterative approach. This approach is detailed in (Broenink and Broenink 2019). This approach shows a way to develop a CPS by dividing the design problem into manageable features and detail levels. Both of these will result in a large set of models, that can be simulated during the design process. One example set of models is shown in Figure 5. The specifics of this method can be found in my publication, but is is safe to say that this structured approach should allow for more simulations and thus also tests during the design process. This process should be as automated as possible. Thus after changing a part of your design you can receive feedback immediately on the performance of the system.

Figure 5: An overview of the models generated of a segway as shown (T. Broenink and Broenink 2019).

Figure 5: An overview of the models generated of a segway as shown (T. Broenink and Broenink 2019).

This brings me to my final subject for this article, that is the future work. While I have shown you some of the results of this research project, the work is not yet done. Currently we are working, together with students on different ways to improve this. These subjects include but are not limited to: Automated tests with simulations. Generating standalone code based on the design process. Effectively switching hardware platforms. Hopefully this work will improve the methods and approached mentioned in this article into something that can really help with the design of robust cyber physical systems. Who knowns, you might read all about it in my final thesis.

If you do think these subjects are interesting, or are looking for an bachelor’s or master’s assignment within these subjects, feel free to contact me or our group.

Bibliography

Broenink, Jan F., and Yunyun Ni. 2012. “Model-Driven Robot-Software Design Using Integrated Models and Co-Simulation.” In Embedded Computer Systems (SAMOS), 2012 International Conference On, 339–344. IEEE. http://ieeexplore.ieee.org/abstract/document/6404197/.

Broenink, Tim, and Jan Broenink. 2019. “Rapid Development of Embedded Control Software Using Variable-Detail Modelling and Model-to-Code Transformation.” In Communications of the ECMS, 33:151–57. 1.

Broenink, T.G., and J.F. Broenink. 2018. “A Variable Detail Model Simulation Methodology For Cyber-Physical Systems.” In ECMS 2018 Proceedings Edited by Lars Nolle, Alexandra Burger, Christoph Tholen, Jens Werner, Jens Wellhausen, 219–25. ECMS. https://doi.org/10.7148/2018-0219.

Lee, Edward A. 2008. “Cyber Physical Systems: Design Challenges.” In , 363–69. IEEE. https://doi.org/10.1109/ISORC.2008.25.

Nägele, Thomas, and Jozef Hooman. 2017. “Rapid Construction of Co-Simulations of Cyber-Physical Systems in HLA Using a DSL.” In 2017 43rd Euromicro Conference on Software Engineering and Advanced Applications (SEAA), 247–251. IEEE.

Nägele, Thomas, Jozef Hooman, Tim Broenink, and Jan Broenink. 2018. CoHLA: Design Space Exploration and Co-Simulation Made Easy. IEEE.

Ni, Yunyun, and Jan F. Broenink. 2014. “A Co-Modelling Method for Solving Incompatibilities during Co-Design of Mechatronic Devices.” Advanced Engineering Informatics 28 (3): 232–40. https://doi.org/10.1016/j.aei.2014.05.004.