preface:
：
This article was rewritten by the translator of Automotive Software Architecture according to the translator's order, the original article was written in March 2020, and two years later, the author has supplemented some of these ideas with the latest practices in the industry. This article provides a comprehensive overview of the concept of "software-defined vehicles" and includes:
1. Speculation on whether software can define the car
2. How to define "defining the car" through history
3. Split analysis of the full stack of automotive software ecology
4. How to look at the essence of this change from a historical perspective
5. Challenges this transformation poses to the automotive industry and businesses
It contains some authors' views on the automotive industry and automotive software, and their conclusions may not be absolute, but the thinking on the history of the automotive and consumer electronics industries, the discussion of the nature of travel, the summary of the panorama of automotive software, and the analysis of new issues related to automotive software are still worth learning, which helps relevant practitioners to judge the future of the industry more critically. It can be said that "planting is useless, as long as it leads to the breeze".
1.
Can software define the car?
Some reasons for vulnerabilities
When "software-defined cars" have become known to women and children, a soul torture has always bothered me:
Can software really define the car?
The conclusion of this question may not be important, but by asking the truth, it helps us to better understand automotive software and look at this era more rationally. The reasons for supporting "software-defined cars" are most commonly found in the following three, all of which seem to be inappropriate:
Point one: the development of the car and the mobile phone a few years ago is similar, now the mobile phone hardware homogenization is serious, competitiveness mainly comes from the software ecology; so a few years later the car will also be hardware standardization, and the software through the decoupling with standardized hardware, become the decisive factor in the competitiveness of the car.
Loopholes in point one: This view is fairly mainstream. Let's not talk about whether the car will become a "big phone", but has the mobile phone hardware really been homogenized? So why are Apple, Samsung, Huawei, Xiaomi, OPPO and other head mobile phone manufacturers developing their own chips, and why huawei mobile phones will be necked by the United States? Today's mobile phones around the world are using the App Store and Google Play, two highly homogeneous software ecosystems, why are consumers still willing to spend nearly ten times the price to buy high-end machines such as Apple and Huawei? If we look at the computer industry, which has a longer history than mobile phones, hardware such as CPU, memory, graphics cards and even lightweight materials is still the differentiated selling point of high-end PCs today.
In fact, as early as the emergence of the X86 architecture, the software and hardware in the computer field have been decoupled from it, but since then, hardware and software have been intertwined. Software became the main theme of development when hardware was leading, and then for a period of time, software gradually became complex driven by consumer demand, and hardware resources became a bottleneck. Today, even if Moore's Law is close to failure, the head PC companies have not stopped investing in hardware design. There seems to be no trend of "developing hardware to the head first, and then relying on software-defined products".
This is still the case in the computer industry, and the automotive industry is too late. Whether it is the wire control technology and chip technology of automatic driving, the MEC/RSU of road vehicle collaboration, etc., there are a large number of basic problems that are not related to software algorithms that have not yet been solved, and the staggered progress of software and hardware in similar computer fields has not even begun. And if the homogenization of hardware is difficult to occur, then the decoupling of software and hardware seems to be more difficult to promote "software-defined cars". Decoupled hardware and software can only be developed synchronously in time at best, and does not mean that electronic/mechanical hardware must be defined around software. It is true that software is more flexible in meeting consumer needs, but the cost of failure is also smaller than that of hardware, which is difficult to invest heavy resources to upgrade and cooperate with its mass production just for a software/algorithm that has not been proven by the market. Therefore, it is not so much that software defines the car, but rather that "function defines the car, and software and hardware go hand in hand to implement the function."
Point 2: Tesla has created a precedent for software commoditization, and relying on the service-oriented architecture of automotive payment software and subscription ecology in the future will be the core competitiveness of car companies.
The loophole of point two: This view has become more popular with the implementation of SOA architecture in recent years. People who hold this view often cite the example of Apple's software ecology to defeat Nokia, and think that Tesla is the next Apple, and if traditional car companies do not follow suit, they will be eliminated like Nokia. But first of all, it is debatable whether Apple's victory over Nokia by software ecology is a fact. If you look back at the news and changes in smartphone shipments between 2007 and 2011, you will find that the Apple and Android software ecosystem may have been the last straw that crushed Nokia. In 2007, when the App Store was not yet on the shelves, the advent of the first iPhone had already beaten Nokia with its simple appearance, excellent human-computer interaction design, high-sensitivity large touch screen, and efficient Internet experience, and these KSFs seemed to have little to do with software.
Second, although FSD paid software generates considerable profits for Tesla, it is not necessarily the most critical element to attract consumers to buy a car. As a Tesla owner, when buying a car, I also value the endurance, fast charging, charging pile deployment, modeling, acceleration, high sensitivity central control large screen and not chicken-computer interaction design at the same price, and the advanced manufacturing capabilities such as industry-leading HW3.0, the industry's first mass-produced SiC power semiconductor, high-current overcharge and other hardware, and even the industry's first-class automation and zero inventory management are also key.
Third, although SOA has greatly improved the scalability of automotive software, in my opinion, automotive software may not really form a thriving ecosystem like the App Store. After all, in another field of medicine related to human life, it has been adopting a full-cycle "centralized" model of compulsory clinical trials, strict access to listing, and prescription drug purchase, and has never formed a highly open ecology that relies on SDK free-range breeding like mobile phone software. Therefore, it is undeniable that software commoditization and the SOA architecture behind it have become a "compulsory course" for car companies in the new era, but it is difficult to promote the automotive software ecology to the richness of the mobile phone software ecology; and even if the automotive software ecology reaches this richness, the examples of the iPhone and Tesla inspire us that perhaps it is still difficult to define the car only by relying on the prosperous and open software ecology.
Point three: The code length of the car has exceeded that of other consumer electronics products, so the car is already a software-driven commodity.
Loopholes in point three: This view is obvious from a technical point of view, but because it is often cited and misleading, it is necessary to clarify. The sheer size of car code is a fact, for example, the number of XML files in engine control codes has reached 7 million lines, far more than ordinary computer software. But this view does not take into account the problem of code efficiency.
The embedded software of the car requires hard real-time, the operating system running time overhead requirements are strict, which means that each task has a clear and personalized activation time and deadline, so the scheduling design between tasks must also take into account the interrelationship of each two tasks in time one by one, this interrelationship often varies according to product function and hardware personality, so the software can be reused libraries less, usually need to take an almost enumerative programming method, the efficiency is obviously not high. Computer software mostly uses interpreted languages, a large number of functional scenarios can reuse ready-made libraries, and the code referencing the library only needs a few strokes and does not need to be converted into cumbersome C code like the compiled language of the embedded system, which can achieve powerful functions. This creates the "illusion" of software-driven automotive development. Car software code is produced a lot, but it does not mean that the software is decisive for the car.
summary:
There are many more such ideas, which do show that software has become more important in the car, but it does not seem to indicate that software can define the car. So, what is the essence of "software-defined cars"? To clarify this account, it is necessary to go back to the original starting point.
2.
Take history as a mirror
How to define "defining the car"?
For the sake of rigor, before analyzing whether software can define the car, it is necessary to figure out what kind of innovation can be regarded as "can define the car". This is a big problem, different people have different views, and the author should throw bricks and stones here.
Let's start with a story. In the late 1920s, the automotive industry under the Rule of the Ford Model T generally believed that the hardware had been homogenized, and it was difficult to make a big breakthrough, and the industry urgently needed to find new selling points for the car. In 1927, GM established the Art and Color Division, and under the leadership of legendary Harley Earl, a large number of strangely shaped cars were designed, triggering a revolution in the shape of the car. For a time, automakers focused on the design of interior and exterior trim, and relied on the publicity that "cars can reflect the personality of the owner", forcing consumers to pay more for strange shapes. It wasn't until 1965, when a book called Unsafe at Any Speed was published, which attacked the over-design of cars and the neglect of safety, that the more than two decades of styling faded.
When we look back on the history of the automobile, it's hard to argue that this wave redefined the automobile, because most of the products of this wave are no longer able to see the shadow of the contemporary car. On the contrary, we can still remember the Ford Model T that first added a shell to the car a hundred years ago, the Borscher Beetle sixty years ago, and the Giorgiaro Golf, whose ideas have been inherited in today's car styling design, in a sense can be called redefining the car. Deeply study the difference between them and the former, these cross-world works are designed with distinct personality shapes at the same time, just right to solve the travel pain points of people at that time.
So, what kind of innovation can "define the car"? If you return to the source, human beings' demand for socialization and the soul yearning for freedom make travel a just need; and for travel, no matter how the means of transportation change, human requirements are always:
1. Arrive at the destination safely;
2. The less money, time and energy spent on travel, the better;
3. Get better comfort and pleasure when you travel.
1 and 2 are basic requirements, while 3 are advanced requirements.
Figure 1 Examples of the nature of human mobility needs and innovations to meet them
If we summarize the changes that we think have defined the automobile, (in the figure above) they usually make the car a significant improvement in meeting a certain human travel need (safety, consumption, comfort/pleasure), without reversing the basic human travel needs (safety and consumption) that have been met.
The word "basic" is particularly critical in the latter condition, where advanced needs such as comfort and pleasure are often multifaceted and difficult to evaluate what constitutes a setback. For basic needs, consumers have a highly consistent judgment that "needs are better met", and any regression is difficult to accept. The failure to successfully define the innovation of the automobile in history is not that the innovation is not enough, but that they sacrifice the basic travel needs that have been met, especially those related to psychology, because factors such as "comprehensive travel load increase" and other difficult to quantify factors may not be detected by consumers in the short term, so when car companies face consumers who are accustomed to being fed, they can still rely on "freshness" to maintain the false prosperity brought by innovation; but for a long time, Once consumers perceive an increase in load, it can trigger anxiety and frustration, resulting in retaliation for losing trust in innovation, or even surpassing trust, and ultimately deprecating functionality.
Is this somewhat appropriate to the current wave of automotive software? On the surface, the software ecology of the car is constantly booming, but it also creates a considerable number of features that consumers will not use, which are intended to improve the user experience, but provide redundant and useless feedback to the driver, which instead causes the driver to be distracted and anxious. When these features are forcibly sold to consumers at a high premium, although they can "scare" consumers in the short term and trigger an industry pandemic, can we really call it "redefining the car"?
3.
Software cannot define a car
So, can software actually define the car? We might as well take apart all the software on the car and analyze them one by one. We adopt the concept of AutoSAR and dismantle the car software into four domains: "traditional control", "automatic driving", "smart cockpit" and "non-in-vehicle". Eventually we turn the question into:
1. Which of these domains can be defined by software alone;
2. Whether these domains, which can be defined by software alone, can define the car. In each domain, we split the software into basic software (hardware drivers, task scheduling, and other middleware) and application layer software.
Figure 2 Schematic diagram of the composition of automotive software
Software for traditional control domains
Its characteristics are not repeated in the figure above. First, the embedded software in this domain is highly correlated with the setpoint generators, sensors, and actuators associated with it, and it is difficult for software alone to be a determinant of good or bad functionality. Second, this type of software is usually developed directly by Tier1, which provides controllers, actuators, and smart sensors. Because the personality characteristics of many hardware are considered in programming, it is difficult to form a common software scene library in the industry, and Tier 1 has accumulated a considerable amount of code for a long time in the supporting software development of its own products, and even formed a subcode base within the enterprise. This leads to OEMs or technology companies that want to carry the banner of software, even if their programming ability is strong, it is difficult to replace the former, and at most they take the way of software sharing and participate in part of the development of functional software directly related to consumers at the application layer. Obviously, traditional control domains cannot be defined by software alone, and it is difficult for enterprises with only software capabilities to make waves in this area.
Software for autonomous driving domains
Its characteristics are not repeated in the figure above. The status quo of the domain is that, on the one hand, the underlying operating system must be both security-critical, and because of the large amount of data, it needs to use dynamic tasks and memory allocation, the threshold is extremely high, and there have only been four or five that can be done for many years, which is difficult to become the leading factor leading the trend of software-defined cars. On the other hand, while autonomous driving can obviously define cars, it has not yet developed to a stage where it can be defined entirely by algorithmic software. It still has many engineering problems to be solved in terms of system and hardware, and the current industry discourse power dispute is not only around software algorithms, but also around hardware-related computing platforms and computing power. In addition, as mentioned earlier, the field is also likely to have a similar software and hardware alternating development phenomenon as the computer industry in the future. Therefore, we cannot assume that the autonomous driving domain is defined by software.
Roadside and cloud-side software
Its characteristics are not repeated in the figure above. First, while the development of the domain is mainly focused on software-determined areas such as algorithms and information security, it must be attached to the autopilot function of the car to exert maximum value. Secondly, although the hardware requirements in this domain are relatively low and the maturity is relatively high, there are still communication and systemic problems such as the delay of the real-time task unloading of the vehicle and the fading of the channel when the vehicle moves at high speed, which not only rely on the optimization of the algorithm, but also rely on the hardware performance of the roadside device. In the short term, at least until autonomous driving is implemented on a large scale, the domain is also difficult to define cars.
Software for smart cockpit domains
With these three domains excluded, the smart cockpit becomes the last hope to support the idea that "software can define the car." In fact, when most people talk about software-defined cars, they tend to talk about the impact of software features in the domain that favor consumer electronics on cars. For the consumer electronics and capital community, this field is similar to mobile phones, with low thresholds and large innovation space, which is the best entrance to the automotive industry. In order to make the "bureau" bigger, it even proposed the concept of skateboard chassis matched with the smart cockpit, believing that the future car = skateboard chassis + intelligent cockpit + road cloud synergy. Within the automotive industry, because the bargaining power of the whole vehicle is reduced, the threshold in other high-premium areas is too high (such as automatic driving), so the smart cockpit is also regarded as the primary breakthrough to improve the profit of the vehicle.
Does it seem that it really has the potential to define the car? We may wish to break it down into two questions: 1. Can software define the intelligent cockpit? 2. Can smart cockpits define cars? From the author's personal point of view, the answer to both is temporarily negative.
First, software doesn't define a smart cockpit. Or from the field of mobile phones similar to the smart cockpit. The business model of hardware homogenization + software differentiation in the mobile phone field does exist, but high-end mobile phones, whether it is Apple, Samsung or Huawei, are continuing to iterate hardware. Even when mobile phone manufacturers around the world are sharing the two extremely homogeneous software ecosystems of the App Store and Google Play, hardware seems to have become the core competitiveness. By analogy, the business model of hardware homogenization (even oem) + software differentiation can indeed be realized in the car, which reduces the threshold for car building, but the car created by the model is difficult to have lasting power.
Under the premise of hardware homogenization, relying on novel software functions can indeed temporarily satisfy consumers' curiosity about black technology, but the pursuit of high-end consumers is not attracted enough, which means that the price of the model is difficult to increase, the cost pressure will be directly transmitted back to the hardware, car companies will have to use low-cost hardware, which in turn will limit the space for software function innovation, and eventually the so-called software of such models is likely to go to a vicious circle of "flashy".
Second, the current smart cockpit is also difficult to define the car. In the field of human factors engineering, the functions handled by the intelligent cockpit are referred to as secondary driving tasks. The corresponding throttle brake steering wheel operation is the main driving task. At present, the main action of most car companies to build smart cockpits is to install iPads on the car, and does not take into account the "cognitive dispersion" caused by the secondary driving task to the main driving task, which may lead to the expected functional safety risks; or it may be because of a chicken rib design to increase the load on the driver, resulting in frustration, which eventually leads to the driver's abandonment of functions and even the reduction of brand reputation. On this topic, involving driver situation awareness, feedback, load, trust and many other driving psychology issues, here will not be repeated, it is recommended that interested readers read the author's other translation of "Automotive Factors Engineering" or two popular science articles "The development trend and practice of intelligent cockpit human-computer interaction", "Is it feasible to change the central control of all cars to iPads?" 》。
In short, if the intelligent cockpit can define the car, there may be only two possibilities: first, automatic driving becomes a reality, the main driving task is handed over to the machine, the vehicle becomes the third living space, and the intelligent cockpit will become the main battlefield of model differentiation; second, automatic driving has not been realized, but the function of the intelligent cockpit fully takes into account the occupation of the attention resources of the secondary driving task on the main driving task and the expected functional safety. Most of the domestic car companies do much better.
summary
The increase in the number and variety of automotive software has become an irreversible trend, and relying on software to obtain higher profits is also the basis for the future continuous growth of all car companies. Software and hardware decoupling is happening, AI algorithms implemented by software are one of the important issues driving the development of automobiles, SOA-based software ecology has become a compulsory course for all car companies, and personalized software functions based on intelligent cockpits are also thriving. However, none of this is enough to make software-defined cars.
If software can't define cars, what is the nature of the "politically correct" view of "software-defined cars"?
4.
The continuation of history
A game made by outside forces
If you look back at history, you will find that the trajectory of "software-defined cars" and the popular trends in the history of automobiles have many similarities in development trajectory, and it is not a "major change that has not been encountered in a hundred years". In essence, it is a slogan designed by external forces to "enter the automotive industry by yourself", but it has objectively promoted the pandemic of automotive software and is bound to change the automotive industry. As for the correctness of the "software-defined car" slogan itself, it may not matter.
How is "software-defined car" popular?
According to online rumors, the first proposal of software-defined cars was around 2002-2007 (although the author did not find, only the 2002 GM's automotive SOA scheme), but it is certain that it did not stir up much waves at that time. It wasn't until 2016, when it was proposed by The head of Baidu's autonomous driving, that the slogan became a buzzword. By 2017, the first version of Adaptive AutoSAR, R17-03, was released, and the concept of Adaptive Car was proposed (Figure 3), the industry's first prototype of the architecture of a software-defined car, which has been used today. Since then, people such as NVIDIA Jen-Hsun Huang and other opinion leaders inside and outside the industry have given a more specific explanation for the concept, and software-defined cars have gradually become an industry pandemic.
On another story line, since 2014, Tesla has successively implemented the central control large screen, SOTA/FOTA, paid software model, a large number of in-car entertainment functions, and realized a centralized distributed electronic and electrical architecture in the Model3 delivered in 2017. The industry generally feels that it is a proof of "software-defined cars".
Figure 3. The concept of adaptive Car proposed by the AUTOSAR organization in 2017
The popularity of "software-defined cars" is no different from other pandemics in automotive history
Looking at the entire history of automobile development, it is clear that the pandemic in the automotive industry has followed a similar trajectory, and "software-defined cars" are no exception. To sum up, the trajectory of an automotive industry pandemic usually has two key elements:
The first element: the fire of the times to the car
In essence, the car is not a technology, it is the carrier of various emerging technologies that humans integrate in order to obtain a better travel experience. Therefore, the popular trend of automobiles is often ignited by the "fire of the times".
The "fire" of the times usually burns into cars in two ways.
One way is to ignite the change from the demand side and be actively completed by the industry. This demand or the great change of the times changed the way of life of human beings, so that people have new expectations for travel (such as the industrial revolution in 1760 let humans learn to improve production efficiency with the help of machines, humans brought this expectation to the field of travel, invented the earliest steam-powered car in 1801, human beings entered the automobile era), or the car has obvious shortcomings in meeting human travel needs, engineers take problems to the trend of the times to find solutions (for example, in the 1970s, In order to solve the problem of long start-up time caused by mechanical disconnection ignition, automotive engineers went to the fast-moving solid-state electronics at that time to find answers, so the electronic ignition technology based on transistors was invented, and the automobile entered the electronic age).
The other is ignited from the supply side and driven by external forces to change the automotive industry. Whenever a new technology appears across the era, the stakeholders of capital power and new technologies hope to find the landing scene of technology in the car, so as to share in the huge market of the car. With the car can meet the basic needs of human travel, while the capital force in the automotive industry chain more and more penetration, this "the outside world first set up a stage, the automotive industry and then a thousand calls out" approach has gradually become the mainstream. This "fire" of software-defined cars is ignited in this mode.
In the 2000s, when the ICT industry proposed software-defined cars, concepts such as software-defined networks and software-defined Radio were also proposed. At that time, the "fire of the times" was more triggered by the rise of software engineering, and the software engineering community expected to use software to digitize all physical entities and accelerate the development of society with the advantages of software in digital computing. But in the year before smartphones appeared, the capital and software engineering communities did not know how to burn this fire to the car, but instead turned the software fire to the more promising network/communications field. As an aside, the fire did ignite the communications sector, and the technology boom in the communications sector also affected the automotive industry, and the high-bandwidth Flexray bus was proposed during this period.
By 2016, digitalization and intelligence had become the clear themes of the times. Emerging basic technologies such as 5G communications, data science, artificial intelligence, and cloud computing are beginning to emerge, and the infinite possibilities brought about by their integration with cars will naturally make human imaginations, and software is one of the core elements of this integration. At the same time, the smartphone and Internet industries are gradually entering a mature period, and capitalists and related companies urgently need to find a new profit curve, which is geographical advantage. So the fire of software burned more vigorously to the car.
However, as a heavy asset industry, automobiles are huge. In addition to the "time of day" and "geographical advantage" of the outside world, it is also necessary to "people" to really wake up the entire industry. That is the second element we are going to talk about.
The second element: the adventurer's game-breaker
If the outside world's voice is to really shake the big ship of the automotive industry, it usually requires a person who dares to take risks to land his dream, which in turn triggers the catfish effect. At this time, traditional car companies will have to take over to avoid being eliminated. A famous example in history is the advent of the Ford Model T.
In the 1900s, people in first- and second-tier cities in the West were looking forward to owning a car as a new and faster means of travel. However, due to price and manufacturing efficiency, the automobile was still the exclusive property of the nobility. Until the advent of the Ford Model T in 1908, the price of the car was reduced by 80% by relying on assembly line operations, and the production cycle was increased from the industry average of more than 100 vehicles per year to tens of seconds. Cars flew into the homes of ordinary people, and the bigwigs of the automotive industry realized the crisis, all in assembly line production, and the curtain of the era of automobile popularization was lifted.
What has prompted "software-defined cars" to be valued by the automotive industry is the emergence of Tesla. Since 2014, Tesla's series of software innovations in SOTA/FOTA, paid software models, and in-car entertainment functions have made the automotive industry aware of the crisis, so mainstream OEMs in Europe and the United States joined forces to create AP AutoSAR in 2016 to prepare for "facing the enemy". In 2019, after model 3 relied on excellent software features and lower prices to beat the market and the market value exceeded GM, traditional car companies were truly impacted, and "software-defined cars" have resounded since then.
ponder
It is not difficult to perceive that the popularity of "software-defined cars" is similar to other popular trends in the history of the automobile, and the big premise of these popular trends is due to the new expectations of the times, and the small premise is that an adventurer lands these new expectations, which in turn triggers the industry-wide pandemic. Therefore, it is difficult for us to call "software-defined cars" "the great change that has not been encountered in a hundred years", this slogan is more like the capital and Internet circles to enter the automotive industry and "do the game", but it objectively does promote automotive software to become a pandemic in the industry. As for the "software-defined car" itself, it is just a slogan designed by external forces to set up a stage, whether it is a fact may not matter, it can also be called "software-driven car", "software changes the car", "software-enhanced car" and so on.
5.
Software's changes to the automotive industry
Although the popularity of software has not reached the dominance of "defining the car", it is still (or about to) transform the automotive industry in many ways. The impact of these changes on automotive industry practitioners is far more profound than a slogan. We might as well raise the picture and think about how we would evaluate the most groundbreaking changes that software brings to the industry when humans summarize the cars of our time hundreds of years later. In my opinion, the most fundamental changes are mainly in three aspects:
Figure 4: Changes and challenges brought by automotive software to the industry
Change 1: The transformation of the car from one-time delivery to continuous service has changed the production, supply and research model of the car and the way the automotive industry thinks
Relying on the emergence of software, secondary paid software, and subscription services that rely on OTAs to continuously upgrade, the car is no longer just a one-time delivery product, but also needs to provide continuous service throughout the life cycle of the vehicle. The value of the vehicle also depends not only on the visible and well-defined mechanical devices, but also on invisible, value-added, and sustainable profitable software services. On the sales side, this will change the price model of automotive products, how to assess the value of software, and quantify its market contribution will become a new challenge. On the supply side, this will affect the original cost management model based on BOM+ software for car companies; on the research and development side, this will affect the quality assurance methodology of traditional car companies.
At the same time, the shift from one-time delivery to continuous service will also change the DNA of the automotive industry to some extent. The original automotive industry was characterized by labor-intensive manufacturing, and solving the problem of employment population was an important mission entrusted to it by the state, while the quality of employment was ignored for a long time. With the popularity of software, the automotive industry will have some of the attributes of a knowledge-intensive service industry, which puts forward new requirements for the way the industry works and thinks.
Change two: Cars move from logic-driven to data-driven, creating a host of enormous challenges
New technologies and algorithms such as AI emerging in the context of the era of digitalization and intelligence have promoted the emergence of a series of functions that rely on state estimation and active decision-making through the integration of software and automobiles. The "blood vessels" of these functions are no longer black-and-white logic, but data. This will present a number of challenges:
Data-driven data-driven introduces non-deterministic components to the car for the first time, and it is a new challenge to combine traditional vehicle driving control models and non-deterministic probability estimation models in automotive software. The labor-intensive approach to code development implemented by if else logical enumeration alone will be difficult to measure the success or failure of software. At the same time, the "torque structure" that the original vehicle control follows and can be used to clearly decompose software requirements into different controllers will be difficult to play the role of "brain", which means that the complexity of the software architecture will be greatly improved, the decoupling between functions will become more and more difficult, and the cooperation boundary of software development will become blurred, which will pose great challenges to development efficiency and quality.
Self-reinforcing complexity cycle between automotive functions and consumer needs Because the addition of data continues to accelerate, car companies will respond more intuitively and sensitively to the market, and the vehicle development cycle will continue to be shortened.
Figure 5 Hollnagel complexity self-reinforcing cycle (Image from Automotive Ergonomics Engineering)
The data will change the original automotive-related rule-making system. The rules originally derived from physical principles and experience may be determined directly based on real driving data in the future, and the resulting standards are more in line with the facts, but the role of industry authority will gradually decrease. It affects not only the formulation of regulations (such as the RDE cycle of emission regulations, etc.), but also the various rules that need to be formulated throughout the life cycle of the car (such as Tesla's UBI car insurance model).
The data itself brings with it issues such as cybersecurity and privacy. First of all, with the increase in the number of cyber attacks on servers, keyless entry, and in-vehicle apps, and the introduction of regulations such as WP.29 and ISO21434 in the industry, network security has become an important topic in automobiles. In terms of privacy, in the context of the personal data protection law and the cybersecurity law, the industry has successively issued ISO 21434, ISO 24089, UNWP29 R156 and "Several Provisions on Automotive Data Security Management" to a new height.
Change three: Security and flexibility will have to be compatible
The original vehicle control software and the newly added consumer experience software such as smart cockpits have conflicts in engineering, but they have to be integrated. On the one hand, in the past, automotive software accounted for a small proportion of the value of the whole vehicle, and the functions that users could directly perceive were limited. Compared with those software-led industries that have matured accumulations in the development paradigm, automotive software is still a little naïve in the face of upcoming data-driven, iterative consumer experience-oriented product development. But on the other hand, the car's software attaches great importance to safety, when the "more agile" software development paradigm that has been very mature in other fields is applied to the automotive software development scenario that seems to be "more clumsy" but has extremely strict safety requirements, it is bound to experience a period of pain (on this topic, it is recommended to read this public account article "Can NPDS and Agile Development Coexist"). There have also been many attempts in the industry, such as the SOA platform built by SAIC Zero Beam, which integrates the functions that focus on safety and entertainment in the form of software ecological developers, and provides a unified vehicle-level safety acceptance in the background of the platform, which to a certain extent achieves the harmonious coexistence of security and non-security software.
If process compatibility can still be guaranteed by mechanisms, then conflicts in development philosophy are more difficult to resolve. Taking the control of the traditional power domain and chassis domain as an example, the code used for diagnosis, safety redundancy, and multi-level monitoring accounts for more than one-third of the software, and the most complex software development in which the author has participated has experienced more than 30 different types of tests, each test writing Case to the production of test software, the test to the review or even the second round of testing, the second round of Review, troubleshooting, which takes a very long time (Figure 4). R&D personnel would rather lengthen the R&D cycle than bear the risk of dereliction of duty of putting the vehicle in a dangerous situation, which is difficult for software teams from the consumer electronics field to understand in the short term.
From another point of view, the current software that is still easy to decouple needs to be so cumbersome to deal with, and in the future, when faced with more coupled and faster iteration software, will this extremely emphasis on safety be like the epidemic prevention work we are experiencing in some areas, in the face of rapid reproduction and intricate chains of relationships, caught in endless resource investment but wretched? Or, the industry may not eventually unify the management of software that emphasizes safety and software that emphasizes experience; instead, it will align with the more traditional pharmaceutical industry, dividing software into "safety critical" (prescription drugs) and "non-safety critical" (non-safety critical) according to the SOA architecture, the former must go through expert consultation, reference to driver habits and past driving data, "the right medicine" after consultation, and the number of such software must be strictly controlled to avoid endless investment in research and development resources; the latter can be "no threshold". Developed and sold. Where to go, the industry has yet to be explored.
Figure 6. A traditional controller project involves testing/checking items for software
6.
A new issue for car companies
Software has changed the automotive industry, and car companies are facing new challenges in business development and organizational talent support in order to cooperate with this change (Figure 5). The author's ability is limited, and I can only try to provoke you to think, in fact, each topic is large enough to carry out a consulting project.
Figure 7. Software brings new issues to car companies
A new issue in the operating model of car companies
The right to speak of car companies will no longer come from the core competitiveness of mechanical hardware, but from the two aspects of "data" and "computing platform". This poses two challenges for the operation of the enterprise:
Internally, the model originally developed around visible and tangible hardware technology no longer makes much sense. In order to improve the development efficiency, car companies are more willing to adopt the software and hardware synchronous engineering mode, around a certain demand, with data and computing platform as the medium, the decoupled software and hardware are developed in parallel. How do hardware and software development teams work together in sync? How do you ensure that data flows smoothly within/across organizations while meeting information security requirements? How can the platforming strategy of software and hardware be compatible, is it still based on the car platform, or is it moving towards modular variant management such as Volkswagen's Toolkit model? All these pose new challenges to car companies.
Externally, the traditional cooperation model between manufacturers, primary suppliers and secondary suppliers will be broken, bringing great unpredictability to the original competitive relationship. Should car companies master the core technology and keep it secret to seek monopoly, or should they share the technology to seek ecological cooperation? What businesses can be developed cooperatively, outsourced or outsourced or outsourced or developed in-house? How do businesses at different levels, especially those with waterfall and agile processes, work together seamlessly? How is profit divided? How is the responsibility for after-sales divided? These problems will be repeatedly seen and thought about by enterprises.
A new topic for R&D organizations of car companies
The new operating model will also have to be taken over by the new organizational and talent model, and the challenges remain numerous.
From an organizational point of view, should the automobile R&D organization with the increase in the number of software be based on customer differences or platform-oriented? Is it profitability accounting by product line, or is it based on the concept of autosar architecture, dividing the organization into cost centers for basic software and product profit centers for application software? How to organically authorize and control the SOA platform and the developer ecosystem across enterprises and beyond? Will the implementation of organizational reforms be gradual or refactored (e.g. the establishment of separate software companies that can be split and listed)? Should the leader of the organization come from the traditional automotive industry or the IT industry, should the internal promotion or the external parachute? These will all be related to the effect and implementation costs of the enterprise transformation.
New issues for automotive companies
The first is the shift in employment standards. The traditional development model of "formulating requirements by professionals and then decomposing and implementing them step by step" is transcendental, each engineer only needs to deal with local knowledge, and the requirements for their abilities are often classic knowledge systems such as thermodynamics, tire dynamics, mechanical principles, etc., and the design method is based on the deduction and reasoning of principles. "Software-defined cars" will break this rule to a large extent, and companies will more directly obtain corresponding data from consumer groups with different levels of demand and personalities, and actively lead and create demand. This development model is empirical (a posterio) doctrine, and the ability requirements for engineers are knowledge of statistics, human factors engineering, etc. R&D personnel can no longer drill the tip of logic, but should go out of the office and make good use of the data to summarize and summarize to get conclusions.
Secondly, for employers, they will face the dilemma of an extreme shortage of talents with structural thinking. The problem of seeing only individual "trees" and not seeing the overall "forest" is prominent. In the face of more complex automotive software architectures in the new era, this lack of development efficiency will not only reduce development efficiency, but also lead to a lack of overall consideration of functions in the design, and lead to serious technical debt risks after the demand is expanded.
However, it is not easy to train an engineer with top-level design thinking in the automotive industry. He not only needs to master considerable basic scientific knowledge in the face of self-immature technological applications such as autonomous driving, but also needs to have a comprehensive understanding of the increasingly heterogeneous functions of cars that are difficult to exchange boundaries according to physical principles, and sometimes even need to be supplemented by some so-called "intuition". From the perspective of actual combat, this "intuition" is particularly important for automotive engineers, but it cannot be learned in books, and it is bound to need to sit in the car and drive from an early age, and observe, experience, and love through the "communication" with the vehicle in the journey of millions of kilometers. Gone are the days when driving experience was lacking but could become a good systems engineer, or even a calibration engineer.
In addition, for enterprises, the original labor-intensive industry characteristics shown in the salary system and key performance indicators must also be changed, originally relying on platform attractiveness and excellent training system, large enterprises do not care about the loss of talent, known as "Whampoa Military Academy". However, in the face of scarce top-level architecture talents in the future, enterprises may no longer have to waste the capital of talents, and they must be differentiated in their selection and retention.
7.
Introduction to Automotive Software Architecture
With the rise of automotive software, a large number of new software and features have been introduced into the car. They are either concentrated on a computing platform or distributed across different sensors and controllers. To better and sustainably manage these software, we must build a future-oriented "soul framework" for software on top of the "flesh and bones" of sensors, controllers, and computing platforms. Software architecture will play a decisive role. It is in this context that this book was introduced to China by the Machinery Industry Press. It is the first book in China dedicated to the study of automotive software architecture, written by Dr. Miroslaw Staron, head of the Department of Information Science at the University of Gothenburg, Sweden, who is one of the few scholars in the academic community to study automotive software from the perspective of software engineering, and is also a well-known expert in the field of automotive software engineering.
The book has 10 chapters, each of which is relatively independent except for the summary of chapter 10. For details, please refer to the article "Automotive Software Architecture After Reading", which will not be repeated here. Here are my reading tips for different reading groups:
For other industry software practitioners interested in entering the automotive sector, it is recommended to purchase this book and focus on chapters three, four, five, and eight, which talk about the processes, architectures, and coding requirements specific to automotive software.
For college students who are interested in automotive research and development, or automotive engineers who have not been engaged in automotive software development but want to change careers into the automotive software industry, the content of this book is more abstract, and the author recommends giving priority to reading the other two translations of the Mechanical Industry Press. One is the newly published "Automotive Software Development Practice" written by a senior expert of German Volkswagen; the other is the upcoming classic textbook of automotive software "Automotive Software Engineering (Sixth Edition)".
About the Author:
The author of this article has worked in a number of Tier1, engaged in chassis and power domain product system function definition, software product design, software development and testing, quality process management, platform configuration management and controller project management and other positions, as a supplier has participated in the domestic OEM vehicle software development work, is now working in a foreign strategic consulting company. Published and translated books "Automotive Human Factors Engineering", "Automotive Software Architecture", "Automotive Software Engineering (Sixth Edition)"