Topics In Demand
Notification
New

No notification found.

Software Defined Vehicle demands R&D overhauling
Software Defined Vehicle demands R&D overhauling

462

0

  • Like mobile phone evolution automobile will change from hardware product to a software defined vehicle System/function based architecture to transform into E/E central architecture
  • As part of continuous improvement through OTA updates continuous co-ordination between OEM and supplier R&D team is required
  • Suppliers will have to sell software and hardware as separate and in combo based on the OEMs software outsourcing strategy
  • Customer centric optional (subscription based) and mandatory updates needs data driven decision making

Just like how cell phone has changed, cars are also going through a revolution, modern cars are being sold as hardware with a software package. Pushed by CASE (Connectivity, Automation, Shared and Electric) revolution along with development of 5G and Artificial Intelligence (AI). Traditionally cars were sold as a hardware unit and gets minor feature changes through service centres, which is now being changed to software defined vehicle with Over-the-Air (OTA) updates.

Software Defined Vehicle

Moving away from conventional cars to software defined vehicle is an evolutionary process. This is four staged evolution of a vehicle as 1. Functional Vehicle, 2. Digital Vehicle, 3. Updateable-Vehicle and 4. Software Defined Vehicle. Each stage transition needs both hardware and software architecture changes which in effect demands an overhaul in conventional automotive research and development (R&D). That means shifting from the traditional scattered, embedded Electronic Control Units (ECU) to a domain focused system with central vehicle controllers. This requires sophisticated software including a software abstraction layer, Ethernet usage and large scale connectivity.

Traditional vehicle development period use to be 5-6 years, software defined vehicle demands R&D cycle of 3-4 years range. Main changes in R&D for the software defined vehicles are; change to agile systems engineering from component based waterfall development, change from embedded development for ECUs to centralised electrical-electronics (E/E) architecture and software, change from material cost optimisation at start of production to cost and revenue optimisation throughout the lifecycle, from product and technology focus to customer focus and change from experience based engineering to data enabled engineering and virtual engineering.
 

Software Defined Vehicle

 

Conventionally OEMs use to get components/systems from suppliers and integrate, this will get sophisticated for software defined vehicle. OEMs and customers and looking for flexibility and agility, which in effect will make suppliers to sell hardware and software separately, so that OEMs and customers can pick and choose. As there will be OTA updates for both mandatory and subscription based systems and features, OEMs needs continuous co-ordination with supplier. The R&D team co-ordination that happens throughout continuous product updates makes this little difficult manage with conventional automotive organizational thinking and structure.

Conventional product focused R&D and product development processes discussions typically remain in their area of focus and have a few structured interactions with other functions such as marketing and sales. In case of software defined vehicle, OEM’s customer experience team needs continuous co-ordination with R&D team and some information has to be shared with software supplier R&D team. Customer experience should not be just from traditional surveys through service centers and third party but from data generated from vehicle and service centers.

Bringing automotive R&D organization fits to software defined vehicle is a sophisticated but necessary evolution for OEMs and suppliers, if they want to remain competitive to face CASE revolution and disruptive player entries.

 


About the Author

Arun K T, Deputy Manager, Strategy and M&A, HindujaTech


That the contents of third-party articles/blogs published here on the website, and the interpretation of all information in the article/blogs such as data, maps, numbers, opinions etc. displayed in the article/blogs and views or the opinions expressed within the content are solely of the author's; and do not reflect the opinions and beliefs of NASSCOM or its affiliates in any manner. NASSCOM does not take any liability w.r.t. content in any manner and will not be liable in any manner whatsoever for any kind of liability arising out of any act, error or omission. The contents of third-party article/blogs published, are provided solely as convenience; and the presence of these articles/blogs should not, under any circumstances, be considered as an endorsement of the contents by NASSCOM in any manner; and if you chose to access these articles/blogs , you do so at your own risk.


Automotive Product Engineering Services & Digital Technology Services

© Copyright nasscom. All Rights Reserved.