Autonomous Driving: A New Challenge for Connected Working

The goal of being able to drive highly autonomously is leading to profound changes in the automotive industry. This not only applies to automotive engineering in terms of software and hardware but also to project management during the development process. In the automotion interview, Timm Kellermann, Managing Director of Consulting4Drive, the IAV Group’s consultancy subsidiary, and Dr. Michael Gröschel, Project Manager and Business Mediator at IAV, report on their project experience and reveal potential for optimizing the development process.

Project management in development – is that still really a challenge in 2019?

Timm Kellermann: In answering this question, we in the automotive industry are becoming a little humbler than we may perhaps have been five years ago. What can be said is that all manufacturers we work with come with a very high level of maturity in terms of planning, managing and implementing vehicle development projects in the field of driver assistance. This goes both for the hardware as well as for the automotive software. But in developing highly automated driving systems, we are currently seeing virtually every project in a crisis. The reason for this has not been seen to be lacking rigor or discipline in project management. What is emerging is the fact that automated driving development projects at level 3 or higher are producing their own new category of project management problems. A project of this nature sometimes involves as many as seven companies with more than 700 individuals at over 20 locations and in three time zones. These individuals come from over 30 countries. This fragmentation is the result of extensive new competences and the many partners and domains which are needed for this type of development. But this alone does not explain the challenges occurring in the projects.

Where are the other causes?

Dr. Michael Gröschel: Across the industry, the development of assistance systems is entering a new phase. To date, individual products, such as a lane-keeping assistant or an ACC system, are developed as standalone functions on a bilateral basis between manufacturer and component supplier. From level 3, the project task will lie in developing a complete system instead of an individual function. The level of maturity of the required systems and technologies is still not sufficiently high, resulting in strong interdependencies between sensor, technical architecture and software development. In the course of integration, the high degree of connectivity in the vehicle frequently leads to dependencies which, at a very late stage in the development process, involve extensive hardware and software modifications in the sub-systems in order to meet all of the customers’ demands on the overall system. You can imagine that in situations like these the complexity of the relevant development and validation process grows immensely. At the same time, time pressure increases which means that ever more complex tasks must be completed in ever shorter time within increasingly distributed project teams.

Kellermann: We are well familiar with the symptom chain. At the beginning of the project, requirements cannot be properly described in sufficient detail which leads to significant problems in development, testing and validation right through to troubleshooting in the field. Here too, these deficiencies, however, are not usually attributable to any lack of discipline but a lack of understanding and knowledge. With ADAS level 3 and higher, we are – to be honest – unexpectedly treading more new terrain than familiar territory. Today, developing highly automated driving systems is primarily still a search for new effectiveness. This is also the reason why agile-iterative and MVP-based approaches (Minimum Viable Product) are so highly rated: they are methods from the world of effectiveness. Our main methods from the present automotive efficiency world are the sequential product development process (PDP) and the vehicle or feature business case. Consequently, current AD projects are reaching a fundamental complexity limit and can no longer be completed with the customary level of success using the familiar project tools and process models.

Dr. Gröschel: In handling projects, we are encountering further challenges, in particular through different communication, implementation and working cultures characterized by regional factors and segment-specific perspectives. We experience regional differences, for example, in implementing projects at team level. For the component suppliers in Asia, achieving the common goal in a partnership based on a deep relationship of trust has utmost priority for the component supplier whereas in Europe we are primarily oriented towards requirements predefined within a set of specifications based on a rigid contractual relationship.

There are industry-specific discrepancies in implementing cloud-based functions between the automotive and the IT world which is marked by a much faster pace of development. The latter involves a higher level of error tolerance in the development process which is evened out in the smartphone segment by the capability of carrying out a software update during later use, for example. The domain of highly automated driving, in contrast, involves safety-critical and, at the same time, highly innovative products that demand a close link between hardware and software development for control units and sensor system. Often, we witness project partners using the same or very similar terms and concepts but understand them to mean completely different things. This is bound to generate tension in the project team and cause problems in realizing a project.

Why are these problems now emerging so clearly?

Kellermann: As we have been successfully developing driver assistance systems for many years, the move from level 2 to level 3 seems to be a small, systematic step. I’ve come to believe, however, that the opposite is true. It is at this point that a fundamental boundary is crossed in our automotive business model. Up to level 2, the driver alone is responsible for safely operating the vehicle. From level 3, the manufacturer starts to take some of the responsibility for the vehicle’s safe operation. Defacto, this means that even today it is necessary to address many challenges of higher levels of fully automated driving. In terms of developing and validating driver assistance functions, recent years have seen much responsibility being taken from the manufacturers and passed on to the component suppliers. However, due to the high degree of connectivity of automated vehicles this trend in particular must be reversed because these (interconnected) systems can rarely be provided entirely by one component supplier.

Dr. Gröschel: Alongside this, current projects in progress at manufacturers are demanding far greater input in terms of system development, integration and validation, and much broader demands are being placed on communication and information management among the project teams.

In addition, software is becoming increasingly important in development work. Whereas there was a 60-to-40 percent split between software and hardware in level-2 projects, software now accounts for 80 percent of level- 3 functions – with this figure rising. In hardware development, time is needed to realize robust solutions, making it necessary to define architecture and performance early on in the process. However, during this time, the world continues to turn, and often it only becomes apparent during the course of the project that the hardware no longer meets the latest demands. In contrast, software development is much more dynamic. Changes – also of a substantial nature – are the order of the day and implemented at short notice. When developing systems for highly automated driving functions, the high level of innovation and the above-mentioned close link between hardware and software mean that two cultures of thinking come together under high project pressure, both of which have their justification.

And the impacts on development projects?

Dr. Gröschel: As project partner, you generally notice very quickly when things in the team are not going as well as they should. Among other things, this becomes evident in project delays and in late milestone reporting as well as through the late identification of functional deficits necessitating complicated and costly hardware changes.

Kellermann: In managing projects, we are experiencing a sharp increase in the need for steering and transparency in order to coordinate the many team members and keep them up to date. Otherwise, the project runs the risk of getting out of hand.

Which countermeasures are you taking?

Dr. Gröschel: In the current project, we noticed that the problems occurring could not be resolved merely by increasing capacity on the engineering side. Through intensive discussions with the customer it became increasingly clear that, besides the technology, it was also necessary to adjust the project partners’ cooperation model. Together with Consulting4Drive, we then initially analyzed the overall situation far beyond the normal scope and identified the challenges described at the beginning.

Kellermann: In an effort to achieve lasting improvement in the project, we have created a new modular solutions toolbox. It is divided up into management consulting, technical consulting, operational engineering and extended project management at the points of contact between the project partners. In management consulting, it is about preparing the project partners in advance for the project’s complexity and making them realize that different perspectives and approaches are a deliberate asset and not counterproductive for the project. Attempts to lay down requirements at the beginning of the project don’t lead to the desired outcome either.

In technical consulting, we use IAV’s expertise to answer the question as to which system or technology architecture is best suited for the task in hand. Operational engineering covers systematic requirements management, testing and validation of the hardware and software systems developed in the project with IAV’s own simulation environments and test facilities. An important cornerstone of our project management at the interface with component suppliers is the so-called “joint operations platform”. Using this tooling, the project partners can, for example, file and exchange all information at a central point, communicate with each other or view deadlines and the status of the overall project and sub-projects. This provides transparency and hence clarity throughout the course of the project. It also forms the basis for constantly monitoring milestone targets and for keeping a tight control on the course of the project.

Dr. Gröschel: In order to guarantee internal, overarching day-to-day coordination of the projects derived from the solutions toolbox, a program structure was developed as a framework around the broad activities. This program structure divides the various aspects of the overall undertaking into individual projects with separate responsibilities. Program management is only responsible as the overriding authority for project interaction, not for the success of individual projects. The distributed responsibility resulting from this structure very well reflects the characteristic of the systems being developed, making it a central key to success. It was crucial – particularly in the international context – to understand and respond to the cultural specifics of the project partners, such as building a strong relationship of trust in Asia. Building a deep customer relationship at management level as part of consulting by Consulting4Drive also enabled our project team at IAV – on the engineering side – to reach a new level in project handling with the customer.

Is this problem mostly limited to automated driving projects?

Kellermann: We don’t believe this to be the case. The main characteristic of the projects addressed consists of a high level of technology and innovation, which is why the challenges first emerged in the field of highly automated driving. However, the problems are of a fundamental nature and are caused by the way in which digitalization is transforming the automotive world. For me, this is only the precursor of the ultimate level of complexity which will result from the new “smart mobility” concepts. This is where digital domain, automotive domain and infrastructure provider, with their widely differing paces of development and innovation, must then be brought together and synchronized.

Dr. Gröschel: Wherever different fields of technology and various international sites work together, the described new approaches will be needed to develop solutions in a structured way. In cooperation with Consulting4Drive, we have developed a process model for connected working, transferring information among the developer teams as well as new forms of collaboration based on an understanding of the diversity of the partners involved, thereby offering a key component to ensure the success of mobility projects.

Kellermann: Finally, a concluding thought: in the world of digital IT there’s a competitive edge which we in the automotive industry are currently focusing much attention on: high speed of learning. We believe that for developing automated driving systems, this factor will also have a major influence on their market success and hence on profitability.

Gentlemen, thank you for talking to us.