The VW-Horizon Partnership Is a Typical Case of Smart Connected Vehicle Software Development

First, a joint venture formed by two completely different companies, each bringing core technology

Most likely, Volkswagen will set up a joint venture with Horizon Robotics through CARIAD's Chinese subsidiary. Horizon is highly experienced in chips and autonomous driving algorithms—its Journey series chips are already deployed at scale across many OEMs. For VW, CARIAD is like what Z-One is for SAIC: the "darling" of the global software transformation strategy. CARIAD's headquarters is in Germany, and its goal is to be a key pillar of VW's software-defined vehicle transformation, including operating systems, next-gen E/E architecture, autonomous driving, OTA, and more.

Although CARIAD's Chinese subsidiary was only established in April this year, CARIAD HQ was founded in early 2020. German CARIAD has accumulated experience since then, and China CARIAD builds on that foundation. Their slogan is "R&D in China, innovation for China; R&D in China, innovation for the world."

Overall, both VW CARIAD and Horizon have their own core technologies that the other doesn't possess.

Second, the JV's products serve mainly one company, but its project management and product development experience has high value for other companies

Clearly, this joint venture between VW and Horizon—whether developing operating systems, L4-adapted autonomous driving chips, or autonomous driving algorithms—will primarily serve VW's global vehicle models. It's unlikely that such a product or solution will be sold to other companies. But for partner Horizon, developing products with VW creates a highly reusable product that can be used across other brands' models and products. The cross-national team's project management and product development experience will be valuable for Horizon when working with other OEMs, like Ford, GM, or Japanese companies.

Given this, the partnership has different goals for each side. VW wants the most advanced products for itself first, and hopes these technologies will never be learned or used by competitors. Horizon's goals may differ. This divergence is one of the hardest parts of running a joint venture. Most current smart connected vehicle software teams face similar challenges—like SAIC and Alibaba's Banma, or Huawei and BAIC's partnership (even without a formal JV, the collaboration logic and challenges are the same).

Third, one side has deeply entrenched OEM thinking, while the other is an emerging software supplier

What is OEM thinking? For the side with OEM thinking, they only need to define requirements—often very rough requirements—and hand them to the supplier to deliver turnkey. During turnkey delivery, to ensure product quality, beyond final product acceptance, and based on German quality control philosophy, quality control must extend upstream, meaning they also control the software development process. Traditional OEM thinking is best exemplified by ASPICE. The OEM needs to deeply inspect the JV's R&D process: requirements analysis, whether requirements were reviewed, whether corresponding architecture design exists, whether test cases exist and were reviewed, whether every function's unit test coverage exists, whether a quality management process exists. Everything must be traceable, with paper records.

What's the fundamental logic behind this OEM thinking? The buyer isn't personally executing the entire process, can't accept black-box delivery, so needs clear visibility into the execution process for quality control. The supplier must provide process documents or deliverable documents at any time. This requires highly documented processes. But for emerging software suppliers, their mindset and goal are to efficiently develop quality products. Previously they developed within their own teams, so the whole team is very clear about the development process and deliverables—they don't need to document everything. But now facing a JV, VW's participation in execution is definitely less than Horizon's, so it naturally has needs to review historical documents. This is also a conflict between the two companies. How to resolve conflicts is key to the JV's maximum efficiency and VW's rapid software transformation strategy.

Fourth, cross-timezone, international R&D teams

This type of team is common in China's smart connected vehicle software projects. NIO has software teams in China, Germany, and the US; so do Geely, XPeng, and others. Facing an international R&D team, there's a problem that must be confronted: distance and time zones. Often, JVs squeeze the Chinese team's time—Chinese team members work overtime until midnight to accommodate international teams. This causes two problems: first, one-sided effort isn't sustainable. Over time, the Chinese team feels unfairly treated, hurting morale. Second, are cross-timezone meetings really necessary? If meeting content and materials can be communicated and resolved online, the frequency of cross-timezone meetings drops dramatically. While such meetings can't be completely eliminated—some scenarios genuinely require online discussion—they can be reasonably minimized.

Fifth, multiple vehicle projects in parallel

Predictably, such a JV develops products based on specific vehicle projects—like an in-vehicle operating system. But as it develops to a certain stage, it finds VW has more and more vehicle projects. Then it needs to apply this solution to different vehicle projects. Some teams simply copy the first vehicle project entirely and modify it. If there are more vehicle models, copy more backups.

VW has many models. This approach means every additional model requires an additional team—inefficient. Also, as vehicle projects increase, system documentation grows, documents become more redundant, and inconsistencies between documents increase. But 60% or more of documents across vehicle projects are extremely similar—similar but can't be deleted. So if a JV's multi-vehicle parallel project uses this model, efficiency gradually decreases as projects multiply. Moreover, each vehicle project's experience and product improvements can't effectively carry over to other vehicle projects.

What Kind of R&D Management Toolchain Is Needed?

First, the JV has maximum information access; both VW CARIAD and Horizon only access partial information

First, this JV will hire new people—they won't all be from VW or Horizon. These new hires are the JV's core engineers. Early on, VW and Horizon both provide project managers and development teams to work with the new team. As mentioned earlier, both companies have their own core technologies, and during joint development, neither side can accept disclosing all technical information to the other. VW wants products only for itself; Horizon hopes project experience can be applied to other collaborations. So it must be that the JV has maximum information access, while VW and Horizon only access partial information.

So the situation often is: the JV receives system requirements or software requirements from VW CARIAD, technical requirements and architecture design from Horizon, then develops within the JV—but both VW and Horizon only access partial info. This requires the R&D management system to receive inputs from both VW and Horizon in real-time, rather than through an intermediary. Both sides may not understand code-level details of subsequent development, but for parts both sides agree to share—like bugs related to a requirement—both can view them in real-time in the system. Even for product-level bugs, VW or Horizon can clarify or resolve them directly in the system. So this R&D management system needs interfaces for each party to freely input data, get real-time feedback, while also precisely restricting permissions—information they shouldn't see, they can't see.

If we use lean management analysis: in such a team, writing code and fixing bugs might not be the most time-consuming part. The most time-wasting is coordination and clarification between parties. So the R&D management system must first solve this problem.

Second, VW CARIAD should gradually abandon OEM thinking and become a key player in software development

This doesn't mean VW should completely become a software company. What does it mean? For a JV involving multiple stakeholders' interests, information should be disclosed as much as possible based on multi-party requirements. So VW shouldn't rigidly follow ASPICE requirements, demanding the JV provide entire development process deliverables and documents. If the JV can prove to VW that automated unit tests were done for all software modules—does VW still need to know which test code and test scripts relate to each of the 100 functions in those modules? Or if VW already participated in initial requirements design and review, does it still need the team to provide detailed review records for every subsequent review?

Software R&D processes are relatively fixed. Process confidentiality isn't highly sensitive—VW, Horizon, and the JV all understand them well. So does VW still need the JV to provide detailed explanations of every process step?

These requirements are traditional OEM thinking: unable to observe the supplier's daily work, but needing process control. But if VW CARIAD sees itself as a key player in software development, it will participate throughout requirements analysis, architecture design, test case reviews, and so on. Then it knows the entire process well. For example: whether unit tests covered modules, whether integration tests and functional tests followed, final product acceptance is fine. In this case, do we still need the JV to prepare lengthy documents proving process compliance?

So if CARIAD sees itself as an important part of software development and participates throughout, it knows the whole process and its quality is guaranteed. It can choose to abandon those traditional OEM top-down processes that require suppliers to provide various documents to prove their R&D process. Anyone who's done an ASPICE audit knows: for the same project, whether you need to pass ASPICE makes a huge time difference. Passing ASPICE often requires 2-3x more time cost, but quality doesn't improve qualitatively.

Third, tools should support real-time online collaboration, rather than sacrificing one side's time to accommodate the other

As mentioned above, this type of development team is necessarily a cross-timezone international R&D team. Although the Chinese team is mainly CARIAD China, we can foresee that CARIAD China will have very close ties with CARIAD Germany, and CARIAD Germany has close ties with VW Germany. So some projects will definitely involve the German side. If our R&D toolchain passes information by email, it might be: China sends an email at 9 AM about a problem's progress; by the time Germany reads it, it's already 3 PM in China. It's hard to guarantee the German side has the latest version. There are two ways to handle this: first, assume it's the latest—Germans make decisions and develop based on the info they got. If info updated in the meantime, they might make wrong decisions, and redoing it lowers team efficiency. Second, communicate with the Chinese team to confirm it's the latest. After Germans receive the info, they schedule a meeting with the Chinese team—but the Chinese team might already be past 6 PM, sacrificing their time to meet and explain.

Either way, it's decided subjectively by individuals, and everyone handles it differently, leading to inconsistent situations across projects. This causes two problems: either quality control is lax and errors slip through, or the Chinese team's time is constantly sacrificed, reducing efficiency and morale. So the R&D management toolchain needs to support both teams updating information on one platform and seeing each other's updates in real-time. More information flows online, and only the unavoidable remaining part goes to offline meetings.

Fourth, platform projects and vehicle projects in parallel; manage the platform's requirements pool well

As mentioned earlier, as the JV's business expands and vehicle models increase, from the very beginning you need a management plan for vehicle projects, filtering reusable requirements and architecture documents to build a platform-level requirements pool. For this requirements pool, corresponding architecture design, test cases, and bug experiences are all reusable. Future new projects can maximize reuse of previous project experience from the pool. After reuse, modifications are made on top. After modifications, review the new documents and consider whether they can be reused by the next project, or whether they enrich the platform—putting valuable information back into the requirements pool.

Git naturally supports this model: mainline and branches. The mainline is the platform project; branch projects pull from the mainline to modify code. After modifications succeed, parts of the branch that benefit the platform can be merged back.

But beyond code, a lot of content is also reusable: requirements analysis documents, architecture design documents, test cases, bug experiences. These reusable files need similar support in our R&D management platform.