Let’s talk about four thoughts on automotive software development

What is a “software-defined car”? Everyone may have their own unique opinion, but there is no doubt that software is beginning to dominate automotive electronics.

In the early 1980s , the electronic system of a car only had tens of thousands of lines of code . Today, the electronic system of a high-end luxury car has tens of millions of lines of code . In the future, the electronic system of an intelligent connected car may have hundreds of millions of lines of code. , this phenomenon illustrates the inevitable correlation trend between software development and automotive innovation.

Automotive functions were initially realized mechanically and later electronically. In the future, more functions may be realized by software without changing the hardware. According to Forbes , it is estimated that 60% of the value of self-driving cars will come from software in the future, while today automotive software only accounts for 10% of the value .

"Software-defined cars" will make cars like mobile phones. As long as it is a smartphone, we can easily add different applications on this basis to realize different functions, and can update and upgrade the software online. However, cars and mobile phones are fundamentally different in use. The quality of mobile phones only affects communication and entertainment, while the quality of cars is related to the safety of people's lives and property. Therefore, how to ensure the quality of car software in the context of "software-defined cars" and how to adapt to the new situation? Rapid software development of functions and new platforms is an issue that requires in-depth consideration in current automotive software development.

Thoughts on rapidly changing software architecture

With the development of intelligent connected cars and the evolution of automotive electronic and electrical architecture, the vehicle electronic and electrical architecture has gradually transformed from a distributed architecture to a centralized control architecture. Multiple traditional ECU functions are concentrated on one domain controller, and even across The concept of domain integration. In this case, the requirements for the software in a domain controller are getting higher and higher, and the scale of the software is becoming more and more complex. Therefore, a software architecture with strong compatibility, decoupling , and scalability is required. It's important.

"Decoupling" is divided into two levels, one is the decoupling between software and hardware, and the other is the decoupling between internal modules of the software architecture.

Software and hardware decoupling means that the software architecture design considers cross-hardware target factors, treats the hardware as a black box, builds a universal software framework, abstracts the interface devices, and is compatible with different interfaces. In addition, the software architecture should be a layered and modular design, decoupling the modules and standardizing the interfaces. Different algorithms and software modules can be loaded on the software framework.

In order to cope with the rapid changes in current automotive software requirements, software architecture design should be an act of "planting trees" rather than "planting grass." In other words, the overall software must be built into a big tree, and branches and leaves can be continuously expanded or deleted without affecting the main trunk. Instead, a software system cannot be designed just to plant a piece of grass.

In order to achieve scalability goals, software architecture design must have an overall view and ensure the compatibility design of the software architecture. When designing software architecture, it is necessary to fully analyze data flow and control flow, and software resource occupancy. Software architecture is like the blood vessels and nerve networks of the human body, connecting various limbs and transmitting information and nutrients. Only by ensuring the correct implementation of these data flows and control flows can a healthy architecture be achieved.

In short, the software architecture design must adhere to one goal: the software is complex, the architecture is simple, and a simple and clear architecture is used to carry the ever-expanding software modules to meet the rapidly changing needs.

2

Thoughts on Software Quality Challenges and Guarantees

With the development of intelligent connected cars, automotive software development is facing huge challenges. The emergence of new functions and new requirements does not have too much experience to follow, resulting in continuous iteration of software requirements; the software architecture needs to support the changing requirements; the complex and large amount of code in the software may introduce more defects; complex scenario combinations and huge code amount Making it difficult to ensure the adequacy of test verification...

Faced with these challenges, how should the quality of automotive software be ensured? The particularity of software is that its quality cannot be quantified. Quality defects are not only introduced through technology, but may also be introduced through irregularities in the development process. These risks introduced through the process are invisible, intangible and unpredictable. Therefore, ensuring the quality of automotive software is summarized It can be divided into three aspects: process assurance, method assurance and tool assurance .

First of all, a complete software quality management system needs to be established for the process, such as ASPICE-based software development process, quality management process, configuration management process, change management process, etc. These are directly related to the quality of the software, and the software development process needs to follow these qualities. management requirements. A perfect process can also ensure the stability of requirements. For example, when establishing requirements, sufficient research and confirmation are required, and requirements must be reviewed by multiple parties, which can reduce unreasonable changes in requirements to a certain extent; on the other hand, the requirements must be well prepared in terms of processes. Baseline management and change management, identify the scope of impact of demand changes, and formulate relevant response measures based on the scope of impact.

In terms of methods, it mainly refers to technical methods and methodology. For example: when formulating requirements, HAZOP analysis can be used to supplement security requirements, identify whether the requirements are comprehensive, and ensure the consistency of software development and requirements through two-way traceability of requirements; in the software architecture design phase, hierarchical, modular design and high-level The cohesive and low-coupling method reduces software quality risks, and verifies the integrity of the architecture through data flow analysis and control flow analysis; follows the method requirements of coding specifications during the software coding phase; ensures test coverage during testing, and adopts performance testing, Avalanche testing and fault insertion testing are used to fully verify software functions and performance. There are many methods, it is impossible to list them all, and they need to be fully explored during the software development process.

In addition, tools are also a very important aspect of software quality assurance. A complete tool chain can make software development work more effective with half the effort. For example, automated testing tools, code and detailed document conversion tools, with these tools, you can quickly respond to the workload caused by changes in requirements. From a functional safety perspective, software tools themselves may introduce systemic failure problems, so safe and reliable tools are the basis for ensuring software quality.

3

Thoughts on agile development

Although agile development has become a hot topic nowadays, agile may be a good method that can verify the software in advance, but agile is not a panacea.

First of all, current problems such as rapid changes in software development requirements and tight progress cannot be solved simply by agile development. The use of agile methods needs to be matched with appropriate projects. For example, it can be interspersed with the development process of some small software modules, and It is necessary to cooperate with certain automated testing methods, otherwise the workload of test verification will increase dramatically.

The author personally does not recommend agile as the main method for the development of complex software systems. The more complex the software, the more overall planning is required. However, agile methods can be appropriately used at the specific detailed design and implementation levels.

The automotive industry is different from some Internet development ideas. In the early stage, there will still be relatively clear needs, including functions and interfaces, which cannot be added or removed completely at will. In the process of Internet product development, inspiration may suddenly occur, and a lot of creativity will be added. content, thereby adding new requirements. This demand iteration is like a snowball, with new elements constantly added in all aspects and constantly expanded and improved. Therefore, applying agile development may be more suitable for some Internet products. In the automotive field, even in the current field of intelligent connected cars, the demand framework is relatively clear and stable. This process is more like building a house. The overall foundation should be built first, and then high-rise buildings should be built layer by layer to ensure quality. Instead of building a little bit of each floor quickly, the foundation will be verified by the completed building. Therefore, as to whether to adopt agile development, you need to first identify whether this is a snowballing project or a house-building project .

Although intelligent connected cars have some integration elements of automobiles and ICT, overall they are still more focused on “building a house”. Agile is suitable for "unknown unknown" exploratory projects, while smart car software openness is a "known unknown" exploratory project, and there are still some differences.

And from the perspective of software quality and functional safety, the method of streamlining processes and documents through full communication during the agile development process may introduce unassessable systemic failures. Therefore, the development of complex software for new functions and new platforms in the automotive industry must at least require the architecture. Before the stage, I personally recommend using waterfall development. Agile development can be appropriately considered during the detailed design and post-baseline requirements iteration process.

4

Thoughts on software testing

In the face of increasingly expanding and complex automotive software systems, the traditional testing human sea tactic may be useful at certain times, but it is not efficient enough. Software testing requires "fusion", that is, for complex software systems, attention should be paid to the integration of manual testing and automated testing. Using automation for continuous integration and delivery can achieve twice the result with half the effort, but automated testing also requires certain testers to write scripts and manual verification. At present, automated testing cannot completely replace people. For example, there are some automated tests for unit tests. The coverage rate of tools can reach 100%, but from the perspective of software quality, simply using this tool for testing is not enough, because whether the logic of the software is correct still needs to be verified by humans. However, for complex software systems with a huge amount of code, it is not feasible to rely solely on the human sea tactic, which is a waste of human resources and inefficient. Therefore, it may be more correct and efficient to use automated testing as the mainstay and manual-assisted "fusion" testing. way.