Assisted and Automated Driving at Porsche
Dr. Jürgen Bortolazzi, Senior Vice President, Head of ADAS and Automated Driving, Porsche
Since the introduction of Park Distance Control and adaptive cruise control in the mid-2000s, Porsche has integrated driver assistance and automated driving technologies into its product lines. This does not contradict the philosophy of a sports car—customers who like to drive themselves in appropriate traffic conditions expect driving to be made significantly easier in stressful, time-consuming situations such as traffic jams or busy parking spaces.
Although the general discussion focuses on the higher levels of automation from SAE Level 3 to Level 4, Level 1 and 2 systems will play a significant role for the next decade, at least, and represent the technological state of the art for most vehicles. In this environment, Porsche is focusing on increasing the performance and functionality of Level 1 and 2 driver assistance systems while developing programs that enable automated driving at Level 3 and 4. This offers the opportunity to build the necessary expertise in sensor technology, sensor fusion, planning and control, as well as the processes, methods, and tools required for the development, approval, and release of higher-level automated driving systems.
Systems engineering must be combined with approaches to processing very large amounts of data, while traditional random testing on the road must be transformed into a combination of virtual and systematic testing. Finally, a new end-to-end electronic architecture is required to ensure the seamless integration of the vehicle with the IT infrastructure.
In this keynote speech, hear Prof. Dr. Jürgen Bortolazzi illustrate how Porsche is addressing these challenges in the development of assisted and automated driving.
Published: 4 Jun 2024
It's a great pleasure for me to present some thoughts about ADAS and AD, and also, relating this to the second topic of this conference, which is software-defined vehicles. So my history and story with MathWorks is pretty long. reminded me that we met in the beginning of the '90s, talking about model-based development, which was my topic at Mercedes Passenger Cars at that time-- code generation for target systems. So long and successful story and history that we have followed along together.
So I will focus on assisted and automated driving, give you some overview of what's going on-- lots of challenges, some solutions, and let's get into the presentation. I will be talking about automated driving, the role. Porsche is not necessarily the forerunner, if you think about automated driving. I will explain how this fits into our product strategy and where we want to go in the next years. We have some roadmaps and trends. Excuse me.
My focus will be on scalable architectures, because I think software-defined vehicle and the underlying hardware is especially important for ADAS and AD. We need to establish scalable solutions. Otherwise, we will be overwhelmed by the complexity that we have to handle.
And also, the economical challenge is definitely there, to handle all this software complexity. But also, the data complexity. I will focus on data-driven engineering-- also, a little bit describe our development framework, which we are working on, which is not ready today, but where, especially, also MathWorks components play an important role, and very quickly elaborate on the role of AI and our current perspective on that, respectively.
So in the beginning, I wanted to motivate the mutual interrelationship of automated driving and software architectures and software-defined vehicle. So both, let's say, have, from both sides, motivating factors. On one hand, automated driving is, besides digital cockpit and the driver experience, one of the driving factors for software complexity in the car.
So we started, as you will see in, let's say, one of the slides with a centralized ADAS unit in the middle of the 2000s, together with Audi. So we have some experience in centralization, which is one of the SDV factors. But for sure, automated driving is one of the driving factors here. The software complexity demands mandate both scalable software solutions, but especially also scalable hardware solutions. It's pretty obvious when you look at the sensor sets, but it's also true for the centralized control units where the functions and the software runs on.
In ADAS and AD, we will be mandated, if we introduce level 3 and 4, to provide a seamless life cycle management. That means not only at the level, develop the systems once and bring them in the field, but we have to install a field observation process and an incident detection mechanism, including error correction and fast response to incidents in the field. Otherwise, we will not be able to introduce level 3 and 4 to the field.
And therefore, we need additional capabilities, like over-the-air updates and upgrades, and so on and so forth. And last but not least, we have the big data loop for sure. ADAS and AD is, let's say, by far, the producer of the largest amount of data that we have to handle both in the car, in the vehicle fleet, and in the cloud, respectively.
So first, how does that fit into the Porsche strategy? Porsche is a small vehicle supplier-- not supplier, but car manufacturer. Sorry. And we focus on premium cars, on sports cars. We produce a little bit more than 300,000 cars per year, but focusing, really, on premium cars, high-end, cars, high-performance cars. We follow along a clear strategy, and our main driving factor is electrification of the complete car portfolio, except the 911, which is our, let's say, brand icon. And we always say that the 911 will stay on combustion engines as long as possible.
There is some hybrid approaches and so on and so forth, but all the other car lines are under way or are already fully electrified. And with the Taycan, we introduced, as one of the major innovations, a new and energy supply system with the 800 volt technology. At that time, the whole industry laughed about us, and said, OK, the small company Porsche wants to establish a new standard. As you know, probably, many follow now. 800 volts has many advantages over the 400-volt voltage level, and therefore many follow, now, this path.
Another example for innovation driving is our latest active chassis control system. For those of you who follow, let's say, the media, there is really enthusiasm about this new active chassis control system that we introduced in the Taycan and the new Panamera. ADAS and AD is part of this innovation strategy, and we will follow this along. Our newest part of the portfolio is the electrified Macan, which we introduced this year into the market.
[DRAMATIC MUSIC]
So this car will present a new level of car dynamics and performance in its segment, and it's also following along our AD strategy, which we will see in a few slides. So our main focus is still self-driving capabilities. Nobody would buy a Porsche for being able to do automated driving in a Porsche. But it's quite clear that for as we have a widespread customer base, and many of our customers use our cars, even the 911, the sports cars, in a day-to-day usage scenario. For the daily driver, we need aspects like safety, we need comfort, and we want to take the opportunity to give back some time to do other things while sitting in the car.
Just to give one example, if you look at the metropolitan area of Shanghai in China, the average speed of our customers measured over the fleet of cars that we have available there is 5.6 kilometers per hour. So nothing to do with high-end performance there, you can imagine. And people spend hours in the car. They want to use this time to do some work, some site activities, whatever they want to do.
Our roadmap is long and challenging, so to say. I mean, ADAS/AD is something where every day is a new surprise. So we follow along. So we introduced safety functions and so-called NCAP functions, emergency braking, very early into our cars, and also longitudinal control systems. And followed along, we introduced the centralized ADAS unit in 2017 together with Audi-- the Centras System, which was the first centralized ADAS unit in the market, and just, let's say, kind of a breakthrough in this direction. We follow along also this strategy.
We introduced predictive longitudinal control systems, taking into account, also, the electronic map to allow for a forecast of the upcoming topology. Main focus was to optimize energy consumption, which brings up to 10% of range, or, let's say, energy consumption. And we are underway towards automated driving for level 3, at the moment. So this is our focus, and let's see what comes after.
So just to explain how this path and this roadmap looks like, and how the things are differentiated from each other-- to start on the right side, level 5-- is and robotaxis is not a topic for Porsche at all, so we are not working on this, because level 5, if you take it rigorously, it would mean really fully autonomous, always and everywhere. And we think that this is a real future music, although a number of companies are pretty, let's say, enthusiastic about it.
But this is another topic. We are talking about ownership cars-- cars that are owned and operated by the owners. So we start the level 2++, where, compared to level 2 ADAS systems, have the benefit of more human-like driving. There, AI comes, also, in into the scope, and the first opportunity to take the hands off the wheel, although you are still enforced to observe and control the car appropriately.
With level 3, we have the opportunity of side activities, although the driver is still in force. So we have stringent takeover requirements with a few tens of seconds the takeover has to take part. And also, the man machine interface has to develop in a way and implement it in a way that this is possible. But there, we have the chance, now, to take our eyes off the road, our hands off for sure, and therefore, side activities are appropriate.
And if we look at the level 4, we think that from the technology perspective, therefore, we put them together, it's quite close. It's not the same. The major difference is not in the ADAS or AD system, where we already, with level 3, have redundancy, we have the sensor set that we need to do automated driving. Level 4 is really related to a completely new car concept, new interior concepts, because if you have a lot of time available for side activities, you do not want to sit like this in the driving position.
You want to relax more. You want probably to turn around your seats. We need completely new safety systems, passive and active safety systems. So level 4 is really a challenge in the area of whole vehicle design. With level 3, we are prepared to provide a necessary functionality.
A few words about ongoing trends. And those of you who follow the topic, we have a major trend in the automotive industry. So many of the traditional car manufacturers come from level 2 ADAS and now scale up and develop technology. L2++, L3, L4 follow this path. And others-- companies like GM Cruise, like Waymo, just to name two of them.
And you see this GM Cruise, this Waymo car here. And if you're in San Francisco area, then take the opportunity to use one of these cars. You can be driven driverlessly wherever you want to go in the San Francisco area. It's really amazing to be able to experience this.
But these cars come from the other side of the technology development with a much different cost basis. So we are, today, talking about a factor of 10 company approaches that come bottom-up, compared to the approaches that come top-down. That is related to the sophisticated sensor sets and the immense compute power that these cars have onboard.
So to scale them down is one path. It's a challenge. To scale ADAS systems up, it's also a challenge, and we will see who will be successful in the future. We think that the bottom-up path is the path to follow for ownership cars, not for mobility as a service, and so on and so forth.
The trend towards huge onboard compute power can be recognized if we look at our Chinese competitors. There, you see extensive sensor sets-- up to four LiDARs-- and I put this down here-- up to four LiDARs, including radars and cameras, a huge amount of data that has to be processed onboard. And that leads to enormous compute power-- more than 1,000 teraoperations per second onboard.
And I think of my University time, a long time ago. But I wish I had this processing power in our central processing infrastructure in at the complete university at that time. So we are talking about this. And this will go on. If you look at the roadmaps of companies like NVIDIA, Qualcomm, we the next generation of SOCs will provide even much higher power, and that is also related to the necessary complexity. So this is a trend. And I put it in words-- the new horsepower is the number of LiDARs and the onboard compute performance that we can recognize.
What will we offer with L2++? So because one of the topics of this meeting is also collaborations, we went into strategic collaboration with one of the technology leaders, which is Mobileye-- not only Porsche, but also the whole Volkswagen group, including Audi and Volkswagen. We worked on L2++ up to level 4. So these are the functionalities.
So we have highway access and exit automation in this area, automated lane change. We have in all kinds of-- all types of roads, follow the navigation. That means you enter a navigation target, and then you will be automatically driven to this target. And on the left-hand side is the real challenge, even for L2++-- to go into the urban areas wherever it is allowed. It is not allowed worldwide. This is clear to say.
So you have the necessary regulations to be in place. But there, we talk about coping with roundabouts, traffic rules, like the well-known four-way stops in the US, which is a tricky thing for an automated car, recognition of traffic lights-- sounds simple, but on a road with eight lanes and lots of traffic lights in front of you, what is the traffic light that is relevant for you? And you have to be absolutely sure that this is the case. This is really a challenge.
This corporation relies on a scalable sensor hardware and function architecture. On the left-hand side, you see the scalable sensor set where we start with a combination of a complete 360-degree camera belt and a radar belt for L2++, and then we add additional sensors, especially LiDARs for the L3 functionality, in this case. That means we also need a higher, let's say, processing power onboard that is related to our scalable hardware architecture, where we start with a L2++ central unit with two of the latest Mobileye SOCs-- EyeQ6 High-- which incorporate the necessary processing power.
And this L2++ path then allows for the main path, driving path, that is then accompanied with a redundancy path for L3, and we can even extend this to a L4-capable system. And we have, on the right-hand side, also, the scalable function set. And the underlying software architecture has to be provided in a way so all the basic services-- let's say, the SDV services-- upgrade, update, data handling, and so on and so forth are developed once, and are then used in all of these, let's say, scalable variants.
In a little bit more detail, you can see that the sensor set for L3 is very much extended. So that means, let's say, for our processing units, that we need the capability-- you see here, where we start with a two-chip system that incorporates the functionalities that are shown here up to hands-off, but still observed by the driver, and then adding a redundancy path, a third control unit, including, also, the necessary redundant power supply, the redundant sensor data supply, to be able to address L3 functionality.
On the software architecture side, and, let's say, the combination of the hardware capabilities and these SOCs-- and they are representative, so to say, for, let's say, the latest SOCs that you find in the market-- they consist of a general purpose unit, like an ARM core, or several ARM cores, and additional GPU or hardware accelerators, especially designed and fitted towards the needs of the functions of the algorithms.
And therefore, it is definitely important, if you select these SOCs, or you develop them by yourself, which is also a major topic at the moment-- I'm personally absolutely convinced that you will fail if you have not enough knowledge about the needs of the algorithms that you develop. This is something that doesn't really fit. You cannot develop an SOC standalone and then hope that this will fit to what you want to do with this approach.
So data-driven development and electronic maps. Just a short introduction. We used the complete Volkswagen fleet and, in future, also the Porsche fleet, the Audi fleet, to generate and do onboard processing of sensor data, send compact data up into the cloud. We do not rely on high bandwidth. We send small chunks of data that focus on landmarks, for example, or representative details. We then generate an annotated map from that.
So it's not an HAD map, a highly high resolution map that is used in some of other approaches today because HAD maps require a lot of maintenance effort to keep them up to date. Here, we have an approach where our fleet-- and the Volkswagen fleet is pretty large-- is taking care of update and upgrade of the map. And that is a pretty intelligent and smart approach. We then download this annotated map into the cars, and this allows for a, let's say, precise localization, and also a predictive control functionality.
So how do we develop and validate and verify all this? So three major sources of requirements and constraints for the development of ADAS and AD systems. We have, for sure, the customer requirements. We have all the functional safety and software of the intended functionality requirements, and additional standards. Also, security. It's not named here, but it's quite clear, because there is no safety without security. I think this is also pretty clear. And we have lots of regulations-- unfortunately, not commonly used or standardized worldwide, so we have to meet many different variants of regulations.
So we have to do requirements and management and architecture development. We extensively use model in the loop, software in the loop, and hardware in the loop technologies, where we use, also, the MathWorks products since many years. We still rely, as part of our validation and verification strategy on prototypes, early prototypes, to generate data with, let's say, the appropriate sensor set, and later on, also, to validate the functionality in the target car.
We have the test tracks, which are specifically designed, or, let's say, updated, upgraded like our Nardo Technical Center in the south of Italy, where we use, also, digitization approaches, together with MathWorks, to be able to run simulations on, let's say, the test track. And last but not least, we have to handle these huge amounts of data. So we are talking about petabytes of data that have to be handled and operated in this framework.
So if you look at the validation and verification strategy, the question is, what is the approach? I mean, the traditional approaches, mostly, let's say, based on test track validation and public road testing, would lead. And out of the safety concept, you can calculate that we would need more than 3 billion kilometers of testing. That would mean 100 prototypes running for 100 years.
And it's quite clear that this will not lead to success. So we need the new-- and not all of them are new virtual methods-- rapid prototyping, digital twins, simulation, re-simulation, where we use sensor data from the field and feed that into a software in the loop environment to do extensive testing-- and all this is necessary to come to an appropriate or a realizable verification and validation strategy with, let's say, a much reduced number of kilometers or miles.
One of the requirements is, as I mentioned, a complete life cycle management. That means that we have to observe the complete fleet. We have to identify incidents. We have to generate tickets. We have to do a first-hand analysis of these incidents. We, as an OEM offering automated driving in the future, if we detect an incident-- a severe incident, safety critical-- we have to degredate, or even, let's say, deactivate the function in all cars in the field. Then, we have the necessity to develop a solution for this problem. We extensively do testing in the simulation environment, and then roll this out to a test fleet.
There, shadow mode is a topic. That means running a new functionality in parallel to the, let's say, released functionality. If this is OK, we do further data collection and ingestion of this whole fleet-- large amounts of data, again-- and then we do an approval and release, and then we can roll out this functionality. And hopefully, we are able to run through this complete chain of activities within weeks or months, not years, like today. This is one of the major challenges that we face here.
How do we do that? We have established, over years now, a cloud-based framework for doing all the necessary development, verification, and validation steps to, let's say, reduce my time consumption. I want to focus on the left-hand side. The real challenges are end-to-end traceability of over all the methods and tools that we use here, focus on scenario-based techniques, where tools like RoadRunner-- MathWorks-- is used extensively.
And on the other side, integration, verification, and validation, I want to focus, and one of the major challenges is to provide a verification and validation environment that fully represents all homologation-relevant aspects, ideally in a fully automated manner, and that would be what we are hoping for.
So a few examples how we use these virtual methods in the very early phases. One of the challenges is really doing sensor positioning and packaging. So there, we have a lot of target conflicts between the technical requirements of the sensors-- so the field of view-- that often collides with styling requirements, with packaging requirements, with cooling requirements. And therefore, we need, in many loops, to be able to optimize the sensor set.
We then have, on the second column, the virtual function development, where our first steps are to try out a new, let's say, control functionality, new algorithm, linked to a sophisticated chassis model which we developed over years at Porsche. Then, in the third column, we have the virtual integration and test. There, I want to, let's say, put an eye on the virtual coverage of variants.
So in the meanwhile, we just do a real, let's say, physical testing and measurement for the so-called corner variants. That means two-edge representants of the variant portfolio and all the variants in between-- tire variants, chassis variants, powertrain variants-- are validated through simulation. We also test, let's say, specific situations, like this pedestrian crossing here. And the last column shows our focus on the objectivation of the results. We need KPIs-- that means targets in numbers-- that we want to head for, and as I mentioned, also, fully coverage of the homologation tests.
My last slide shows the opportunities and some of them already realized-- that we see for the usage of AI not onboard, but in this case, in our tool chain. So it starts with, let's say, AI-based cornered case detection and all kinds of big data analytics that we can do. I want to point out that generation of synthetic data sets is a real field of activity and research that we elaborate on and have a high interest. And you can see there's many other fields that we can elaborate on, and we are starting activities or are already running activities to accompany and to, let's say, extend our data-driven development methodology through these AI-based methods.
So to come to the summary, I hope I have shown that SDV and automated driving are mutually interrelated, are linked to each other, so there is a necessity for automated driving to rely on SDV functionalities. With regard to AI onboard, we are still, let's say, have open questions and things to do with regard to the safety standards that are not covering AI fully as we expected to be able to bring it to the market. But we see huge potential for AI, especially when we look at our data-driven development and validation methodology.
And last but not least, we appreciate the long-term cooperation with MathWorks, and see, also, many opportunities in this area. Thank you very much for your attention. And if you want to discuss a little bit, I will be available afterwards also. Thank you.
[APPLAUSE]