The Chinese advantage

The fact that Chinese manufacturers have been able to design, test, and launch new vehicles much faster than European incumbents has produced a lot of hand-wringing and speculation on what exactly the Chinese are doing better. There are a lot of explanations ranging from regulatory, economic and technical advantages. 

When it comes to the technical, many commentators point at China's adoption of the “software defined vehicle” (SDV) and their pioneering work in ADAS (Advanced driver-assistance systems). 

But there’s another, more overlooked advantage. 

Is their R&D velocity so high because they can validate requirements faster? After all, R&D velocity depends on how fast you can test and how fast you can learn from the results of testing.

Even if you now call your car “an iphone on wheels”, it’s still fundamentally a piece of hardware (or rather, a cluster of hardware components) that needs to withstand a high degree of wear and tear. Automotive R&D therefore depends on testing physical systems: on proving grounds, on test benches, in climate chambers, and in laboratories. It also depends on analysis capacity, meaning how fast you can turn raw test results into engineering conclusions. 

New hardware components are built to meet specific design requirements, and engineers need to collect data points that validate whether those requirements are met. This is done through testing and data acquisition.

Take a car’s internal network for example. Engineers need to ensure that electronic control units (ECUs) communicate reliably by measuring properties such as signal latency, bus utilization, jitter and so on. That data is all captured using a data logger then evaluated in the lab, using a very specific set of software applications. 

When a component fails a requirement, engineers must analyse the recorded signals, find hidden patterns, and often compare the current test against historical test campaigns to understand what changed. 

Thus you can see how these two factors (testing capacity and analysis capability) are intertwined. It doesn't do you much good to run twenty tests per day if you need a week to evaluate the results of each test. You need to make sure that the feedback loop between the physical test and the data analysis runs as fast as possible.  

To some extent you can also substitute physical testing with simulation. 

Indeed, the Chinese rely more heavily on simulation than OEMs in other markets. According to analysis by McKinsey, Chinese automotive OEMs run 65 percent of their testing as simulation and virtual prototypes, compared with 40 to 50 percent in other regions, and three quarters of those tests are automated, compared with about two thirds elsewhere. But even if you rely heavily on simulation, you still have to validate your models against real physical test data to ensure they remain accurate (the so-called “sim-to-real” comparison).

Which leads us back to the question: what are the Chinese doing that allows them to shorten these feedback loops? 

To answer his question, we need to look at the two key phases of the test validation workflow.

1. Primary Analysis: follows directly after data acquisition. This means analyzing one specific car, on one specific day, running one specific test sequence. 
2. Secondary Analysis: Evaluates data from many test campaigns. Engineers look at how a physical component and its corresponding model (used in simulations) performs against historical benchmarks and regulatory requirements.

Let’s look at the software ecosystem for primary analysis first. 

The Vector empire

In the European market, one vendor dominates the primary analysis phase: Vector Informatik. Vector sells both the acquisition hardware (interface boxes such as the VN series and GL data loggers) and the desktop software used to analyse the recorded data (CANalyzer, CANoe, CANape, vSignalyzer). The German automotive industry has a long history and is deeply interconnected. Vector has been embedded in it for decades. Manufacturers standardise their toolchains on Vector, and then require their suppliers to deliver test results in Vector-compatible formats, which extends the dependence through the whole supply chain.

This monopoly has impacted R&D velocity in several ways.

The first problem is the licensing model, (which is generally per seat) and the pricing. A single seat of CANoe or CANape, bundled with a Vector interface box, routinely costs between USD 5,000 and USD 12,000 or more, with extra fees for protocols such as Automotive Ethernet, LIN, or FlexRay, and recurring annual maintenance. Because of these prices, manufacturers buy a small shared pool of licences instead of one licence per engineer. 

Engineers then take turns to open log files. That means fewer engineers can do analysis in parallel. The dedicated post-processing tool, vSignalyzer, still costs thousands of dollars per licence. In practice, engineers often pay for a sophisticated product suite but mostly use it as a very expensive log viewer.

It’s also very difficult to see how licenses are being consumed. Many of these licences are node-locked, meaning they are tied to one machine or one user, without a central licence server and without usage reporting. The manager who pays for the licences therefore cannot see whether they are actually used. When an engineer requests an additional seat, the manager has no data to evaluate the request, and no way to find idle licences that could be reassigned instead.

The pricing model also changes over time, so customers must repeatedly re-plan budgets around a moving licensing structure. The result is that the licence pool cannot be managed as a normal, measurable cost, and this affects the buyer of the software as directly as the seat shortage affects the engineer.

The second problem is more technical: Vector still relies on a proprietary scripting language (CAPL). Although Vector recently tried to include better Python support, automated analysis scripts are mostly still written in CAPL, a very niche, domain-specific language. This means that engineers need to be trained in it which is not necessarily the case with Python. There is far less educational material available online for CAPL than for Python, and years of accumulated CAPL script libraries can only run inside licensed Vector applications. This again makes it difficult to test and update old analysis scripts.

China's domestic imperative

Initially, Chinese manufacturers relied exclusively on Vector tools too. Many of them still do. They are known to be the best in the business. 

But over the past several years, the many players in the domestic Chinese market have replaced large parts of the Vector toolchain with local alternatives. The Chinese government has encouraged this substitution as part of a broader policy of reducing dependence on foreign software supply chains. This policy, called the “Xinchuang Policy” specifically stipulates that “systems involved in production and R&D” are subject to replacement, with a flexible timeline based on domestic capabilities. China aims to achieve technological self-reliance by replacing foreign technology in government and critical sectors by 2027.

There are a few examples of these home-grown Vector replacements (e.g. HiRain INTEWORK-VBA and ZLG ZCANPro) but one of the most popular is Tosun TSMaster which is designed to replace CANoe, CANalyzer, and CANape.

The most important product difference is that test and analysis scripts are written in standard Python or C instead of CAPL. It also runs on third-party hardware, including Vector, Kvaser, PEAK, and ZLG interfaces, so laboratories are not forced to buy proprietary interface boxes.

This, of course, helps to accelerate R&D. When licenses are cheap or free, and when scripts are written in Python, every engineer can analyse data in parallel rather than waiting for their turn. Recently hired graduates are more likely to arrive with a fundamental knowledge of the scripting language, and AI coding assistants inherently understand Python much better than any proprietary language. This means that the same pool of engineers can effectively commit more work hours to primary analysis. 

What can European OEMs and Vendors take away from these examples

First, the European market needs to remove the commercial roadblocks that impede primary analysis. That means moving beyond the seat-licence model for primary analysis tooling.

The Chinese “domestic substitution” wave shows that per-seat pricing on analysis tools directly reduces a customer's engineering throughput, and that prompts customers to switch vendors. If you must charge for analysis, price by consumption or by site, so that every engineer can analyse data in parallel. Consumption pricing also makes usage more measurable. 

With node-locked seats, the buyer cannot see who uses what, which makes it more difficult to decide how many licences to purchase. With consumption pricing, the invoice itself has to include a breakdown of usage. This makes life easier for two different stakeholders: the engineer who needs to do analysis, and the manager who needs cost control.

Secondly, proprietary formats and domain specific languages slow everyone down.

Europe has known this for a long time, hence the birth of ASAM MDF4 in the first place, but the tooling around it has remained proprietary. Luckily that is starting to change with newer offerings (such as Peak Solution and our own Quix platform) that are built on open-source tech stacks. Modern tools also need to support general-purpose languages such as Python as first-class citizens. 

CAPL-style proprietary languages are a training cost and a lock-in mechanism that the market is abandoning. New engineering graduates are more likely to know Python, and there are plenty of open-source libraries for working with ASAM MDF4 files and raw CAN data. For example, CSS Electronics, a Danish manufacturer of CAN bus data loggers and interface modules provides many free analysis tools written in Python.  

In China, the gradual replacement of expensive proprietary analysis tools with cheap and open source tools is a small piece of a larger plan. China treats every foreign tool it depends on as a cost to remove. The government calls this “Keji zili ziqiang” (科技自立自强) which translates to "Science and technology self-reliance and self-improvement."

If your industry depends on a technology or framework that is maintained by a foreign vendor, you are vulnerable on multiple fronts: the price, the roadmap, and the political relationship between two governments.

When it comes to proprietary technologies, Chinese companies could not beat US and European companies who have been iterating and evolving those technologies for decades. So Chinese companies took the opposite approach in two ways. When the software they depended on was closed and foreign, they built their own version and gave it away for free or made the licensing model more accessible. When the software was already open-source, they often took over its maintenance instead or created new open-source derivatives

The second move is an interesting one, because investing human capital in open-source maintenance is a form of control. The engineers who maintain a project decide which features get built and which features are deprioritized. They also have a huge influence on the ecosystem of integrations around that product. For example, consider the relationship between Databricks and Apache Spark (a large-scale data processing and analytics framework). Databricks have many Apache Spark maintainers on their payroll. About 43 percent of Spark's contributors work for Databricks, and no other company comes close. Databricks also gives away Delta Lake, a storage format designed to work well with Spark. Instead, they earn their money from the infrastructure used to run these technologies. 

Thus, European OEMs and vendors need to collectively support the development of open source technologies that support test data analysis. Don't just leave it to individuals maintainers or small ad-hoc communities. 

In the next article, we’ll look more at how this open-source strategy plays out in secondary analysis and the processing of test data at scale.