Complexity of Automotive Software
Author: eng2mot
In the context of car’s new four modernizations, software is undoubtedly the core part of automotive development. However, with the continuous increase of its functionality, the potential complexity of software is also gradually growing. Due to the invisibility of software, engineers cannot fully understand the importance of software complexity.
Over time, the complexity of software will appear in the form of a large number of defect reports and increased maintenance costs.
Size of Software
When it comes to the complexity of software, the first thing that comes to mind is the size of software code. However, not all large software is complex. Nonetheless, the size of software is the most direct attribute to represent software complexity.
The size of software is usually represented by its number of lines of code, which makes it easier for people to understand the complexity of software. For example, one line of code is equivalent to one line of text in a book. If the size of ECU software is 300 pages and each page has 50 lines, it is roughly equivalent to Jane Austen’s “Pride and Prejudice”.
Volvo stated that by 2020, the number of code lines in its cars is about 100 million, which means the number of code lines in one car is equivalent to the collection of a normal library, which can fulfill the needs of a small town. These 100 million lines of code implement electronic fuel injection, transmission control, engine control, cruise control, powertrain control, adaptive suspension, multi-channel networks, navigation systems, stability control, entertainment information, avoidance, advanced driver assistance systems, active safety, interconnection and many more advanced features.
Statistics show that beginning in 2000, the size of car software has grown by one magnitude every decade. In the next decade, with the addition of the Internet of Things and autonomous driving functions, the size of software in cars will reach the size of the Science Fiction Library of the Massachusetts Institute of Technology by 2030.
System Complexity of Software
The complexity of a system is composed of the number and types of system elements and their interactions. Complexity is the basic element that gives the system its functionality and characteristics, but it is also the reason why the system is difficult to understand.
In the code, millions of elements such as operators, local variables, global variables, conditional statements, preprocessors, pointers, and function calls create complex units and large-scale abstractions.
In addition, the relationship between code and corresponding software versions, requirements, testing, changes, and electronic components creates stunning complexity in automotive software.
However, complexity is usually accumulated in the system due to non-optimized design decisions and underestimated business needs. This type of complexity does not increase the functionality of the software; instead, it consumes a large amount of work and produces software defects.
So, what are the aspects of complexity from a software perspective? Let’s take a look at them one by one.
Complexity of Source CodeAccording to Volvo’s statistics, by 2020 there will be 10 million conditional statements in the entire source code. These are decision blocks and loop blocks. There are also about 3 million functions defined in the entire source code, which are called approximately 30 million times at about 3 million locations in the source code. Many of these functions perform tasks while the vehicle is running.
The probability of a function producing erroneous results depends on the programmer’s skill, code cleanliness, testing quality, and other factors. Even if the probability is very small, such as 0.0001, there will still be hundreds of defects after development. This is not because the developers are not skilled or the testing is not good, but because the overall complexity is astonishing. Huge complexity purely has the potential to cause defects.
Function calls and conditional statements introduce basic complexity. These elements are essential for writing a piece of code to solve a problem. Even more daunting is the occasional complexity, especially the complexity of legacy code. Code written 20-30 years ago introduced deeply nested code areas.
Statistics on nested code show that in 20% of the functions in a car, the original functional areas have a high degree of nesting. New code built on top of its original framework will become a topic of lengthy discussions whether old code should be refactored or left unchanged.
As people become increasingly aware of the impact of high complexity, software engineers are increasingly focused on developing simple code. Following coding guidelines has become a more rigorous practice than ever before. A piece of code cannot be merged into the main code branch unless it meets complexity management guidelines. Deeply nested code, cross signals, incorrect use of pointers and global variables, inconsistent names, lengthy lines, and other unexpected complexity triggers will be rejected.
Although static analysis tools are not perfect, they attempt to systematically help engineers complete this task. Legacy code is thoroughly tested and kept as isolated and unchanged as possible.
Complexity of Architecture
Statistics show that in a modern Volvo car, about 7,000 external signals are connected to more than 120 Electronic Control Units (ECUs). In addition, the number of internal signals connecting software components is two orders of magnitude larger than the number of external signals.
An important task in software architecture design is to isolate architecture components from each other in an ordered manner, creating a reasonable hierarchical structure and relatively independent system partitions. This is crucial for developing new functions on the basis of existing ones in the future. Another equally important task is to make architectural decisions that support attributes such as security, reliability, high performance, and availability.
The problem with balancing the above two coexisting tasks lies in the existence of different levels of architectural considerations, such as allocating ECU functions from a functional perspective and their interaction, ensuring reasonable coordination between them from a requirements perspective, ensuring software component design and interaction from a software design perspective, and considering the union of different levels of consideration, handling it in a reasonable way is a challenge.As the challenge of complexity continues to increase, there have been proposed solutions such as the introduction of AUTOSAR architecture and SOA.
At least on the level of software abstraction, AUTOSAR is another step towards simplifying complexity. By unifying specialized knowledge in the automotive field, the focus points for the development of software architecture standards can be separated, allowing basic software, runtime environments, and adaptive services to be separated.
Compared to AUTOSAR, the Service-Oriented Architecture (SOA) has been relatively successful in reducing complexity. It unifies function and design, while also dividing services. However, a key challenge of SOA is that services themselves can be complex structures composed of many other services. This can create dependencies between service designs, which goes against the principles of SOA.
Another key challenge is that certain services require real-time prioritization by basic software processes. In modern cars, such services are plenty, and it is difficult to completely adopt SOA.
In the study of software architecture, these two challenges need to be appropriately examined. However, these challenges seem to be limited by two kinds of trade-offs: the first is the trade-off between reuse and complexity, and the second is the trade-off between performance and complexity. So far, the road forward seems quite blurry.
In this current situation, it is unclear how to distinguish incidental complexity, as such a distinction depends on the characteristics of the product – for example, certain services may need to be placed in the central ECU based on performance requirements or some services may need to be coupled (become more complex) based on reusability needs. How much decoupling to sacrifice for performance or reusability is difficult to quantify.
Complexity of Software Variants
Software variants introduce a third major dimension of complexity. It is noteworthy that the same software has hundreds of different variants to adjust to different terrains, temperatures, altitudes, emissions regulations, cultural preferences, and other factors. Variant models provide one of the biggest competitive advantages to high-end automotive manufacturers, allowing them to meet the demands of different market segments.
However, at the same time, they have become one of the most influential sources of complexity. Variants are not parts or components of the software but the entire software, with slightly different ranges of variable values and compiled sets of code. This means that there is a software superset that has produced a multivariate world of software, each with slightly different properties.
As variants appear, the complexity of code, architecture, requirements, and testing also increases. Variants blur the consistency of code with requirements and testing. Variants make software compliant with ISO 26262 and ASPICE, making continuous integration a semi-complete paradigm.# Variants of Large ECU Software
Figure 1 shows an example of the variant scalability of a large ECU software. From a business perspective, there are four variant points, namely the model, engine type, emission region, and drive type. Each variant point has several business variables. The small number of business variants on the left side turns into 114 software variants on the right side of the figure. It is crucial to note that the linear addition of business variables results in an exponential increase in software variables.
One progress in dealing with variants is the development of software product lines. Managing software product lines undoubtedly reduces software complexity as they aid in strict planning and reuse of software to meet various market demands. Otherwise, developing separate software development branches based on market demands would lead to a codebase that grows exponentially.
However, this does not necessarily mean that software complexity becomes as small as when it only has one variant. In fact, increasing variants trigger the creation of more complex codes, regardless of how well-designed the product line is. A tricky fact is that the added variants generate essential complexity in software since implementing these variants requires a certain amount of software.
Tesla and Apple have adopted a radical approach to variant models. They reduce variables to achieve better quality and development flexibility.
Complexity of Requirements
The safety, reliability, and performance of automobile software are crucial and require strict functional design before implementation. This design comes first from meticulous discussions among system designers, using natural language texts and diagrams as representations. These are software requirements specifications.
Like source code, software requirements tend to become complex. Complex conditions and state machines are typical sources of complexity. The rest of the complexity is incidental, caused by the inappropriate use of language. To reduce complexity, standardized patterns for writing simple requirements can be used, adopting language structures that lower complexity, and so on.
One key challenge in improving these techniques is that the natural form of language is highly variable, which hinders the creation of clear rule sets for developing simple requirements. When this challenge is addressed, a more problematic challenge exists in the overall requirements.
Statistically, the functionality requirements across the entire Volvo software superset are over 100,000. These functionality requirements are further broken down into multiple design requirements.
Such a vast number of requirements should be continuously consistent with source codes and testing to maintain traceability. Otherwise, it becomes daunting to handle respective source files and testing for upcoming defects and change requests. This is especially challenging if defects appear several years into production.When the source code undergoes changes, the corresponding requirements may be missed, leading to a discrepancy in knowledge that confuses software practitioners. To complicate matters further, every source function variable must have a corresponding requirement variable.
While source code variables can be handled by the code’s internal preprocessor and requirement variables by a requirement management system, the tricky problem is how to maintain traceability between source function variables and requirement variables.
Summary
Although complexity manifests itself in different forms in these four domains and requires different measurement methods, it is always necessary to clearly distinguish essential complexity from accidental complexity.
In some cases, this distinction seems clearer; for example, unused variables should be eliminated, or deeply nested code refactored. In other cases, this distinction is more like an optimization problem; for example, understanding the best trade-off between performance and modularity.
Furthermore, there are also tooling issues that can introduce unexpected complexity – for example, developing a system that separates code and requirements. If car companies want to develop increasingly complex cars while maintaining current development speeds, they should be more open to research communities and place greater emphasis on complexity management research commitments.
On the other hand, the research community should make more serious efforts to create methods that can truly help practitioners reduce complexity in an orderly manner.
This article is a translation by ChatGPT of a Chinese report from 42HOW. If you have any questions about it, please email bd@42how.com.