 Stefan Poledna at"The Autonomous" (image ©Romar Ferry) |
Stefan Poledna speaks about building future-ready driving systems, in this edition of Expert Talks. He points out what key criteria OEMs need, to ensure that they have a future-proof strategy in place and what they need to consider for the changing landscape in the software-defined era. He also gives concrete suggestions how OEMs can already prepare in the early phases of their projects to evolve all the way to full automation and public acceptance. |
What are the key criteria for OEMs to ensure that they have a future-proof strategy for building automated driving systems? What do they need to consider?
We see a very strong market trend to level 2+ driving systems. That is a very high level of automation in many driving scenarios, while still holding the driver responsible. These features are not only in high demand by the market but can also serve as a springboard – if designed thoughtfully – for the higher levels 3 and 4. The upcoming NCAP (European New Car Assessment Program) regulations will fuel this trend towards level 2+ systems even further, because they will mandate the implementation of certain level 2+ applications to achieve a high star rating. The key challenges that need to be managed are complexity, re-usage and re-deployment as well as safety and scalability. Complexity is skyrocketing with the rapid growth of software functions enabled by the advent of silicon technology, especially in the field of deep neural networks. As most of the functions are safety-related, software validation becomes the key cost driver. Therefore, it is necessary to re-use, constantly improve, and re-deploy the software functions. This can only be achieved by hardware abstraction to enable hardware-independent software development as much as possible. Such a decoupling of hardware and software is necessary to re-use and evolve the software functions independently from the hardware, including all efforts that have been spent for validation. In particular, the ECU upgrade path can take full advantage of the newest high-performance SoCs (System on a Chip). Besides decoupling software from hardware, software functions must also be separated from each other by well-managed interfaces. Separating software functions and managing their interfaces has been proven by other industries to be “the” efficient way to deal with complexity. We can see this from safety-critical aviation software to ultra-complex cloud software. Our real-time safety platform MotionWise addresses both aspects, decoupling hardware from software and software function separation.
In this upcoming software-defined era, how are the RFIs for the highly automated driving projects changing and are the OEMs fully aware of how this change translates to their environments?
Many OEMs are making a radical change from sourcing ECUs with sensors and actuators as a black box from a single Tier 1, to sourcing the software functions and hardware functions separately. The OEMs even consider some software functions as core know-how and they even develop these software functions themselves. This gives OEMs much more freedom and flexibility. However, this requires the build-up of more software competencies and introduces a new software integration role. This also demands a powerful middleware platform to enable efficient integration of software coming from multiple sources. Exactly these integration requirements with hard real-time and safety constraints were the key drivers in our MotionWise development.
What are the principles OEMs need to consider in the early phase of the project, to build a sound, future-ready automated driving system, that would be capable to evolve all the way to full automation?
Efficiency in the development cycle is key. This cycle can be broken down into 3 phases: First function development, second function integration and third function verification and validation. In modern software development, different software functions need to cycle through these three phases in parallel, in an agile and iterative setup. This requires that the function development can be done in parallel on a PC or Laptop side-by-side with the embedded platform to speed up development progress. To do so, we need a middleware platform that bridges from the embedded platform to the PC and therefore enables the developer to run the same code on the PC and embedded target seamlessly with fully synchronized real-time behavior. Even more important is the possibility to take the integrated software function and perform a continuous re-simulation with a rich and comprehensive scenario database. Again, the middleware platform needs to provide a rich SDK (Software Development Kit) that enables correct timing and sequencing in re-simulation, even if performed in hyper real-time. With MotionWise, we have taken care to address both aspects in a seamless and easy to use approach to enable parallel development and to speed up the development cycle.
How do we achieve highest safety levels of the complete automated driving system, in order to get public acceptance?
Here we need to differentiate between Level 1 to 2+ and Level 3 to 5 systems. Up to Level 2+, the system can rely on the driver as an ultimate authority to correct wrongful decisions. The driver also serves as a backup in case of failure. The lines get blurred here when drivers are becoming overconfident in the system’s capabilities and thus, no longer perform their supervision tasks with the necessary attention. Notably, we humans are not good at supervising automated systems that only occasionally require interaction. Starting with Level 3 systems, we are in a very different field. There is no supervision by a human, thus, computer decisions are final – and potentially harmful. Moreover, the system needs to be designed fail-operational. That means, even in the case of a failure, the system needs to be at least partially operational instead of entering an unsafe state. Based on well-founded experience in many fields, for example, aerospace fly-by-wire systems, we know that complex software, as well as hardware systems, can operate much more safely than humans can. In aerospace, the likelihood of a fatality is 10-9, in other words, we expect a fatality on average every one billion flight hours. Recent statistics indicate even a ten times lower value of approximately 10-10. If we take the Motor vehicle fatalities in the U.S. in 2017 as a comparison for human driving safety, we observe a 3,500 times higher likelihood of fatality. That is 3.5x10-7 or 0.35 expected fatalities every million hours traveled. Interestingly, most of us accept the risk of flying with a plane and driving a car. In our opinion, getting public acceptance can only be achieved by building computer systems that are better than human drivers with an increase in safety that is so significant, that it can be easily underpinned with strong evidence and facts. Let us turn to the question of how to get there: We know from our experience and from other industries, that no single component, being software or hardware, has a failure rate that is low enough to make life-critical decisions. Hence, we need diversity and redundancy in software as well as in hardware components. On the hardware side, implementing redundancy is a highly sophisticated engineering practice that is well understood by expert engineers. On the software side, however, we are entering new territory. For example, street traffic is a wide-open system that cannot be described by a model, at least not, when there is the need to model all the extremely rare corner cases, unusual situations, weather conditions, and erratic behavior of other participants that may possibly lead to a fatality. This is a game-changing level of complexity. To manage this complexity, we see the most promising approach in breaking down the problem into components that address different aspects in a very specialized form. For example, an ongoing architecture project at TTTech Auto breaks the overall problem into four components. Firstly, a component that generates the driving trajectory that is optimized according to the passenger’s needs. Secondly, a component we call Safety Co-Pilot. This component constantly calculates the free space where the car can move safely. Note that this component does not calculate any trajectory as we have optimized this component for safety and have not considered any comfort or optimization aspects. Thirdly, a component makes the decision whether the driving trajectory of the first component is consistent with the calculation of the Safety Co-Pilot. In case of failure, the trajectory of a fourth component is used. This fourth component is specialized to calculate, under all situations, a minimum risk trajectory. At TTTech Auto, we are working on this architecture and the Safety Co-Pilot in our advanced development department. Combining this architecture with the Safety Co-Pilot and MotionWise is a robust base for highly automated driving functions. We see the safety challenge with all its aspects, for example, architecture, AI, security, and legislation, as an industry-wide challenge that needs to be addressed jointly. We have initiated “The Autonomous” to bring together all relevant stakeholders. Safety is the baseline and not a differentiating feature.
|
About the ContributorDr. Stefan Poledna is member of the executive board at TTTech Auto. As Chief Technology Officer he is responsible for the company’s technology roadmap, all scientific topics and quality management. He has over 30 years of international industry experience in innovative embedded systems development and has authored and co-authored several patents. He received his M.Sc. and Ph.D. degree in computer science with distinction from Vienna University of Technology, where he also lectures on Dependable Computer Systems. |
|
Accelerate your journey towards highly automated driving with MotionWise safety software platform. MotionWise delivers safety by design and fail-operational performance while managing the high complexity of solution elements. As a result, OEMs and Tier 1 suppliers can benefit from faster time-to-market for their automated driving projects and increased competitive edge at reduced costs.
Stay informed about the most recent technological findings in the automotive industry - visit us at www.tttech-auto.com and follow us on LinkedIn for more on this exciting topic.
Related Insights
