Why Automotive Software Development Needs a Toolchain

"Software-defined vehicles" has become an industry consensus. For automobiles, software has become so critical that delivering high-quality, user-loved software in a short timeframe is paramount. The standard development model in the automotive industry is the V-model, represented primarily by ASPICE and ISO 26262. This model has been used in automotive software development for nearly 20 years. China's new EV makers only started around 2014.

One striking observation: software iteration speed has always been a competitive advantage for new EV makers like NIO, XPeng, and Li Auto. Even after NIO delivers vehicles to owners, it can still ship a minor update every month and a major update every quarter. These advantages are powered by software development toolchains, including CICD (Continuous Integration, Continuous Delivery, Continuous Deployment), OTA, and a series of related technologies.

This is why automotive software needs a development toolchain. In Germany, the birthplace of ASPICE, consulting firms like Knüvener Mackert and KUGLER MAAG CIE are actively discussing the integration of ASPICE and Agile, and pushing for a unified standard. Whether a fused standard will emerge in the next few years remains to be seen.

What Kind of Toolchain Is Not Suitable?

Automotive software's requirements for development efficiency are gradually increasing, but before the rise of new EV makers, toolchain design did not prioritize efficiency. Everyone was accustomed to a 3-5 year vehicle development cycle, accustomed to suppliers handling software development, and accustomed to software development following the V-model exclusively. But as the automotive industry gradually embraces Agile thinking, more and more automotive software companies are considering software products not originally designed for the automotive industry—products with strong Agile development philosophies, such as Jira, Ones, and Pingcode.

So what kind of toolchain does the automotive industry actually want? To answer that, we first need to understand what kind of toolchain the automotive industry does not want. Based on my work experience, I've summarized the following points.

First, tools designed solely to meet standards rather than to make engineers' jobs easier.

If a tool doesn't consider user-friendliness in its design, no matter how prestigious the standard it satisfies, it has little practical value. For example, overly complex permission settings, where users without permission receive no notification and have no way to request access, leaving them passively subject to permission configurations.

We've observed a pattern: some automotive software teams purchase tools for ASPICE or functional safety certification, hoping to build their R&D process around the standard and achieve alignment. Their intention is sound, and they pass the certification—but afterward, they find the tool isn't efficient. They try to configure it for better efficiency, but since the tool itself enforces a heavy process tied strictly to the standard, any deviation from the standard workflow becomes a constraint. As a result, they end up splitting processes across multiple tools, creating a Frankenstein toolchain. This violates the second lesson below.

Second, cobbled together from too many tools, feeling like you're using a dozen different systems.

To meet ASPICE standards, you need at least 16 domains of work, including requirements analysis, architectural design, detailed design, test cases, and more. I've seen teams use Redmine for issue tracking, another tool (like DOORS) for requirements management, and Excel for offline test case management—all for various reasons.

Building a toolchain requires a holistic perspective. It's not about satisfying individual functions first and then assembling all the tools. You need to consider both whether the tools can integrate and how usable the integrated experience is. Even if you buy top-tier tools that are best-in-class in their respective domains, if they don't integrate well, engineers logging in feel like they're using completely different tools. The result: every tool has a high learning curve, you pay a lot in license fees, but the user experience is severely degraded.

Let me give an example. At a previous company, we used Jira for requirements, task management, and bug management. Initially, with fast development velocity, test management was nearly unrecorded—relying purely on engineers' experience. Later, we gradually moved to Excel for offline management. Then when test case volume grew too large, we switched to the open-source tool TestLink.

But TestLink had virtually no aesthetic design—it existed purely for functionality. We spent significant effort integrating TestLink with Jira, but the user experience wasn't great. For example, when a test case in TestLink passed or failed, that result couldn't feed back to the corresponding requirement in Jira, and you couldn't create a bug from the test case side. The traceability chain from requirement → test case → bug was awkward to build, and ultimately we couldn't generate a requirement coverage report.

Third, excessive use of offline tools.

In my previous article, I mentioned teams using Word to implement traceability. Many readers pushed back, saying ASPICE doesn't mandate Word for traceability. I agree. ASPICE never tells readers what tools to use—it only states requirements, never prescribes solutions. A major drawback of offline tools is that they can't serve as real-time team collaboration tools; when changes happen, they can't immediately notify the rest of the team.

Some teams say, "We can put Word and Excel on a shared drive so everyone can edit." But then you have to consider that multiple people can't edit simultaneously, which hurts editing efficiency. Some teams switch to SVN to solve the concurrent editing problem, but with SVN, no one can see files in real-time—you have to open or download them. When too many files accumulate, the entire experience degrades. Moreover, SVN's workflow isn't intuitive, and it has a high learning curve for non-developers.

Fourth, steep learning curves, poor design, requiring repeated training.

Here's a real example: a foreign company specializing in automotive R&D management software also offers SaaS registration. A new domestic customer asked, "Can we sign up for a trial?" The sales rep replied, "Yes, but you probably won't know how to use it—we'll need at least a month of training before you can actually use it."

If a tool requires a month of pre-sales training before it's usable, the tool's design itself is flawed. It means the learning curve is unreasonably steep, or the UI design violates human intuition. You've never heard of WeChat requiring a month of training to use. Feishu, the recently popular office tool, is usable within a day, and a team can work fluidly with it within a week.

Fifth, lacking online training resources, problems only solvable by the vendor.

This one I've experienced firsthand. The company that does this best is Australia's Atlassian. Many people know it from Jira. As an excellent Agile project management tool, Jira has a wide user base in China, and many people are impressed by its powerful features and ecosystem. Anytime you have a Jira question, searching keywords on any search engine yields countless videos, forum posts, and answers.

In contrast, there's another automotive industry R&D management tool—search for it online, whether inside or outside China, on any video platform, and you'll find very few tutorial videos. If you encounter a problem, you can only rely on team members who've already gone through the pain. Or you can reach out to the vendor, but the vendor is overseas, with only sales agents in China. The entire software experience becomes particularly poor.

The Ideal Automotive Industry Toolchain

So what kind of toolchain does the automotive industry actually want? Based on our own product design philosophy, I've summarized some lessons for reference.

First, engineers can meet ASPICE standards without tedious processes, while working efficiently.

When talking about efficiency in software development, Agile always comes up. Whether Agile should be introduced into the automotive industry is still debated, but no one can deny that Agile has unique advantages in development efficiency. Therefore, an automotive industry toolchain must at least reserve entry points for Agile development.

ASPICE's standard is complex—over 100 pages. What exactly needs to be satisfied? I've summarized a few points that I personally found particularly challenging in previous work.

Traceability. Traceability means being able to trace from requirements → architecture → detailed design → all corresponding test cases. At the same time, traceability must be operational. As in my previous example, using Word and Excel, traceability exists but engineers are exhausted. The more complex the project, the harder it gets exponentially. Gradually, engineers will stop actively maintaining traceability.

Document compliance. Document compliance means having test plan documents, test execution records, requirements analysis documents, architectural analysis documents, and so on. This means the tool must not only support Agile development (breaking all tasks into trackable items) but also support document-style reading, and be able to export directly to documents when needed.

Baseline management. I believe this is especially necessary in the automotive industry, and ASPICE explicitly mentions the importance of baseline management. This isn't as valued in the internet industry. The automotive supply chain is long, involves many suppliers, and is particularly cautious about changes—because a change might mean re-opening molds, at enormous cost. Baseline management and change review are therefore typically paired. Once a team establishes a baseline, they develop based on that baseline for a period of time. If the baseline itself changes, the entire team needs to be notified conveniently. Without that, the entire development and testing process becomes obstructed, ultimately resulting in a product that doesn't match the requirements.

Change review. Since changes affect the entire upstream and downstream chain and all partners, automotive industry change reviews are typically conducted collectively by a change control board. Only after approval can changes be formally added to the backlog for subsequent development.

Speaking of change review: first, it requires multi-person review, and second, it needs review records. Many teams conduct this process offline, while requirements, development tasks, and test cases are usually online. Since changes directly affect requirements, tasks, and test cases, this creates an online-offline inconsistency—tracing from online to offline and back again has poor operability.

Online test management. Generally, test systems are established relatively late. Many teams start with no test cases at all, relying purely on engineers' experience for ad-hoc manual testing. Test case management gradually matures as development progresses, eventually achieving test automation. During this maturation, many teams still habitually use Excel for test case management. This creates a problem: if requirements, development tasks, and bugs are already tracked online, but test cases are offline, then as online requirements and tasks iterate with requirement changes, test cases must also iterate—sometimes even saving different versions of test cases. The complexity of offline management increases dramatically. Another difficulty with offline test case management is producing test reports. Test execution reports might be fine, but reports on bug backlog, bug status distribution, requirement coverage, and test case coverage are extremely difficult to produce.

Second, use a one-stop tool, or at least a one-stop user experience.

The ideal scenario is executing all processes in a single tool: system requirements analysis, system architecture design, software requirements analysis, software architecture design, detailed design, code management, CICD, test management, project management, quality management, supplier management, issue management, change management, and more.

Some tools claim to be full-lifecycle solutions for automotive software development—which I believe is false advertising. In code management, you can't avoid Git or SVN. If even those tools don't claim to offer full-lifecycle solutions, no other tool can either. So sometimes we have to integrate several tools to build an ASPICE-compliant toolchain. But we must remember: the more tools you introduce, the higher the integration cost, the higher the learning cost for engineers, and the worse the user experience; for the company, it means higher costs and lower human efficiency. So use as few tools as possible. If multiple tools are truly needed, at least keep the user experience as consistent as possible.

Third, a gentle learning curve, abundant online learning resources and communication channels.

This point might not be valued enough in the automotive industry. Historically, even though cars are a B2C product, they're sold through 4S dealerships, which then sell to individual users. Dealerships aren't interested in customer feedback; their only focus is selling cars as quickly as possible to reduce inventory. This tendency seems to have transferred to automotive software R&D management.

Although R&D management tools are sold B2B, the end users are individual engineers. Therefore, tool vendors need to build good channels with end users. When engineers have any questions, they should be able to find abundant learning materials online, and there should be online communication channels.

Fourth, smoothly extendable to ISO 26262.

Generally, if you build a toolchain that meets ASPICE, there's a very high probability you'll later need functional safety support. If you then have to use a completely separate set of tools for functional safety, that adds even more tools. But ISO 26262 and ASPICE are very similar—many processes can directly reuse ASPICE practices, differing only in functional safety rating specifics.