In 2022, self-driving cars for consumers are finally hitting the streets in Germany – but the Mercedes “Drive Pilot” comes with many ifs and buts. Is this a big win or a baby step?
Philip Potkowski: Driver assistance systems are making great progress. When your aim is to enhance safety and help the driver in a challenging situation – like being stuck in stop and go on the highway – it is a win. Every step in that direction deserves respect, the same goes for systems like Ford’s BlueCruise, GM’s Super Cruise or the Tesla drive pilot. If we talk about the vision of a fully autonomous driving scenario, that is a different story.
What is the holdup when it comes to autonomous driving?
Modar Horani: Right now, the industry is pushing for more and better sensors. A new car might currently have ten. For a fully autonomous vehicle, you would need a combination of around 30. All of these cameras, radar- and lidar-sensors need to be aligned and coordinated. They have to work under all circumstances, which requires a lot of testing.
What kind of scenarios are you dealing with in sensor testing?
Modar Horani: You can for example test a lidar sensor in different situations: how does it behave in snow or rain, when there is little light in the morning or direct sunlight in the evening, when there is some frost on the vehicle. All the little things we rarely think about now become crucial because we want our cars to deal with each of these on their own.
Philip Potkowski: We had to develop our own platform called Adapt vehicle to effectively deal with this complexity. It enables us to test how different combinations of sensors manufactured by different suppliers work together.
“You cannot beat the challenges of autonomous driving in the car alone”
So, is it all about sensors right now?
Modar Horani: Sensors are important, but so are the hardware and software that interpret their input. But you cannot beat all the challenges of autonomous driving in the car alone. You will need vehicle-to-vehicle communication to extend the perception of your own car. You need intelligent infrastructure to reach a mature level. You need to improve digital maps and GPS coverage. All of this cannot be done by one OEM alone, and we are working hard on pushing industry-wide and cross-industry solutions here.
Philip Potkowski: People used to look at a car as an isolated unit. With autonomous driving, we are dealing with so many parameters in the environment that need consideration. There are other cars, pedestrians, the urban infrastructure, and many unpredictable situations. This adds a whole new level of complexity to systems engineering as well as testing and validation – and we need more comprehensive solutions to deal with this.
Dealing with complexity seems to be key on the road to autonomous driving.
Modar Horani: That is definitely the case. There are many elements with behaviour you cannot model. To give an example: How can we make sure it is safe for an autonomous vehicle to hand over to the driver? In classical systems engineering you would set up a document, maybe start by categorizing the states of the driver – awake, eyes on the road, sleeping – and mechanism to alert the driver. You would probably do some drawings, talk to a supplier. At the end of six or seven months you have a Word file and hopefully you thought of everything, but what if you didn’t? That is why we propose an improved method called Model-Based Systems Engineering, “MBSE” in brief.
“Test results give me more confidence in the safety of a system than a stack of documents”
What changes with MBSE?
Modar Horani: It provides a more holistic way of looking at things based on use-cases. And it sets out to provide a direct route from use-case to code, all in one framework, which means we create a model that we can test very early in the process. This allows us to apply a Scrum framework to iterate based on the test results. It also enables us to test different configurations early on, for example, for model lines or models for different markets. After six or seven months, instead of a Word document you will likely see a driver sitting in a mock-up cockpit.
I understand that for OEMs speed is of the essence, right? Still, you are working with a platform that weighs thousands of pounds. How is it possible to ensure safety in systems as complex as this?
Philip Potkowski: It is important to say that MBSE does not necessarily introduce a new launch speed. It changes the speed where you can test something. These test results, in turn, give me much more confidence in the safety of a system than a stack of documents someone thought up. It goes without saying that the globally implemented safety standards also apply to our process, such as ISO26262, which aims at functional safety.
Modar Horani: We go even further, because in a complex environment, functional safety is not sufficient. Sensors may be operating fine, ECUs in the limits of their performance, but then there can still be a situation where two cars are making different decisions in similar scenarios. That is why we add another layer of safety standards called safety of intended functionality, which aims at dealing with real-world scenarios. Because the problem is not with the issues which are known and unsafe, it is about the issues which are unknown and unsafe.
In the end, how do you ensure my car always makes the right decision?
Philip Potkowski: A lot of simulation, a lot of testing, and a lot of field data are the best ways to make complex systems safe. For autonomous systems, I think the game changer is going to be simulations with model and software in the loop. Basically, a way to effectively test your systems in many scenarios without a physical prototype. You can also leverage hardware in the loop in combined physical and virtual testing. In the end, you also have to do the physical field-testing, which is time consuming and labour intensive, but it is necessary to keep our drivers and our streets safe.
