 I'm just going to shut them up when we can start. OK. Everybody, please sit down. We're going to start with our next talk. And I'll hand Mike, now, to Zeeshan, which will actually do his presentation. Hello, everyone. I have a bit of a headache. Nothing to do with last night, as I don't know what it is. Every fourth time it happens. So I'm going to talk about something called GDP. But before I get into that, I'll have to introduce a bit of background. So first, we talk a bit about GenEV. By the way, my name is Zeeshan. I didn't introduce myself. Sorry. And I work for a company called Pelagicor. It's a small company in Sweden, which works for IVI systems mainly. And we are now part of a greater Luxsoft company. Yeah, GenEV. It's all about open source IVI. So when people are making IVI systems, they realize that they can make use of a lot of open source components out there that are already there. And they're well-established and stable and working and everything. So why not make use of them? And while they were doing it, a lot of companies realized that they were using the exact same components in a very similar or exact the same way. So why not combine forces and create an alliance to standardize those components and to create more components that are also standardized across industry? And just about combining the forces. So one of the first things that came out was the compliance process of GenEV. So GenEV is the alliance that was formed of many automobile companies. And it's not just OEMs, but also some companies that work with OEMs, the four OEMs and stuff, and silicon manufacturers as well. And compliance is a process in which you have a system and you want to show that it's using industry standards and it is compliant to GenEV standards. So you have this process which you go with GenEV and you get certified to your IVI system that it's compliant with GenEV. In GenEV, we have abstract components defined like you have some APIs that you don't have to implement in the same way as we will have in a reference implementation, but you can have completely different implementation. But as long as the API is the same, it's your system is compliant. But then we have specific components as well that it has to be the exact same component, otherwise it's not compliant. But there is at least a lot of room for changes, for improvements, for differences. And it's very, very open. And one of the products of this process is something called Base, we call Baseline. It's, as the name suggests, it's the base of all the system. It's a core component and it's in the form of a Yocto layer called Meta-IVI. It's just the basic components that you need for IVI system and everything in this layer, in this Yocto layer is compliant. So if you want to build a GeneVy compliant system, it's very easy, you just take this layer and build on top of that. And it makes your life much more easier. You don't have to, but... And since Baseline is just the base, it does provide you with a bootable image that you can boot and do things with it. But it's not much. So GeneVy development platform, GDP, is something we built on top. It's a reference implementation. It's GeneVy compliant system. It's almost a complete system and it's good for demos. It's not good for, you can't actually put it in a car. It's not good for that. But it's a very good reference implementation and it's very good to get you started with the development of a GeneVy compliant IVI system. It's composed of two Yocto layers. It's the first one is Meta GeneVy dev, which adds the missing layer from Baseline. Baseline just gives you command line, for example, and there's no, for example, UI in there. But Meta GeneVy dev adds HMI. The main UI in an IVI system, in automotive world, it's usually called HMI. So it adds an HMI. It's just a demo and it also has a few apps that show off many of the R APIs on the system. And GeneVy dev platform, it's the whole platform. It combines all the needed layers to create these images. So we have images for various targets available and of course more can be added and you can change the layers to add more boards if you need to. To give you a better idea, I put a picture here. So you can see the Baseline. It has standard interfaces and individual software components that are standardized and compliance is all about this Baseline. And on top of that, we add the GeneVy development platform and it combines the whole thing into a nice demo-able bootable image. We also have tools around it. I'll talk about that later. Software development environment is one of them. What does it offer mainly? Well, firstly, it's like the established open source components that are used in many IVI and embedded systems that are there on GDP already. So you don't have to put it there. It's already there for you. Other than that, we have some IVI-specific tools that we have put on top. Firstly, this is not exactly IVI-specific but it's GDV-specific. We have something called software development environment. It's a completely standalone environment. It's a bootable image. You can download and you boot it in a virtual box and you have the whole environment set up. You have all the tools needed. I'll show you a picture. It might tell you a lot. I'm not sure how much of this you can see but that's how it looks like. It's a bootable Ubuntu image. It has all the usual development tools like GCC and all. Apart from that, there is also debugging tools and Eclipse environment in there for doing development. And one of the things it adds is a log and trace tool. It's a pretty standard tool, this DLT. It's used in automobile industry quite a lot and we have it already on board so you don't have to do anything. And it also sends the logs and everything to the network so you can use the SDE combined with GDP running on a board and you can get traces of what's going on on the GDP system and do all the debugging you need to do. We have something called Audio Manager. You have audio servers like Pulse Audio, you have Jack and various others that do pretty similar stuff and mainly it's about routing of audio. There's some other things too but mainly it's about audio routing. And this Audio Manager firstly, it abstracts those interfaces so you have just one interface in IVI and you have to care about and you don't need to care if it's Jack or Pulse Audio or whichever audio server you're using. You can even change it later on. If you're developing a product, you say I'll use Pulse Audio but later you change your mind and you want another system so this enables that. And also it adds some IVI specific use cases on top. Not going to get into details. There's something called Common API. It's something architects really love. Developers are a bit divided about it but architects really love it because it enables them. It's a tool that translates Franka IDL specification into a real code that you can use to create D-Bus services or D-Bus proxy code. But also not just D-Bus, it can also do something called sum IP. It's used a lot in IVI as far as I know. And so you can translate into code for handing some IP as well. So it's a pretty neat tool for designing interfaces and then translating code. We have a system for persistence. So if you are in a car and you're listening to some song, for example, and you turn off your car and you turn it on back, you want the system to come back to the same state it was in. Not good to some other state, initial state. So persistence is a system that makes it very easy. It's an API that apps can use to have their current state persistent and also for the HMI to save its state and be able to restore from the last state if it goes off or something. We have something called remote vehicle interaction. It's pretty complicated stuff. It's a lot of things involved but I'll give you some examples like if you are about to go out on a long journey and it's really cold or it's very hot and you want to set up your car so that you don't go into a freezing car or a very hot car. So you can, from your phone or an iPad you can already set the environment of your car like start up the heating system or ventilation or whatever. Five minutes before you go in and this remote vehicle interaction, there's a framework that makes that possible for you to do that, to implement that in the car. Also, it can send out information to servers about, for example, if there's congestion in the area or something so it can send to a server and then server can handle that in some way. I'll talk about an example, a real world example later, how that's useful. There's other examples of this as well like for example some peer to peer networking if you have your media on your phone and you get into your car and you just want to have your media play from your phone on the car, car stereo system. So you will use this system to implement that sort of use case. There's quite a few use cases that this can be used for but we have this framework on our own in GDP already so it makes it very easy for you to implement in GDP-based IBI system. So for the air, it's very related to RBI but it's kind of different. It's at least implemented separately in GDP. You nowadays, a lot of new cars are doing that. They want the system to be updateable over the air. You don't, a user shouldn't have to go to a garage to get their software system updated. That should be just automatic, it should just work and it works already in many automobiles and in future it will, you will see a lot more of that and this is a system that makes it possible. It's currently, our SOTA client is written in Rust but it's being ported into C++. We ran into some build issues with Rust layers at some point so I guess it's a good thing. We have also spins, like as I said, GDP is just a layer on top of baseline so you can add, remove things from it but still be compliant to GeneVy. So you can have a GeneVy compliant system but not use exactly GDP. So it's, yeah, GDP is just to make things easy for you but we officially want to support people who want to have such systems and have them available so people can have different software components if they want to and currently we only have one such spin. It's called Qt Automotive Suit. It's actually maintained by my colleagues and developed by them as well. It's actually pretty awesome. If you are for some reason not satisfied with GDP, please do have a look at this. It's pretty neat stuff. Future, I'm really sorry, I'm going really fast but I don't have a lot of time so then I have to go through a lot. Yeah, we have a project now started together with the Nevada Center for Advanced Mobility to make use of the RBI system of GDP to report data from the car to centralized servers and to back from the server to the car to make different various kind of decisions to enable something called we call smart city. It will be a pilot project in Las Vegas I think and the point is that it will be informing pedestrians. There's a lot of pedestrian accidents in that city so they really want to make it safer for pedestrians and they will get data for example on their phones or something that okay there's a lot of congestion here and they should avoid which areas they should be avoiding which areas they should be routing from and the same for cars like if there's a lot of congestion somewhere they can avoid those areas or they can avoid areas where there's a lot of pedestrians crossing so to make it safer for pedestrians and also you don't want to go over a pedestrian so it's good for the driver as well. So there's a lot of these instructions going on to make it safer for everyone to drive and to go around the city. Pretty, pretty excited about this. So Google Summer of Code, it's a project it's I think most of you already know about it Google gives a lot of money for students to work on various open source projects and this is one of our, we want to participate in Google Summer of Code and not just to get some work done but also to welcome more community to work on GDP because there's still a lot of people who don't know that we are completely open source it's a completely open source project and they are welcome to work with us even if they don't work for car companies. So we want to change that impression and one of the ways we will do it is we have applied for Google Summer of Code I don't know if you'll get accepted or not you can never know but I hope we do and we will have some students working this summer for GDP and we can expand our community and that would be really cool. We have a browser on GDP already but it's not so good, it's not so nice it's not pretty complete at least so there's EGALIA guys working on this they are make porting Chromium to GDP and making it work they actually have gone quite a long way in the last one month they started only a month ago and I was expecting this to be kind of integrated in months later but they were pretty fast and I was really impressed by their speed so there's already a demo and they have a blog post where they explain how to download and get it working on GDP so it's pretty good, hoping really looking forward to that hopefully in a month or so it will be integrated in GDP, fingers crossed of course. This is the most difficult thing to explain but I'll try. So we have system D on GDP and that manage the whole system, the life cycle of the system but in an IVI system we need a lot more and usually also in other embedded systems as well for example if you have an app that is running as I mentioned before in the system shuts down you wanted to get back to the same app in the same state that it was in and life cycles, there's a component we will be implementing in the next few months that will make it, well the component is already there we just need to mostly integrate it with the rest of the UI and everything to make it actually work on GDP so it will ensure that system loads in the correct order in the correct and it loads the last application in the last context, user context. Yeah, pretty complicated stuff. There's a lot of other things involved too that I'm not mentioning here such as user management and user seats and those kind of stuff but that needs another talk I think and I think next year I'll have a talk about just this specifically and by that time we would have it completely integrated and implemented so it would be cool. We have location-based services basically just where you are, where your route and where should you go and stuff and it also comes, there was another component involved which is called fuel stop advisor that tells you if you're low on fuel and when you should be getting into a fuel station and it should already, like if the fuel is really low it can tell you that warn you or already inform you that you really need to go to this petrol station like right now or you'll be going out of fuel soon so that's part of it and some of these components are already part of GDP but it's not completely integrated, there's some people working on this so hopefully in the next few months we will also see more location-based services and some demo UIs on top that demonstrates how various APIs can work and for people who want to use these. The UI as I mentioned, it's just a demo so it's not supposed to be put on in a car system like this so the UI is not that great but I think we can make it slightly better and there was a reiteration of the UI which is and it made it much, much better looking and it's really cool looking now but it can really use some improvement still hopefully in the next few months that this is also going to be happening and we will have a UI that is really good for a demo. The RVI subsystem we have, it's written currently in Erlang. The only problem there is that it's not really good for putting in embedded systems, it consumes a lot of space and a lot of memory so those guys have written now the guys who implemented RVI have written a library, a C library that makes it much more lightweight and it does the exact same thing so that's going to be integrated soon. As I mentioned, not many people know or think that we are completely open source project and we really, really want and need more contributions so if you want to work with us, it would be awesome. We actually have one guy already, Changyok. He works quite a bit with us. He's actually one of the maintainers of the GDP layer so he has commit rights and everything and he does not work for January, he does not work for any of our companies as far as I know but he's a completely open source random guy who just was interested in an IVI systems and he's really good, he does good job and he helps out. So if anyone of you are interested, you can also be the next Changyok. We had a team transition I thought I briefly mentioned. Previously, the project, the GDP project was maintained by a team from Code Think. They did an awesome job and I really would want to thank them if anyone of them is here for their work and it was a really smooth transition they did when the team was transferred to, the work were transferred to a team at my workplace called Plachikor and I'll be the lead developer and there's two more people working with me, Taha, Mohamed and Victor. What's your last name again? How do you pronounce it? Okay, I can't pronounce his last name, sorry. Yeah, it's a Swedish man. Yeah, yeah, that's it. I think I have now seven minutes for questions. The question is that if Genevieve supports... Edisys. Edisys, since I haven't heard of it, I don't think so. So, yeah, you could have waited five minutes. Sorry, the question was that we read it in Rust and then, yeah, yeah. The question is that why are we moving SOTA client from Rust to C++? It's not our really decision, it's an expert group who develops it and they went into a few problems because it's not just for GDP, the SOTA client, it's meant for other systems they work on as well for their clients. So, the main reasons they told me were the Rust binaries were too big and, sorry, forgot the second reason, but, yeah, yeah. I'll let you know later on. Okay. Yeah, that's okay. Thank you. If anybody still has questions, just come and talk with Session and do that outside so we can continue with the next talk. Thank you.