Follow our official account, click the “…” in the upper right corner of the homepage, set it as a star, and stay updated on the latest news in smart automotive electronics and software.
Source: Automotive Electronics and Software
As software-defined vehicles (SDVs) continue to gain traction, various OEMs are establishing their own R&D innovation centers, focusing on software, artificial intelligence, and other innovative developments. A recent example is SAIC Group’s establishment of the SAIC Innovation Development Institute. The establishment of independent R&D centers provides ample support in terms of organizational authorization and funding. However, does this mean everything is perfect? I believe the answer is definitely “No“
In previous articles, we described what SDV is, clarified its historical origins, and addressed some misconceptions about SDVs, introducing the concept of software-driven vehicles.
Today, we will focus on the pain points currently faced by the automotive industry and how to further resolve them to allow software to truly unleash its vast potential.
Through interviews with different automotive software developers and lessons learned in software development management, @Aisuo Consulting believes that aside from the independence of organizational structures, the transformation of automotive software currently faces several major pain points that urgently need to be addressed:
1. Conflicts at the Cultural and Ideological Level
2. Transformation of Personnel Skills
3. Upgrading Internal Processes and Systems
4. Changes in Cost Management
1.Conflicts at the Cultural and Ideological Level
Over a century of automotive industrial history has shaped automobiles into highly modular integrations. Engineers in automotive structure and mechanical engineering have exhausted their efforts to ensure that different components within the vehicle are decoupled to the maximum extent, maintaining their independence. However, “success and failure are both due to the same factor”; while high modularity has laid a solid foundation for parallel engineering and outsourcing, it has also led OEMs to focus more on product definition, styling design, product assembly integration, and brand promotion. A large amount of engineering, development, and manufacturing work has been handed over to suppliers.
However, when a large number of components and software products come from internal development teams, traditional ways of working will face many new challenges:
-
Transition from “Client-Provider Mindset” to Ecosystem Management Mindset
How will the “Client-Provider Mindset” formed through years of supplier management adapt to new situations? As the importance and weight of software in the entire vehicle increases, traditional customer-supplier relationships will evolve into ecosystem partnerships (such as various ecosystem companies in vehicle networking), software platform suppliers (such as autonomous driving platform providers), and so on. These transitions will bring significant impacts to the traditional supply chain system, requiring a shift in mindset. The automotive chip crisis that occurred in 2021 is still ongoing, serving as a litmus test for the traditional supplier management system. Furthermore, with the establishment of internal R&D by OEMs and the initiation of independent research, traditional methods of managing suppliers will be difficult to apply to internal team management. The “Client-Provider” management mindset will exacerbate internal conflicts. Two different management styles and philosophies are needed for external and internal teams, which will require time to adjust and digest.
Figure 1 shows the ecological scenario of future smart vehicles. Looking towards the future of smart driving, more Internet content providers (ISPs) will become important ecological partners for automotive companies, as they face both end-users (on mobile or PC) and vehicle manufacturers (car-side), thus they are neither traditional suppliers nor completely loose “bystanders”. Managing these ecological partners requires new innovative thinking and methods.
-
Transition from “Component Management” to System and Function-Oriented Solution Thinking
Compared to hardware, software is intangible and abstract. In traditional component development, software is embedded within hardware entities and is invisible, while OEMs focus more on how components fit together with the entire vehicle. The development of various components is independent, and the coordination of interfaces between them is achieved more through the vehicle’s physical communication network based on control signals.
In contrast, system and software development starts from the functional scenarios based on customer needs. Figure 2 illustrates a typical V2X application scenario, where each ECU component must coordinate with others to form an organic whole through a service-oriented architecture (SOA). Therefore, customer scenarios and market needs require cross-scenario solutions and the involvement of more ecological partners. From basic network infrastructure providers, city brain solution providers, basic public implementation providers to cloud platform service providers, and ecological content providers, all challenge the automotive companies’ ability to design and integrate solutions.
Figure 2 Image source: Information Communication Network
-
Transition from “Hardware Development Management” to “Software Development Management” Thinking
-
Component management is achieved through strict quality gate management, and the components delivered by suppliers (software + hardware) will be assembled into the entire vehicle, with their production processes, versions, and releases strictly planned and controlled. However, software products can achieve “flexible production”. They can be “produced” daily or even hourly, released and updated anytime and anywhere. The diversity of versions and functions, the dependencies on hardware, etc., bring different skill and thinking challenges compared to component development management (Figure 3).
-
In the hardware product development process, many dependencies are unresolvable; for example, if a chip is unavailable, engineers cannot complete the circuit board soldering. However, for “flexible” software, many dependencies can find different workarounds, not necessarily being “Hard Dependencies”. This requires agility from management (Agility) as well as the accumulation of experience and sincere cooperation among teams.
-
Transition from “Hardware Product Management” to “Software Product Management” Thinking
The “rigidity” of hardware products and the “flexibility” of software products determine that they have different product strategies. The future trend suggests that with the participation of major technology players, hardware will gradually become standardized and generalized; while the flexibility of software will manifest its diversity based on different OEMs, customers, and market demands, becoming a strategic battleground for future competition. However, this flexibility will also bring about shock and transformation in various functional systems of OEMs, such as production and manufacturing systems, financial systems, procurement systems, quality management systems, technical centers, and even human resources departments. Here, I will briefly describe two points.
-
From the perspective of product reliability, hardware products typically exhibit a “bathtub curve” (see Figure 4), while software products exhibit different reliability curves. With the independent release and evolution of software products, the quality management of software and hardware products will show different directions and methods.
-
Hardware products’ lifecycles and software products exhibit different forms – once hardware products are assembled, they will accompany the vehicle for 10-15 years without change. If problems arise, the only solution is a “recall”, whether physical or returning to the dealership for repairs. However, software products can be “released” and “updated”. Modern ICT technologies support remote OTA updates. Throughout the vehicle’s lifecycle, multiple rounds of new features will be iterated (Figure 5).
The decoupling of hardware and software forms independent product roadmaps (Roadmap); while independent evolution leads to different product lifecycles, evolving into different ideas: standardization and generalization of hardware products; diversification of software products. This will inevitably create new problems, such as software-hardware compatibility issues and backward compatibility, all of which pose challenges to traditional component product management thinking. This also impacts the production and manufacturing systems of OEMs – should the software functionalities be comprehensive or just “minimal reliable” software? How should the OEM’s financial system better define and utilize software capital?
-
Transition in Cost Management Thinking from “Hardware Costs” to Total Lifecycle Cost Thinking
Traditionally, OEMs focus more on the costs of components (Per Unit Cost), while software development costs are often allocated to the components.
When facing software products provided by suppliers, how will the Unit Cost be priced, and how will it transform into a profitable software business model? Similarly, if it’s internally developed software products, how will the development costs be amortized? How will software capital be allocated reasonably? Since software is “flexible”, if not managed properly, the development costs of software can far exceed the savings from hardware costs.
Christian Salzmann from BMW once provided a set of data: for an ECU with an annual demand of 500K, if the hardware cost is reduced by 20 Euros each year, it can save a total of 70 million Euros over a 7-year production cycle. However, if software development is not reused effectively, it could waste an additional 100 million Euros.
Additionally, “saving costs” traditionally focuses on “cutting costs” for hardware. However, as a cautionary tale from the ICT industry, such as Motorola, Nokia, and Apple, the “catfish” in the automotive industry (see Figure 6), Tesla, has opened a window for “increasing revenue” through software sales. By reserving hardware, although the hardware costs rise in the short term, the software’s OTA iterative upgrades create greater sales revenue. This total lifecycle cost evaluation poses new challenges to traditional automotive professionals’ thinking and management systems.
2. Transformation of Talent Skills
Automotive software is relatively complex and distributed. Its application areas span from in-car entertainment software to safety-critical real-time control software. Based on application areas and safety real-time requirements, automotive software can be categorized as follows (see Figure 7 for examples):
-
In-car multimedia and HMI-related software development. This part typically has low real-time requirements and is currently a key area of vehicle networking software.
-
AI software related to smart cockpit features such as voice recognition and gesture recognition. This part usually has low real-time requirements and is more event-driven, with communication between components achieved through service requests and feedback.
-
Software and algorithms related to vehicle chassis, power control, and in-car communication. This part typically has high real-time and safety requirements, necessitating very high reliability. Communication between components is based on control signals.
-
Software related to autonomous driving, such as ADAS and AVP. This part usually has high real-time requirements and requires considerations for safety design; at the same time, it demands higher computing power, necessitating high-performance processors to meet system functionality requirements.
-
Cloud software and mobile communication infrastructure: This part typically does not rely on specific hardware, with varying real-time requirements based on application scenarios. At the same time, the openness of communication networks increasingly demands stringent information security.
Figure 7 Image source: Renesas website
Through the simple software classification above, we can analyze:
-
The department most closely related to automotive software is likely the electrical and electronic architecture department of the OEM. However, looking at the heads of major automakers’ technical centers and research institutes, most come from traditional chassis and engine fields. They need to fill their knowledge gaps in smart cockpits, autonomous driving, cloud and mobile communications, and information security (see Figure 8).
Figure 8 Image source: QNX website
-
Currently, OEMs basically provide specifications for components similar to “Black Box” (SOR or RFQ), with the specific implementation and technical know-how primarily in the hands of suppliers.
As shown in Figure 9, a typical VDC (Vehicle Dynamic Control) subsystem functional specification from an OEM, apart from this black box interface definition, the software and hardware implementations are primarily in the hands of suppliers. Therefore, within the traditional automotive supply chain, the most knowledgeable about software should be the automotive electronic software departments among Tier 1 suppliers. However, transferring intellectual property from suppliers to automotive OEM developers is nearly impossible. Especially in traditional automotive OEM companies, they typically do not pay separately for software development NRE costs (in a sense, it’s “free-riding”).
-
Limited by the overall industry’s development trend, mainstream automotive electronic software development is still largely confined to the microcontroller (MCU) level. In the past five to six years, with the development of vehicle networking and autonomous driving, it has gradually shifted to ARM-based SoC platforms and multi-core chip processors.
Currently, workers in the automotive industry typically use AUTOSAR-based automatic code generation tools, such as Etas, Mentor Graphic, EB Tresos, etc., to configure applications through graphical interfaces and automatically generate code. However, with the emergence of new functions in autonomous driving and smart cockpits, the demand for computing power in vehicles is increasing, and the adoption of layered software architecture, operating systems, and high-performance SoC platforms is becoming the norm. Previous development toolchains are beginning to face challenges, and new toolchains are still immature. This presents new challenges for traditional automotive software professionals. Years of using tools like AUTOSAR CP have reduced most automotive software developers to mere configuration engineers, gradually losing their ability to develop software from 0 to 1; their understanding of underlying chips is also limited. This challenge will touch the soul. The lack of necessary, mature toolchains to support the automatic generation and testing of code will generate a deep sense of anxiety.
Figure 10 is an excerpt from the internet showing a system architecture diagram of HPC. The complex system structure poses significant challenges for traditional ECU professionals. Code operation has shifted from traditional single-core to multi-core, and how to allocate resources dynamically rather than statically presents challenges and skill transformations for traditional automotive electronic software developers.
Figure 10 Image source: Internet
-
Automotive electronic software falls under the category of embedded software development, conducted on dedicated computer systems, generally requiring developers to have a certain hardware foundation. Mainstream embedded platforms include ARM, DSP, FPGA, etc., with development languages primarily being assembly/C/C++.
In contrast, most IT and internet software developers work on general computer systems, generally developing application software on various operating systems such as Windows, Linux, Android, iOS, etc., covering devices like computers, mobile phones, and servers, primarily based on X86 and ARM architectures. Most developers use some high-level languages like C++, JAVA, JS, PYTHON, MySQL, etc., for specific task development.
However, for internet developers from outside the automotive industry, although their numbers are vast (estimated at 1 million professionals), engaging in automotive electronic software development requires understanding the entire vehicle architecture and automotive know-how (see Figure 11).
-
Companies in the ICT industry, smart hardware companies, and chip companies have also cultivated a large number of communication elites (mobile communication, Wifi, Ethernet, etc.) and underlying BSP or firmware development teams, who are the most knowledgeable about electronic hardware among software teams. This group will be the best candidates for automotive electronic software development. However, understanding the entire vehicle architecture and automotive know-how (see Figure 11) also limits these embedded software developers’ ability to quickly adapt.
Figure 11 The complex vehicle architecture requires years of knowledge accumulation and sedimentation Image source: Internet
-
The development of AI intelligence has cultivated a large number of algorithm personnel (image/voice/data). The open spirit of the internet has also fostered a strong information security team. The diversification of application software and mature C/S frameworks, such as Restful and RCP, have also trained a group of excellent front-end and back-end developers. Because they are more independent of specific hardware or tend to engage with cloud and familiar PC and mobile environments, the switching costs are minimal. This talent is essential for implementing cloud software for vehicle networking and big data analysis. Of course, understanding vehicle architecture, automotive industry laws and regulations, and B-end market trends will still require some time for adaptation and experience.
3.Upgrading Management Processes
Over a century of automotive industrial development has formed a distinctive vehicle development process based on quality gates. Through this process, OEMs and their Tier 1 and Tier 2 suppliers are closely linked, forming an organic development whole. However, as functional and scenario-based solutions gradually develop, with software occupying a dominant position, the existing OEM development process cannot adequately adapt to software systems and software engineering, facing significant challenges that require comprehensive system construction. This systematic construction of processes requires architectural and design considerations, covering organizational systems, roles, and responsibilities.
-
Requirements Management Process
The traditional development model involves OEMs being responsible for the functional and interface definitions of systems and subsystems. However, many subsystem divisions are based on physical mechanical components (ECU) and interfaces, and the corresponding responsible engineers have cultivated their expertise over many years with the respective hardware, forming a specialized know-how; however, specialized division of labor creates an “I”-shaped knowledge structure. Technical barriers gradually emerge between different components, even leading to each component acting independently, “old age without interaction”. The problem is, as shown in Figure 12, scenario-based requirement development necessitates the interaction of multiple subsystems; it requires a “T”-shaped knowledge structure. How to decompose requirements, manage requirements, layer management, achieve requirement reuse, and reduce dependencies between functions all pose new challenges to the original processes.
The implementation of automotive OTA functions, how to manage OTA functions and requirements after the vehicle is launched, how to connect operations, 4S after-sales service, and other functional requirements, and how to provide cloud service functions at any time, all require the transformation of the original component-based development processes.
Figure 12 Smart Car Functional Requirements
-
Architecture Design and Interface Definition Process
The traditional automotive industry model has seen software know-how primarily controlled by powerful suppliers, making the specific software implementation and interface definitions invisible to OEMs. Therefore, ensuring that different ECU software integrates organically and coordinates to achieve necessary scenarios requires the establishment of corresponding working mechanisms.
Moreover, the future development direction of the integration of vehicle, management, and end requires a reasonable process mechanism to ensure the interaction of the three. With the gradual realization of SOA architecture and the ethernetization of in-car communication lines, interface definitions will gradually evolve from signal-based definitions or simple message structure definitions in C/S mode to more complex SOA architectures and interface definitions (see Figure 13). When conflicts arise, corresponding technical arbitration processes need to be established for reasonable assessment.
Figure 13 Interface definitions will evolve from simple C/S models to more complex interface definitions
-
Code and Integration Processes
The design of a vehicle’s shape leads to different models and the Fit and Form of components. In traditional component development models, the software code for different Fit components varies. How to effectively reuse code, how to build a software architecture platform, and how to integrate different codes together become new challenges. New processes are needed to ensure the reusability of software code and the integration of hardware and software.
-
Product and Project Management Processes
Traditional component products and projects are often combined into one. Once the hardware is finally approved, the software will be frozen until the end of its lifecycle. However, the software products of smart vehicles can add new features at any time, forming new versions and being updated through remote OTA. It can be imagined that in the future, the same hardware will come pre-installed with different software versions for sale in the market. How to manage the software versions of customer vehicles, how to manage software compatibility, etc., require new process transformations. Project management, as shown in Figure 14, may primarily focus on software development management, organizing software delivery through project models within the hardware product lifecycle.
-
After-sales Service Processes
With the activation of remote diagnostics for software and the implementation of AI and IoT technologies, a data-based after-sales service system will eventually be established. The traditional 4S service model will gradually shift online. As shown in Figure 15, the remote service system scenario will become the norm, and the corresponding process system transformation is also imperative. With the involvement of multiple ecological partners, how to manage end-to-end scenario solutions and provide higher service quality are challenges faced by OEMs.
Figure 15 Complex Smart Car Scenarios
-
Challenges in Development Toolchains
The demands for the development of various autonomous driving, artificial intelligence, software algorithms, and cloud software will drive the emergence of new development toolchains. Alternatively, traditional toolchains will evolve, such as the toolchain based on AUTOSAR CP will further evolve into AUTOSAR AP, etc. (see Figure 16). Process optimization and transformation will also require the introduction of software development testing and verification tools like JIRA, ZenTao, Synopsys, and Robot Framework.
Figure 16 AUTOSAR Toolchain Image source: CSDN
4. Transformation in Cost Control Methods
Those who have worked for automotive Tier 1 suppliers know the brutal process of automotive component business quoting – “There is no minimum, only lower.” The end result, whether you believe it or not, will be a loss of product quality. This reflects the current mindset of traditional OEMs from one dimension: the functional decisions of a car depend more on the prices of components. This approach can be understood in the past when mechanical structures dominated automotive design. However, with the development of software-driven vehicles, as mentioned in previous articles, the importance of total lifecycle costs far outweighs the current competition over unit costs. In contrast, in new force car manufacturers like Nio, Xiaopeng, and Li Auto, delivering eye-catching features to consumers is viewed as a more important decision-making basis.
In component procurement, this “cutting to the bone” low-price strategy brings negative impacts. Engineers, whether from suppliers or OEMs, will continually reduce critical computing resources such as processor computing power, memory, and communication bandwidth, thus lowering hardware costs. However, this fundamentally damages software and leads to unpredictable consequences:
-
Software engineers will have to optimize their code to fit within limited computing resources. However, due to the complexity of the system, the consequence of this is that various inexplicable problems will be discovered during future performance testing, making it difficult to find root causes, thereby increasing engineering costs and even delaying product launch cycles. On the other hand, even if the root cause is not found, pressured by project timelines, engineers will also adopt temporary solutions to meet project delivery, planting hidden dangers for post-production product quality and increasing after-sales service costs.
-
Software engineers will have to compress their code to ensure it is small enough to run in limited memory. The code must be sufficiently streamlined to ensure that every bit of memory is fully utilized. As a result, adding any new features will become nearly impossible. Worse, even fixing defects will be impossible, leading to hardware recalls. These factors increase engineering costs while further exacerbating the company’s after-sales service costs and diminishing sources of software sales revenue.
-
Over-optimization of code will make subsequent code maintenance particularly difficult. Complex statements will make maintenance a nightmare for later personnel. Modifying code becomes a nightmare for everyone.
-
Excessive streamlining of code will make it difficult to achieve code reusability and portability. It will also prevent pre-embedding of functionalities. Thus, the only way forward is to conduct firmware and application software updates through OTA from top to bottom. From the customer’s cost perspective, this wastes the customer’s time and increases data costs. From a business perspective, it increases internal operational costs and software engineering costs.
Figure 17 Total Lifecycle Costs
Here, we are not emphasizing that the traditional Cost Per Unit cost control is unimportant. We stress the concept of total lifecycle costs. As shown in Figure 17. Therefore, when evaluating the unit cost of components, aside from the costs related to the components, the project delay risks, product launch windows, engineering costs, debugging costs, after-sales service costs, code reuse, and opportunity costs for future new sales revenue growth must all be considered.
The diversity of consumer demands and customization requests drive OEMs to create different configuration versions, resulting in different automotive variants. For example, for a simple power system control application function, there could be 3488 different functional configurations (Note: from Manfred Broy). Currently, luxury cars are generally equipped with about 120 ECUs, and simple “yes” or “no” configurations can result in 2120 variants for consumers to choose from. Besides market and user drives, over the long lifecycle of vehicles (10-15 years), various minor updates, mid-term changes, and major changes, as well as VAVE, are constantly emerging, leading to different FITs and FORMs for similar ECUs, which may also come pre-installed with different software versions. Such a multitude of variants requires enormous verification and confirmation work, inevitably generating huge automotive engineering costs. Likewise, the vast number of automotive variants places enormous pressure on after-sales service spare parts, service skills, and recall budgets.
The “Wright’s Law” of the automotive industry (Note: Wright’s Law was proposed in 1936 by American aerospace engineer Theodore Wright, linking manufacturing efficiency with manufacturing experience, with the core idea being that every time the production of a certain unit of product doubles, the manufacturing cost will decrease by a constant percentage) states that “for each doubling of the production of a single model of car, the cost price will decrease by 15%”. This will ultimately drive hardware standardization and reduce automotive variants, thereby lowering automotive engineering costs; the differentiation of functionalities will increasingly be achieved through software competition.
Figure 18 OTA Upgrade News for a Certain Brand of Car
However, the cost increase brought about by automotive software will increasingly become apparent. How to control the poor quality costs of software will become a challenge for every automotive professional. Figure 18 is a news report about OTA upgrades for a certain brand of car (German “Auto Motor und Sport” reported), where a 12-hour upgrade process saw a 7.5-hour software installation process. Calculating at 4G speed, the upgrade package reached as high as 30GB, with per-car data costs potentially reaching three figures. What’s more shocking is that the battery was drained during the process, leaving consumers in a bind.
The automotive engineering costs also have another dimension, which is the variant of automotive software. Traditional ECU components will have different FITs and Forms over the lifecycle of the vehicle. However, the software differences between ECU variants with different external dimensions may not exceed 10%. Unfortunately, due to the lack of software reusability and the mindset of controlling unit hardware costs, it becomes difficult to quickly transfer software from one ECU to another. This results in most software needing to be rewritten (according to data provided by the German automotive industry, most software changes actually only have a 10% variance.). With the intelligence of vehicles developing, the generalization of underlying hardware, the trend of software reusability is inevitable. Thus, the concept of software products (see Figure 19 for an example) urgently needs to be established and practiced within vehicle manufacturers.
Figure 19 Conceptual Diagram of Software Products
5.Concluding Remarks
SDV, software-driven vehicles, undoubtedly present a topic that every organization and every automotive professional must face. Although automotive software is still relatively small compared to hardware, it requires “water”, “soil”, and “sunshine” to grow, needing the care and nurturing of corporate managers and every automotive professional. However, in the face of this unprecedented transformation in the automotive industry, software will undoubtedly leverage the entire automotive supply chain, generating new value and driving innovation and reconstruction at various stages of the automotive lifecycle, as shown in Figure 20.
Figure 20 Automotive Lifecycle Ecological Chain
In this process, awakened OEMs are beginning to collaborate with external companies, such as Zero束 Automotive Software and Aisuo Management Consulting’s cloud-based DevOPS transformation; Geely Automotive’s overall process optimization, reconstruction, software review, etc. These are all in response to the major changes brought about by software-driven vehicles, building a healthy software ecosystem through extensive ecological connections; on the other hand, it also reflects that companies are beginning to face the problems at hand, actively promoting organizational change, mindset transformation, technical know-how, talent reserves, and the construction of process systems.
Only in this way can a synergistic industrial ecosystem be built, allowing smart cars and even autonomous driving technology to progress further.
Follow our official account, click the “…” in the upper right corner of the homepage, set it as a star, and stay updated on the latest news in smart automotive electronics and software.
【Disclaimer】 The article represents the author’s independent views and does not reflect the position of Wangcai Automotive Electronics. If there are issues regarding the content, copyright, etc., please contact Wangcai Automotive Electronics within 30 days of publication for deletion or negotiation of copyright usage.
