digital.auto : Developing a ‘Digital-First’ Thinking and Working Methodology for SDV
                                        
AEM interviewed with Professor Dirk Slama, Chair of the digital.auto initiative and Vice President at Bosch, who moderated the panel discussion titled 'Towards the Habitat on Wheels' on software defined vehicle at IAA Mobility. He expressed his viewpoint, saying, "I don't believe there is a shortage of technology and standards for SDV at the moment, but I do see a slight lack of methodology that effectively leverages these technologies to create innovative use cases. That's why we have established a very open ecosystem within digital.auto with a specific focus on use cases."

Written by Han

 한글로 읽기 

Dirk Slama is a Vice President at Robert Bosch GmbH. As chairman of the digital.auto initiative, he helps driving the digitalization of the automotive industry. As conference chair of the Bosch ConnectedWorld, Dirk helps shaping the digital ecosystem of the Bosch group. He is director of the AIoT Lab at the Ferdinand-Steinbeis-Institute, where he also holds a full professorship. The AIoT Lab helps customers implement use cases in the digital.auto and digital.industry domains. As Editor-in-Chief of the Digital Playbook for OEMs and manufacturers, he helps making best practices available to support the digital transformation. As former chairman (StC) of the Industrial Internet Consortium (IIC), he helped to create the leading ecosystem for the Industrial Internet. Dirk has 25 years’ experience in very large-scale IT projects, distributed systems and AIoT. His international work experience includes projects for Audi, Daimler, Lufthansa Systems, Boeing, AT&T, NTT DoCoMo, IF.com and others. Dirk is a frequent speaker at conferences, as well as co-author of five successful books: Enterprise BPM, Enterprise SOA, Enterprise CORBA, Enterprise IoT, and the Digital Playbook. He holds an MBA from IMD Lausanne as well as a PhD in Information Systems and a Diploma (MSc equivalent) in Computer Science from TU Berlin.





Q. You are a vice president of Bosch and chairman of the SDV initiative 'digital.auto'. What career in automotive and IT made you take on this important responsibility?

A. I have spent 25 years working with and for start-ups, helping large international companies to optimize end-2-end business processes supported by highly heterogenous IT infrastructures and legacy systems. So, I have learned a lot about migrating complex IT systems to next-generation architectures, and dealing with organizations with teams and technologies which are moving at different speed. As one of the co-authors of the “Enterprise SOA” book (SOA=Service-oriented Architectures) I was in the lucky position to work with many experts in this field and extract and document best practices which are still valid today. I think many of the lessons learned from industries like financial services or telecommunications can be applied to automotive: how do you innovate at rapid speed, while still “running the bank” in a safe and reliable manner. I joined Bosch 10 years ago when I was in the management team of a company which was acquired by Bosch. Since then, I have learned a lot about industrial IT and automotive. The Software-defined vehicle has a lot of similarities to legacy migration projects found in banks or insurances - except that we are not building application layers for internet applications on top of hard to maintain mainframe systems, but rather build the next generation of constantly evolving vehicle experiences on top of - more or less- static E/E architectures.



Q. Was digital.auto's catchphrase "Habitat on Wheels" from the beginning? How does this differ from the commonly called Smartphone on Wheels? 

A. On the one hand, the “Smartphone on Wheels” analogy is a good one: we can easily understand that customers want the same experience they have with their smartphones also with their cars: rich and easy to use applications, constantly updated and delivered on-demand via an app store.
However, the car is also very different from a smartphone: First, smartphones do not have most of the functional safety and real-time concerns that you find in cars. Second, the car is so much more than a phone: it is more and more becoming a living room, office, or nursery on wheels, with many cool new features enabled by SDV which are making the journey of the passengers much more pleasant. 



Q. What is needed to digitize the automotive industry now? Please briefly explain the digital.auto initiative for SDV overcoming these differences. In particular, what is the goal? Is the priority goal "speed," as the saying goes "time machine for SDV"?

A. There is no lack of enabling technology out there. However, we are lacking well understood and highly effective way to utilize these enabling technologies to delivery customer value in terms of this new vehicle experience that we are talking about (“Living room on wheels”). So how can we help OEMs and suppliers to more effectively use these new technologies? How can we implement a customer-driven, digital first approach to delivering new features?
And how can we establish a build/measure/learn process which has become the standard for Internet-type of businesses that also works for automotive.
How can we help OEMs “move at different speeds”, enabling architectures (and teams’ structures) where slower moving parts (related to hardware development or software with high functional safety or real-time requirements) can seamlessly work together with fast moving parts (related to digital solutions which are less functionally critical but highly important for the vehicle experience)? This is what digital.auto is aiming to support through a digital first methodology and supporting open source tools.








Q. I understand that digital.auto is primarily focusing on advanced methodologies and tool development, simulation, and large-scale deployment to support quick virtual exploration of SDV experiences and use cases. How does this methodology and workflow differ from previous automotive software development and verification methods?

A. We are aiming to really establish two separate workstreams: the digital worksteam for functions which are not safety relevant but important for the vehicle experience and can be constantly updated based on live customer feedback and a deep understanding of how customers are reacting to the software. All managed in a highly agile and reactive way, utilizing Internet best practices and technologies, even on the vehicle. And then on the other hand the physical value stream, with the deeply embedded functions which needs to be supporting completely different design, implementation and homologation rules. And these workstreams can only be aligned via an architecture which supports hardware abstraction layers and vehicle APIs as the glue not only between the architectural layers, but also between the digital and the physical workstream.



Q. Many OEMs have already started their own SDV initiatives and are emerging in several types. What does digital.auto mean for OEMs in this situation and what rosy future can it offer? Isn’t digital.auto too late?

A. Yes, many OEMs are well on the way, but they are also still learning and looking for ways to improve the ways they are working in this new world of Software-defined Vehicles. I think we can not make too many assumptions about standards, at least not in the “as is” situation. However, we can work on methods and tools which fit in with existing SDV landscapes.









Q. Standards and open sources such as AUTOSAR, COVESA, and Eclipse SdV are known as key implementations of digital.auto. Does any other standard and open source work within digital.auto?

A. We are currently taking a closer look at the work done by SOAFEE. Virtualized development will become another key ingredient to the #digitalfirst way of working for OEMs and suppliers.



Q. What does it mean to deliver VSM to create end-to-end transparency in software delivery, from code to business outcomes? How do we know the business results?

A. Only if we manage to translate ideas and requirements to customer journeys, and then build in the necessary customer journey analysis tools. 
Today, every web store provides admin tools to understand how online customers are making (or not making) purchasing decision along their customer journey. We need the same level of customer-centric usage transparency in SDV.



Q. What does AI mean in digital.auto?

A. Super important on many levels. This is starting with Gen AI for the development process. We will soon see a huge raise in developer productivity, from the lower levels like AUTOSAR and embedded development, to tools like the digital.auto playground harnessing Gen AI to create entire vehicle applications via Gen AI. And then of course there is on-board and off-board AI supporting the new application in the vehicle which will create the exiting “living room on wheels” experience.



Q. digital.auto emphasizes that for SDV to reach its full potential, it needs to build a vibrant ecosystem of OEMs, startups, developers and innovators. What is the performance of this part a year after the launch of digital.auto?

A. We are very happy with this. We have a very active ecosystem of sometimes complementary but sometimes also competing companies along the entire value chain, from prototyping and simulation to production support and field tests. Interoperability is key, and our interop.digital.auto interoperability matrix is constantly growing.









Q. Are there German OEMs in the use cases? I think I saw the name of Hyundai Mobis in the use case. Are Korean companies also deeply involved in this initiative? How interesting use cases have you tested? 

A. Link to Hyundai Case Study: https://www.linkedin.com/feed/update/urn:li:activity:7117908704204570625
Mercedes is also doing some very interesting work in the area of SDV and variant management. See, for example, 
https://digitalauto.netlify.app/model/BQf8mJ2Krtut7AZNTMQR/library/prototype/6U5vQ2GgKnHMlxWJ9uMB/view/run
The Mercedes vision of combining SDV with their TPLE (type-based product line engineering, the next step in the evolution of product line engineering) is quite cool. The real challenge for large OEMs is dealing with variants, due to different customer vehicle configurations, regulatory requirements, and regional differences. Being able to address this issue on the software level via SDV is revolutionary.



Q. ‘What will SdV 101 course (learn.digital.auto) certification mean for the automotive industry? Can it be a standard like AUTOSAR or ISO 26262?

A. Maybe a good analogy would be Automotive SPICE. We need to bridge the established, SPICE-like automotive world with the agile, Internet-style world. Code-centric and SCRUM teams must be able to work together with V-Model and MBSE-focused teams. If we can help bringing these worlds a bit closer together, this would be great.



Q. Lastly, tell me your near future goals and plans for digital.auto.

A. We are constantly working on making our digital first methodology as easily accessible as possible, via publications and trainings. We are building out our open-source tool - both software and hardware - to support our digital first methodology. We think virtualization - from virtual development to virtual testing - will play an ever-increasing role. And finally, we also have started to build up our own, open test fleet - with the goal to make it as easy as possible to innovated in the automotive industry, even for people not working directly for OEMs.


 

AEM_Automotive Electronics Magazine