 So, as was stated, my name is Mirek Erosz. I am working at Red Hat as a principle software quality engineer. And today, first of all, let me tell you, I am not the best speaker, so it's good that this is the last session for today because you won't get too much angry with me, which is good. Second of all, this won't be a typical deep dive talk. It will be more about our experience once we've started to be researchers in our companies, so it will be more about what we did face when we've been researching this topic and how it worked for us. So if you were hoping for a deep dive, I must disappoint you. So what was the story? So it was 2017, so something like five years ago. We've been in Red Hat playing a bit with IoT tools and stuff, and we got into a talk with Czech Technical University with the software testing lab, and we decided that we want to start some kind of research project where we as a Red Hat would be somehow responsible for the technical part and Czech Technical University would be responsible for the methodological part. We decided to deep dive into the IoT topic because at that time, as it still is, it was a huge topic with unknown variables and a little covered in the research papers, so we've decided that's our way to go. We started in 2017. It was a project that we've got grant for from Czech Agency of Technology, and we started the research. So we became researchers. Okay, how do you start the research? Well, you ask questions. So we try to ask ourselves a question. What is an IoT application? Not an easy answer to it. Then we try to ask, how would I deploy an IoT application? Again, not an easy question to answer. What is the communication method used there? How should we test it if we want to test it? What would be some kind of common ground? How could we effectively describe it or how could we describe the test scenario in such an environment, et cetera, et cetera? So every time we've asked a question, we only discovered more new questions to ask ourselves. So once we got all the questions we got, we moved to the research part. So we've read over 800 research papers in the first year. It raised more questions. We analyzed some topologies that were described there. We reviewed the communication methods that are used in IoT, and we wrote a specification. Something like 100 pages long, and these were our findings. So IoT is vaguely defined. If you would try to define IoT, you would get to the problems like, okay, so what does it mean, Internet of Things? We know that it means we have some devices that produce some data that are collected and that are somehow managed, analyzed, et cetera. But what are the data in nature? Where do you get them? Who provides them? In some applications, the IoT means we have devices that are connected directly to the Internet, so they know who they are going to communicate with, and they are sending their data. But then you have solutions where nothing as such is. You have mesh networks where everything communicates with everything. Like in factories, you have wireless sensor networks where you use small, low-power devices that build their own network as they are running. And then from this network, which is not TCP-IP, generally, the data are somehow sent back to some data store or to some gateway, which then decides what to do with those. What we found out, even though we weren't so much able to define strictly what technologies are used in IoT, what we found out was that there is always some kind of central part. There is always some place where the data are going, where they are processed, and where the decision-making happens. And this is the part we can test in a software way. Because for the physical world, the testing is quite hard. You will, in general, end up with a solution tailored for your purpose, but for the data center part, or for the decision-making part, for the gateways. You can write out a general test, but you need some tools that will allow you to describe the real world. So as a part of research, we've tried to design such a thing, only in concept. And we over-engineered it. This is the definition of some modules that we would use while developing and would we would need. It's mass, it's heavy, and there are a lot of stuff to do. So we ended up with creating a framework. We called it Patriot framework. Not much about patriotism, but about the IoT and the name, right? So we got a name, which was Good Start. Then we got to implement it. So in the end, we reduced the number of components needed to basically free. So our architecture design or decisions that went into design. What do we need to test an IoT application? So we need something that produces data, which are somehow, which can be different like temperature measurements, humidity measurements, information of RFID tech that's going through some path GPS coordinates. We need it to somehow encapsulate such thing that would generate the data into something that looks like network and that has the problems of network, like instabilities, latency, et cetera. And then we needed something to cover it to provide some APIs for integration testing. This is what we end up with. Basically three components. If you compare it to the previous image, it's very much more concrete and less complicated. So we have right now in the Patriot, we have three components. We do have some core API, which is based on JUnit 5. That's Java library. Some of you probably know it. It provides the APIs for the rest of the system, as well as some facilities to enable integration testing, like conditional skipping of tests and some partial ordering of tests if you need those. We do have the network simulator part, which is right now implemented for two platforms. It's for Docker and for Kubernetes. The Docker part, it's the older one. Basically the Patriot framework expects that you have some Docker machine available for it to manage it, or machine with Docker daemon. And then it deploys anything you need, especially the generators of data into it. And it can interrupt anything within this network. Like it can create virtual obstacles for data packets to go through, or it can reroute the traffic throughout the virtual networks, et cetera. And then there's the last part, there is data generator, which is a component that allows you to define the data you want to produce for your system under test. So let's say you want to simulate a thermometer. So you do know that there is some distribution of the data that are going to be produced by thermometer and the data generator. And you can describe this distribution for the data generator, then encapsulate it into some kind of a network protocol, which will then produce it for your application. So how our research ended, basically. So I described how we got to a place where we got some solution. As the final phase in our research project, we expected that we will get to a pilot phase. So we will deploy our solution for some customer so they can test their whatever, software or product. But the project ended in the year 2020, which meant that we got hit by a corona pandemic. So in the end, nobody wanted to be friends with us. From like five pilot runs, we got to none, which was a shame. And it means that we haven't got a chance to properly try it in the field, which means that the software is probably buggy. I know it sounds bad, but this is a part of software development. Unless you have a customer, you are writing into the table. So you don't know what or you can't think if you are a developer about everything or how all the possibilities that can be, can your solution be put onto. So we finished the project successfully, but without the pilot run. And this is the end, well, not entirely. We are still continuing with the research, or not as a research project, but the project still lives on. We do still open an internship positions for it, and there is still development. We still continue with bachelor and diploma thesis. So if anyone here would be interested in having a bachelor or diploma thesis for themselves in this field, I would welcome you. So that's basically everything from me. Now I think we can get to the questions. Could you please rephrase the question in a way I could repeat it? Sorry, sorry, sorry. But I got what you mean, but yeah, right. So basically, yeah, so I repeat the question. So what is the, what is the, sorry, sorry, a little bit of understatement. But yeah, how would any new protocol impact our solution, right? So if there is a new standardized protocol, how it would impact our solution? And the answer is not that much. Like right now in the current state, we do have only a handful of protocols implemented. And if there is any other, you can implement it yourself. So you can edit the solution itself or the pattern framework will not, it's open to extensions. So if you would have some definition of the network protocol or some Java library that is able to use it, then you can just wrap the data generator into it and use it in the network generator. It would be possible. So if you would find out that it would make sense to have it as a part of the tool set in Patriot framework, you could try to ask us if we would implement it or you could propose a poor request yourself. Thank you.