 Hi everyone. Nice to see you. My name is Agustin Almansi. I'm the Director of Sales Engineering at VNC Automotive. And I'm here to talk to you today about the evolving software landscape in the automotive industry and how open source can foster continuous innovation. So thank you for your time. Hopefully you find it interesting. I will leave some time at the end for questions. So this is the agenda for the presentation. So we'll talk about why the automotive OEMs are racing to embrace software development and make it a key buying decision when you're deciding what your next car should be. We look at how customer demand and by customer I mean usually the driver. How their demand for the rich services that they're used to using in other devices like smartphones or computers has influenced how the technology in ABI has been progressing over the last 10, 15 years. We'll look at the open source projects and standards that have been used as building blocks to enable such technologies that we have today. And finally we'll look at the future and the opportunities that can be enabled by using such open building blocks to continue innovating in the industry. So just first of all in case you're not familiar with our company VNC Automotive. We started the company about 13 years ago based in Cambridge in the UK. We were a division of the real VNC company who were the original creators of the VNC, the RFB protocol, virtual network computing for controlling one device from another by way of viewing the screen and sending the events remotely. So that was used mostly for enterprise use but we were the automotive division trying to use that same technology inside the vehicle and that's how we got into the IBI space and such forth. So yeah, our main business is automotive software and hardware basically focused on the device connectivity so connecting different devices together to access those services in a smooth and convenient way as well as telematics and rear seat entertainment. Our software has been used in around 30, 35 million cars today. So we have quite a long heritage in this field and we have customers all over the world, quite a lot of them focus in the Asian region. So we have offices as well in Korea, Japan and China and then we do a lot of business in West Europe so Germany, France, those kind of markets and then North America, US and Canada. So based on our experience doing IBI projects and supporting customers in these different geographical regions we think we have some good input and feedback on the presentation I'm going to show today. Okay, so first part of the presentation. So we'll look at the trends which are driving the changes today in the software development in the automotive industry. So as you read on the news there's a lot of very exciting new customer facing innovations happening at the moment. There's a lot of work being done on ADAS to eventually get to driverless fully autonomous driving technology. So there's a lot of deployments already around the world. So Tesla is deploying this already in North America. ExPang is deploying this already in some cities in China with good success. And there's a lot of development on the hardware side to enable this, right? So on the sensors, whether using LiDAR as one approach or computer vision as another approach, that's all coming together to enable this potential future for the future. Electrification is another big area of innovation at the moment. So the car OEMs are very focused on improving the range of the battery, improving the efficiency of the motors to allow the driver to charge the car as little as possible. And when they do have to charge it to make sure it charges as quickly as possible to make it as smooth as currently it is with an internal combustion engine. And they're doing a lot of development, not just the OEMs themselves, but also governments and other industries around them into the infrastructure to make sure that there is that charging capability. And another big area at the moment of innovation is in the device integration. So bringing other devices and interfacing them into the vehicle. So things like digital keys where you can use your phone or special ID card to unlock your vehicle and also smartphone integration. So being able to connect into the vehicle from your phone to perhaps, you know, your upstairs in your house. You know you're going on a long journey before you set off. It's very cold outside. You can use it using the app for the phone, log into the vehicle and start the climate control. So the car is nice and warm by the time you start. So all of this development is coming on now and it's all very exciting. But what's not so much talked about is the huge amount of new software that is needed to actually enable all of this customer facing innovations. So that's what I want to talk about, you know, how the automotive industry is coping with such high amounts of new software developments. So if we look at the past, how have the automotive industry differentiated themselves? So that was always done through the hardware. So the hardware capabilities of the car. So that was the reason why I as a customer would choose one particular car we have when I was buying my new vehicle over another one. Either things like engine performance. So, you know, how powerful was the engine, things like acceleration driving style and also things like the materials being used internally. So, you know, usually very expensive cars will have very expensive interiors, very comfortable leather seats and wood accents and things like that. Another important buy and decision was the reliability of the car. So, as you know, the car, the internal combustion car is a very mechanical set of components. A car we M that can use a very high quality mechanics and optimize them very well can mean means the car can last a longer time without so much repairs. And that was one reason that, you know, you may want to choose a particular OEM over another. So as you can see, that's kind of always been their expertise, you know, the nuts and bolts of what makes a car. So this, you know, this kind of focus on the hardware elements, you know, let the business model for them into repairs and maintenance. So, you know, they sold you the car once and then they will get some revenue from you over the coming years that you have the vehicle as different components of the car break down. You need to take it to the garage, change, you know, change the tire or change some issue with the engine. They always, you know, they'll get a cut from all of these hardware parts. So that was kind of the traditional business model. So as you can see, software doesn't really play a big part in this. In fact, because the software in the car until recently couldn't easily be updated, the software had to be as stable as possible. And that meant they had to be as simple as possible, as an unambitious as possible to make sure that it was, you know, as reliable and didn't require any changes. So that meant the car OEM stuck to very, what I would say, you know, simple operating systems like Realtime operating systems like QNX, for example, which are mostly focused on, you know, just driving the mechanical aspects like the sensors and the steering controls, driving controls. Make sure that happens in a very smooth and reliable way. There is no big capabilities in those operating systems to provide very rich graphics or very complex user-facing applications. But, you know, things have changed in the last few years, as you know, if you bought a car recently. And electrification is one of the things that have forced that change in the industry. So because of the changing technology, the actual engines have become a lot simpler. The electric motors, because they are simpler, require less components, they end up being more reliable, so they don't break down as often. And also, they are cheaper to manufacture and cheaper to assemble. And, you know, because of these components, getting cheaper and getting, you know, getting less complex, it means that more companies, more suppliers have gone into the market and commoditized key components like the powertrains and the battery development. So that means that there's a lot of new car OEMs jumping into the market. It's a lot easier to start from scratch and build an electric car. You can take your batteries from companies like LG in Korea, get your powertrain from some European manufacturer, and then, you know, quite quickly you can put together an EV. So this means that the playing field has been leveled, and there's not so much difference in the hardware components being used. So the decisions that, you know, someone's buying a new car are thinking about, they don't see that much difference when they look at all these new EV vehicles, right? So that means that if you're a car OEM with a lot of hardware expertise before, you're striving now to differentiate yourself over these other potentially cheaper OEM alternatives. So that's one thing, but also the consumers, the customers, they, over the last ten years, they have got used to very rich, very powerful services, using, you know, running on their smartphones and their tablets, computers, those kind of devices. Development has come a very long way there in terms of the software, but also the user experience, you know, they look and feel how easy it is to use them, how all these services talk to each other. And they're now demanding such functionality to be available inside the car as well. So people, especially the younger generation, are now making their car decisions not just based on the power of the engine, but also on, you know, how easy it is to connect to a smartphone, does it connect, you know, does it allow me to use my Apple Music account, those kind of things. So both of these kind of trends have kind of come together to make the car OEM start focusing more on the functionality of the ABI experience. And that meant that they had to, you know, develop software and start using software as a way to differentiate themselves from the next OEM. So this is obviously leading to a bit of a change in how the OEMs work and design the software platforms. In the past, they would just specify a few high-level requirements and just let the tier ones make all the actual implementation decisions. That led with a very fragmented kind of experience. Typically, you know, a car OEM will have multiple tier ones supplying different models or different geographical regions. And that meant that, you know, different tier ones will end up choosing different underlying technologies. The user experience will end up being a bit different. And it just means that, well, both the consumer and the customer, you know, gets a bit of an inconsistent experience. But also it means that the car OEM doesn't have that much control in terms of pushing new features and pushing fast software development. Because, like I said, it was all kind of subcontracted out to the tier ones. So they're now trying to bring more of this in-house. And we've really seen this from some of our projects with them over the last few years. They are making the key decisions about what technologies and what features need to go into the next generation platforms that they design. And they're also trying to bring software engineers into their ecosystem as well. So things like the platform or some high level applications can be developed in-house directly by the OEMs. That means that they can more quickly, you know, innovate and add new features and push new software. But this is quite a kind of a frictitious rom-pop. The software needs that need to be met across many industries today. As you know, software developers are very, you know, very high in demand at the moment. So it's been quite a slow process to get the car OEMs to recruit the right people. And also the kind of developers they already had in-house or that were already working in the automotive industry tend to be more low level engineers, more experience in things like C and C++, looking at the low level systems. Whereas now, you know, if you want to have very nice and impressive looking graphics and animations and things of that in your HMI, then you're looking more at application developers which tend to be more experienced in the smartphone platforms. But also it's a bit of a change needed in the actual mentality of developing software. In the past, the car OEM, when they were planning the next generation units, they would probably have five to seven years lead time. So they start planning the specifications. The tier one then starts developing some of the software. There's some very rigorous long duration testing and then eventually ends up in the next car that goes into the markets in five, seven years time. Whereas now, you know, that needs to change. It needs to be much quicker. There needs to be a lot more iteration. Again, more akin to what happens in the smartphone world where applications and operating systems get updated very, very regularly. Kind of on a monthly basis as opposed to a kind of multi-year cycle that they used to have. So, you know, they're trying to get there and, you know, they are making good progress. But it is a big change. That screen show that I put there is taken from a recent Mercedes car. That's the interface for how to pair a Bluetooth device, which I think you can all agree still looks very old fashioned, very clunky compared to the smooth UIs you see on your iPhone or your Android phones. So, you know, there'll still be some some ramp up to get there. So, progression of our IBI services. So, we will have a look now at how the services that the user and the consumer is demanding on the car. How are they being brought into the IBI system over the last years, 10, 15 years, let's say. So, we'll focus on multimedia and device connectivity because that's the features that customers are asking about. So, things like, you know, navigation, accessing their favorite music, music content, those kind of things. But also, I'll focus on this area because that's the area that my company has the most experience in. So, I have a good insight into how that's been progressing. And I'll spend a good amount of time not just on the history of IBI development, but also on the key open standards and open technologies that have enabled that functionality. And you'll see as I go through that that a lot of lessons are being learned and a lot of decisions, you know, the right decisions are being repeated and carried over into the next generation. So, how have these services been integrated into the car vehicle in a safe way, in kind of a drive safe way? That's what we'll look at now. So, you know, in the early days, you know, people were starting to buy things like iPods and portable music players. They started accumulating a big database of MP3 files of the favorite songs. And they wanted a way to play that when they're in the car using the very nice, very powerful speaker system that comes built into the vehicles. So, that was the first service that kind of found its way into the IBI system. Apple tried to develop a bit of a standard for this using the iPods and iPhone USB connector, the old 30-pin connector before the lightning port came about. But it didn't really catch on a lot back then. Apple's market share wasn't as powerful as it is now. And, you know, car VMs were still very fragmented into how they embraced new technologies. So, that didn't go too far. I think BMW was one of the main ones that adopted this connectivity. But, you know, a few years later, Bluetooth became the way to share audio inside the vehicle. So, that's been widely implemented now across different cars, but also the smartphones and other devices, consumption devices that the user brings into the vehicle. So, you know, Bluetooth is an open standard. There's a specification that anyone can adopt into the products. There's a robust certification program to make sure interoperability works well. But they still leave a bit of room for differentiation across the people implementing Bluetooth in their products through the use of codecs. So, for example, Qualcomm have implemented some high bandwidth, high quality audio codecs in their SoCs. And, you know, Sony's done a different thing with their own products. So, this was a bit of an early kind of success story, I would say. So, you have an open specification. You have a good certification program. And you still allow a bit of flexibility and customization by each of the people implementing it so they can differentiate themselves. Navigation was the next big thing to get into the car from these portable devices and kind of the online world. Customers were unhappy with the way that the native built-in navigation was working, because the software wasn't easily updatable back then in the car. Usually it was quite outdated or unreliable in some areas. Whereas people were getting used to, you know, Google Maps and Apple Maps, those kind of services which were getting improved really quickly on the smartphone world. So, Ford was one of the first ones to try to bring this smartphone navigation app into the vehicle. So, they worked with a few specific up vendors based on their Ford Sync technology they tried to develop. But because it required a lot of work from the application developers and a lot of the key apps like Google Maps, for example, you know, was never really on board, it was very limited adoption. So, the car connectivity consortium came along a bit later. It was a group of all the major car vendors and the major smartphone vendors. They tried to develop the first actual kind of industry standard for how to bring navigation applications into the IBI screen. So, you know, they developed a specific specification that was available online. There was a certification program as well. But, you know, this was very successful. There was quite a few applications like SciJek and a few other popular ones. And parking applications like Parkopedia, for example. And it was widely adopted in phones and cars. But, you know, there's still some roadblocks there. Apple never adopted MirrorLink, for example. Certification program was quite tricky. They put a lot of restrictions into how the app should look and should work. So, you know, a little bit of adoption, but it didn't really catch on in the industry. But there was some good lessons to learn from that, which we will see carried forward into the more recent standards. So, the MirrorLink standard decided to grab a few of the open standards and protocols that were available at the time, rather than try to reinvent things or do them in a preparatory way. So, for the kind of the screen replication, screen mirroring elements, they used the VNC protocol. And that's how we became involved in this a long time ago. For audio, Bluetooth, as we talked about, real-time protocol for high-quality and compressed audio over USB was used as well. And device authentication, so, you know, making sure that a certified phone was connected to a certified car that was all handled through X509 certificates and a public key cryptography. And we will see that being carried through to the other standards. And then, later on, they added wireless support using the Wi-Fi display protocol from the Wi-Fi Alliance. And in terms of codecs to speed up the performance rather than sending, you know, uncompressed video data, they embraced the H264 standard, which was quite new back then, which is backed by hardware acceleration on both sides and delivers good performance. There's another standard you might have heard a bit about. So, it's called Smart Device Link. So, that was an alternative standard. Now, today, the good thing about it is not just an open standard, it's an actual open-source project. So, you don't just have to implement things yourself based on the specification. You can actually grab the full implementation from the GitHub page and quickly get up and running on your products. So, that was using more of a kind of web technology approach using JSON and RPC protocol for the communication. And then, for the user interface, using HTML and, again, relying on H264 phone mirroring for some of the rich content, like, you know, navigation, things that can't be put into a standard template of just simple data. Again, this had limited support because not many applications actually adopted this. You have to modify your application to enable this functionality. And, again, all the popular applications just didn't go this way. But, again, the fact that this was a fully open-source project was definitely a good step forward. So, that takes us to the last kind of five years, I would say. So, Apple and Google finally decided to make it possible to access these popular apps like Apple Maps, Google Maps, Apple Music inside an IBI system. So, of course, they did things their way. So, you know, they created the standards. They handled the certification program. They're kind of fully in control of the HMI and how that should look. So, that doesn't allow a lot of flexibility for the car VM to differentiate themselves. If you look at the car play screen on a BMW car, it will look the same as a car play screen on a Mercedes car. So, you know, that is changing. Apple and Google have announced some new features to provide a bit more customization. But still, you know, you really are giving a lot of control to the smartphone vendors. So, it's not ideal from the car VM point of view. But it has been very widely adopted because it's already built into those operating systems. So, the car VM doesn't have to worry about the phone side. Application developers don't have to do a lot of work either because, you know, there's a lot of good frameworks on iOS and Android to just make your app compatible. So, yeah, it's been really widely adopted pretty much every car VM these days with some minor exceptions, support Android Auto and or car play to enable music applications and navigation applications and even things like messaging like WhatsApp, those kind of things. But the interesting thing is, you know, they used all the same standards that we talked about from the last technologies. So, the video stream is encoded using H64 encoding. Authentication is handled again through X509 public key certificates. And Bluetooth is used for audio and there's other codecs for compressed audio over Wi-Fi. So, yeah, that's kind of up to the current standard. But if you look at this kind of current generation of vehicles, it's gone a bit of a step further. So, now that cars or at least some cars have a reliable internet connection rather than having to bring the application content and the internet connection from the phone they can just run the applications directly in the IBI and use the built-in SIM card to get access to the music library and the navigation content. So, these services are really integrated as web applications or in some cases, you know, people like Spotify and they will publish some web IPI that you can then develop your own kind of client implementation using HTTP and JSON. So, this gives the OEMs a lot more flexibility. So, as you can see, there's a screenshot there from an Audi car at the bottom right for Apple Music integration. It looks like it's an application running on an Audi car rather than some, you know, iOS interface. So, you know, that seems to be the way forward. But, of course, internet access is still not completely widespread. Still a lot of areas and countries where the connection is unreliable and then you lose access to streaming to your music and that's obviously still a big problem for the user experience. So, in terms of the building blocks in the IBI stack, you know, we talked about how the rich services like music, navigation and messaging have made it into the vehicle using all these open standards and open protocols. So, let's talk a little bit more about the middleware layer and then also the platform layer next. So, a key aspect in terms of middleware is authentication. So, for pretty much any kind of interaction that you do between the IBI and either devices or content, you know, you must make sure you have a secure, authenticated connection. So, that's done mostly with public key certificates and X509 standard. You're probably all very familiar with OpenSSL. It's an open source project which implements all of these cryptography standards. So, then you can very quickly, you know, add such functionality to your application rather than having to reinvent the wheel. And this is quite important and this is kind of the lesson to carry forward is that a lot of the times you need to pick what you want to differentiate on. There's no point in reinventing the wheel on some very simple, not necessarily simple but kind of low level functionality that if you get wrong, like cryptography, can actually bring a lot of new bugs and a lot of new issues into the system relying on something that's already published and already very mature is usually the best way forward. So, some recent application of authentication in the industry is this digital key functionality that a lot of the car EMS are now embracing. So, the car connectivity consortium, they've developed a standard for this using kind of building blocks like we talked about before in terms of X509 and then in terms of the communication channel between your phone and your car, kind of short range communication in a secure way either through NFC or Bluetooth for next generation. Another important layer of middleware is the car data. So, this is key for many different applications. So, things like insurance usage, making sure that your insurance company charges you accordingly to how you drive and your style rather than some generic profile that might be incorrect. Obviously, things like maintenance and fleet management are also key kind of consumers, let's say, of car data. So, there are some standards in the industry for how to talk about car data across different entities. There's this consortium called Kavisa which you may have heard about. They used to be called Geneva, Geneva Alliance in the past. They published this open standard called the vehicle signal specification which is basically kind of like a language model for how to describe car data in the vehicle. I don't know how big that screenshot comes across but it's based on this concept of a tree. So, you have sensors being the blue elements, so things that kind of pump out data and then you have actuators, the gray ones which you can actually get and set values onto. And then the branches can be grouped into higher level concepts so you might have a wheel and then you might have four wheels and then you end up with that overarching system you can dig deeper to read and set different values on. So, they make available a lot of tooling for how to generate actual code from the description that you set and they still allow some vendor specific functionality because the way maybe the unit that you talk in your system for speed might be different from the one that another OEM has chosen but it means that different entities looking at the same car data can have this common language between them. So, let's look at the platform level. So, in terms of IBI, AGL is a great example of pushing open source implementations rather than writing things from scratch. So, as you know, probably from a lot of the talks in this event, it's an open source distribution of Linux, customized for automotive. So, they've taken the Linux kernel and then they've added a lot of services and middleware to make it easier for a car OEM or someone developing some automotive product like clusters or third-party devices to get into the market by just focusing on the key branding or the key differentiating features. So, they use the blue set as the blue to stack. They use Wayland as the mirroring system, the windowing system. So, reusing all of these open standards and open protocols internally. Android is the other big player today in the IBI and they have the open source project called Android Automotive. So, this is a version of AOSP which has been customized to work in the automotive world by giving you access to the vehicle hardware extraction layer. So, then you can connect into your Canvas or whatever system you have for reading and writing the car data. So, the operating system itself is open source. You can just stop there if you want or if you also want to use the Google services, things like Google Assistant, Google Maps. You can then license their Google Automotive services which comes with a lot of requirements, a lot of restrictions, but you do get these great applications which, you know, the customers really enjoy and means you don't have to build them yourself from scratch. But, you know, there's a bit of a riff there. Some OEMs, they have gas and non-gas models, so there's a lot of kind of disparity there. People like Stellantis, I was reading recently, they launched Android Automotive with Google services, but they now decided to back away from that for the next generation because running the Google services is very taxing on the hardware resources and also, as we kind of covered a bit with things like CarPlay and Nudoto, Apple Maps and Google Maps, I mean, we'll start looking the same in the Volvo car as the Stellantis car, so, you know, there's a little bit of friction there, but there's no denying that Android is kind of here to stay in the automotive world. So I'll just get towards the end, whereas I'll leave us in terms of the future. So there's two key ways at the moment of pushing software to cars which have made things a bit easier in the industries over the air updates, both, you know, LTE or Wi-Fi, depending on how old your vehicle may be. This is great because it means that open source software that you're using in your platform can receive security patches often, you know, you may remember things like hard bleed vulnerabilities a while ago in OpenSSL. You know, it's very important to be able to patch these things quickly. And also, over the air updates, it means that you can, as a car VM, you can push new services and features kind of quicker to your users. You do have to be a bit careful. You know, there's already a bit of a trend of trying to push software as quickly as possible, and then, you know, force customers to call this massive day one update to actually fix all the bugs that you didn't have time to fix before. That's something that you see in the gaming industry, so, you know, you don't want that happening here in the automotive industry, but, you know, clearly there's a lot of flexibility enabled. And, you know, subscription services is another important trend coming in. People are used to this from their phones and their web services like Netflix and Spotify. And the car VMs are starting to jump into this a little bit as a way of getting a new revenue stream in the vehicle. So, you know, this is quite good for the consumer. You know, it gives you flexibility. It means you can try some features before you actually commit to them. And it also means that you, you know, if you then decide to sell the vehicle, you know, let's say, like in the Tesla case over there, if you bought a full-cell driving package for your vehicle for $10,000, $20,000, you then sell your vehicle two years later, you then have to buy it again, you know, you lost that investment. So, you know, being able to enable and disable features as your needs change is quite a nice user experience. And it encourages OEMs to keep innovating, right, because if you have someone paying for the service, you want them to keep paying for the service. So that encourages you to keep adding new features, keep fixing the bugs of their report, and it will keep improving the software. So in conclusion, we looked at all this different, you know, this model that's being used quite successfully in the IBI services with the combination of open protocols and open standards to deliver really rich experiences. You know, I think it can work well across the industry. And then, you know, how you actually glue these building blocks together as a car OEM or as a device vendor and how you make the user experience as smooth as possible. So that's how you go into differentiate yourself and make the customer choose your car over your competitor's car. So, yeah, I encourage everyone to keep, you know, developing and using such open building blocks to keep pushing the innovation forward. Okay, thank you very much. If you'd like to learn more, we have a booth in the next hall next door. If you'd like to see more about this or hear more about it. I think we have a couple of minutes, maybe, for questions. If you have anything you'd like to ask either now, let me know. If not, please come and find me here. Hi. I'm trying to wrap my head around this subscription services model. So you showed the BMW service where you have to pay for heated seats, right? Yes. Now, all of a sudden, you have to pay for a feature that you expected to have when you buy the car. And heated seats is one example. I mean, probably thinking of other services that want you to pay. You know, maybe you'll pay for sport mode in your car or steering wheel and all that. Have you seen anything to tell us whether there's customer acceptance for these things? Because my cynical view is that they'll still sell you the car at the same price and then they'll charge you extra for these services. That's my cynical view. No, that's definitely been shared. If you read about this, there's been a lot of backlash about the BMW heated seats online already. Customers are not happy about that. It's something like $15 a month, which if you're going to have it for five years, that's a huge amount of money you're paying just to have this feature that, as you said, you had before. So I think they may be a bit too aggressive about this, the car OEMs, and there will be a bit of push and pull. But it does have advantages for both the consumer and the OEM. So we'll see how that pans out. It reminds me of what Ryanair did when they had to pay to use a bathroom. Yes, indeed. We've seen this kind of thing as well in the mobile space. There's all subscriptions and things like in-app purchases and applications. So that will shake up in automotive industry as well. Okay. I think that's everything though. Thank you for your time.