 So, first a question to the audience, or a couple of questions to the audience, who has been on FOSTA 3 years ago, okay, a couple of you, who has seen the talk that we have been giving 3 years ago at FOSTA Month, okay, just a few of them, okay. So, 3 years ago, I was in FOSTA 2014, and I proposed an idea to create an open source software platform for autonomous driving systems, and a general idea was, okay, we want to reuse software that's existing in the open source community to build up a software platform that's going to be running on an ECU in the car. And this is work that I and two colleagues of mine, that's Thilman Ochs and Daniel Wagner, had been interested in, and we have been working on this for the last 3 to 4 years. And we can now say that we're at some point that we have some first insights, some first results, how the project worked out, how it might continue, right. So, the title on the internet was, success and failures in building such an open source software platform. I changed the title, make it a little bit shorter, and I changed the word failure to difficulties. Failure is only when you give up, right, so we haven't given up, but there are some difficulties that we still have to overcome. So, who am I doing this for? So I'm working for a company BMW Carity that is a subsidiary of the BMW car company. It focuses on software development. We actually consider a vehicle, not as something from metal and plastic and so on, but actually just as a very small distributed system that happens to be running on four wheels, right. So it's just a simple distributed system and you can do all the software development that you know in such a system as you would do it in an IT system. We use various open source software. We participate in a few open source communities in our area and contribute back our work in these communities. And this company asked me four years ago, so how will the future ECU for autonomous driving look like? And that was our basic motivation in 2013. What's the technology that we're going to use when we want to build such an ECU? And this is what we call a software platform, right. So if you look into the automotive industry, there's actually for autonomous driving, you'll have two classes of software functions, or yeah, general software functions. So you have control software and you have cognitive software. Control software is that what we have been doing in the automotive industry for 30 years. It's a very simple controller that's running on a low-power, yeah, low-cost ECU. And this has evolved step-by-step over the years. So the code is getting more and more complex, but it's generally still of the same type. It's a state machine. It has to solve some kind of differential equation. And it is matured over the years to a certain state of art. We use a very static software structure. So you design it once and you never change it again. And you can run it on very low-cost ECUs. On the other hand, for autonomous driving, we're going to have a new set of software functions that are going to be cognitive software. So these are much more functions that you would expect a human to be doing in the past, but now occur to be doing by its own. So you have to perceive the environment. You have to reason about traffic situations. You have to predict how traffic participants will behave. And you have to somehow communicate as well with other participants on the road. And for this cognitive software, the need, you have completely different requirements, different characteristics. It will use dynamic models. It will use algorithms that you know from artificial intelligence. It is rapidly evolving. So you can't just take one technology and say, OK, that's going to be the technology for the next 20 years. You have a dynamic software structure, and things will change much quicker. And you run on ECUs or you run on hardware that is high-performance mainstream hardware. In fact, two key use cases that you have to consider when you want to build such a software platform. The one is that you have this high-performance computing. This means that we will have, we want to decouple the application software development from the hardware technology and the hardware technology that we're thinking of as some typical software that you would know from desktop computing. So right, we have 86 architectures. We have GPUs. We have FPGAs. We have certain DSPs. We have a DRAM. We have NAND flash. And all of this is in one ECU. And you want to decouple application development from that. A general thing that you also have in desktop computing. Second thing is that we will develop the software. And while the software is actually put into a product, we have to find out what are possible failures. We have to improve the software as is actually put in the field. In the beginning, we will have functionality that has to be observed by the driver. But we want to continuously go up and up in our confidence to this point that at some point we can say, OK, the driver is out of the loop. But for that, we have to improve the software over time in a running fleet. And these two use cases motivate a completely new software architecture. So the software architecture that we came up with is roughly as follows. You use Linux as an operating system. You want to use some kind of communication middleware that offers you some kind of dynamic connection of components and the usual patterns of sender receiver and remote procedure call. So something that you might know from MQTT. And then you have certain functionality that's more or less automotive specific. And as this is non-differentiating, you could do it as an open source software. So our primary assumption was we have a software platform that provides the basic functionalities that you need in ECU. And this is open source because it's not visible to the customer. And it's not differentiating. So we do it as open source. On the other side, we have a core business. We want to sell something to our customers. And that would be the usual driving functionality and that that would be kept as our product. But this black and white thinking that we had in the very beginning turned out to be not really true. And there are some kind of gray areas. Mainly, when you get into the more automotive specific functionality, we found out it's much easier, even if it's not visible to the customer, it's much easier to have a cooperation that is gated. And this means you want to work together on a software development, but you have certain terms that you have to agree on beforehand so that the cooperation works. The reason for that is that we're considering a... We all consider the same market segment. We all want to sell the cars to the same people. And we don't actually have different possibilities of differentiating within this market when we consider software. So we actually have to make rules and say, okay, if we want to cooperate on these things, the software development, everyone has to contribute to that. And we ensure that by certain contracts. So here are some examples, right? You know open source development, for example, the Linux project, maybe you know the Yachter project, it's a tool chain for embedded development. We have a gated cooperation within the automotive industry that's the AutoZone development partnership. And we have core business functions that you can more or less buy in our products. So it's like remote control parking or driver assistance systems. So what we have to do is we have to find out where do we place certain functionality of our platform into which of these boxes, right? And as we had these discussions internally and with partners, we've actually found out, well, for the operating system of this platform and the isolation mechanisms, we actually can work together. There's a large market, you can use open source, we can contribute to open source. On the other side, we also imagined that you could do some kind of vehicle-wide software update. And there it turned out that this is a core business of the automotive industry. It's, this is something that might first not seem visible to the customer, but it offers such a benefit in the development and in the services that we can offer to our customers that it remained a differentiating factor, or is considered still a differentiating factor. So vehicle-wide software update functionality is in most companies a core business and internally. And then we have other things like model-based development, diagnostics and the communication middleware that was more or less developed in this gated community because for diagnostics and model-based development, the automotive industry is the main user and the main participant of that development. For the communication middleware was kind of difficult. It could have been open source, it could have been a gated corporation, so it's still open which one it will be. Especially when we look into the communication middleware, this was a very, very difficult task. In the very beginning, we looked into the existing implementations and existing products that are available and we saw, okay, there are three or four choices that you could make and we would just have to make one. Then we continued the technical discussions and found out, well, they're actually really from the functionality side, they're very, very similar. And then we had to make the difficult decisions and it turned out that we had to understand the whole history to understand how these situations emerge that we now have. So in 2003 or yeah, around 2004, the AutoZare Consortium was found and there was a common runtime environment that's in C and that was implemented and it's one standard, multiple implementations for that. And from that, in 2011, the SEMIP protocol evolved. So it's a protocol that works on Ethernet as IP-based and is a de facto standard within the automotive industry for Ethernet communication. From this SEMIP protocol, two new C++ APIs evolved. The one evolved in around 2013, that's a common API C++. It's developed within the Genevieve community, it's an open source product. And in 2015, they started within AutoZare, another API, Adaptive AutoZare Communication API. Again, C++, similar functionalities similar feature set. On the other hand, in the robotics industry, they had a development that started around 2008 and is still ongoing, that's the ROS middleware. It has again similar functionalities as the other C++ APIs and this has built up a huge community in the robotics research area. In around 2014, ROS wanted to reinvent themselves, they wanted to build a new API. So they intentionally chose to have a remaining version of ROS 1, that's ongoing and maintained and they created a new version, ROS 2, that was based on the DDS standard that has been used in mainly military context. But it was a standard that was at least standardized within the OMG, so the object model group. And now we have this situation that we actually have five different C++ APIs. So the question is, is this a problem for the automotive industry or not? And the problem in the automotive industry is that we have a very long tool chain of software development. So there are various companies that have to collaborate with each other so that you get the final product of your software. You have the OEM that integrates it into the car but he doesn't do the whole software development itself. He has a tier one, he has possibly multiple tier ones that he works together with. The tier ones work together with someone else, tier two and so on. So you have a huge group of companies that have to cooperate. So reasonably, they all use the same APIs. And now we have five. So it's clear that you want to have convergence that you can actually save money and you can quickly come to product. So the question is, how will this evolve in the future? And for the first two, for common APIs, C++ and adaptive auto-zar communication, you could expect convergence because it's within the same industry. It's actually the same development company. So BMW is involved in the development of adaptive auto-zar and BMW is involved within the development of common APIs, C++. So if people within one company can figure it out, it would converge. It is based on the same protocol and it uses similar terminology. That's already good for people right when one person speaks about a channel and the other one knows, okay, channel means this. Right? Similarly, ROS1 and ROS2 have evolved from the same company and then convergence is actually intended by design. They wanted to try something new out. That's why they called it ROS2. But they intend once it's in a stable state that they all move the whole ecosystem from one to two. So how about convergence of these two paths of the robotics industry and the automotive industry? And there, there's at least some indications that convergence could be possible and would happen. So just tell you a few of them. They're actually used within, both technologies are used within the same organization. So if you look for presentations on Adaptive Autosau and you look for presentations on ROS, you will see that BMW and Bosch have presentations about it. But there are also other companies that use that within the same company, right? They have complementary strength. Adaptive Autosau focuses on a specification. And ROS is actually very strong on the implementation side. They have wide support for different programming languages and they have a great tooling environment. Also, we have a possible adoption through the next generation employees. So ROS is used in taught in universities. There are various tutorials on the internet and people learn that from the beginning. And the automotive industry is of course hiring many people at the moment due to this type of autonomous driving. So they'll find the many graduates and they'll probably come with this mind that they have a certain tool already learned in university. And on the technical side, the API design and behavior is actually very similar. They follow very similar design patterns. They have a slightly different service discovery mechanism but this is probably something that you could overcome and they have different terminology. Again there you would just have to find out if it's possible to come to the same words for the same mechanism. So I'll just say a few words to other aspects that we have considered. So I said we would use Linux operating system as a basis for this software platform and when you think about it, if you want to use it for autonomous driving you have two points that you have to address. How do I do software related, how do I do safety related software development and how do I ensure the real time property of the system? And we've been involved in both these fields. So if you consider what was the state that we started in in 2013, we actually talked to people and they said, well, safety related software development you do and see and you use a dedicated operating system. So if you look at this state now in 2017 there's actually a lot of discussions and plans to do safety related software development in C++14. So we've moved past this, everything must be in C and we're working on a Linux qualification, safety qualification for Linux so that we can use Linux in a safety related area. On the real time side in 2013, the pre-empt RT patches from Thomas Gleisner were out there but they haven't been in the mainline kernel. Everyone could use them but they've never merged into the mainline kernel and had to be maintained out of three. There was a minimal funding by Osado to keep this happening but there were no plans for mainlining. So now in 2017, the Linux Foundation funds Thomas Gleisner and his team and they're making this preempt RT mainline and I think if you find them on the conference I've seen in yesterday, it's probably gonna tell you it's gonna take one or two years and then it's gonna be done with that. So what has happened in the last four years? Generally the perception on open source on Linux has changed. So as I had discussions four years ago, people were just saying, well yes, you want to build this software platform based on Linux. Well, Linux is just not good enough. And now four years later, this has changed from, well yeah, Linux is good but you know safety, it's not good enough for safety. And we have now actually moved even to the point where people say, well, Linux is really good enough for safety systems but we just don't have it proved yet. So once we have that proof, we could actually move on in that step. But the story isn't over, right? We see that there's a lot of work still ahead of us. I mean, the convergence of this adaptive Autosar communication specification and there was two efforts is gonna be a lot of hard work. It's still unclear how you would actually create a long-term collaborative model for safety qualified Linux so that actually companies can cooperate on a core safety asset and still build their products. And the mainline work on real-time capabilities in Linux is certainly funded by the Linux Foundation and yeah, Thomas Glakser is working hard on that but there's still a lot of work ahead, yeah. So that's my talk, any questions? So the question was if the ROS software is good enough for production use, right? And so I presented some work on ROSCon that we would have to, if you take the current ROS development, it's not gonna be good enough for this software development in the car. The authors of ROS actually confirmed that this is true, right? It was a student project that they had and it served that purpose. So that's why they created ROS2, to actually address all those aspects. Is it good enough for safety? Does it have certain fallback mechanisms and so on? The 2.0 should be good enough, yes. Yeah.