“Leaving our fate in the hands of suppliers is terrifying.”
These words, uttered by Wang Qiyan in 2020, encapsulate a pivotal moment in Nio’s journey toward technological independence. At that time, Nio had been selling cars for over two years, but the vehicle networking system still faced numerous user complaints, to the extent warranting CEO William Li’s involvement. Li’s response was to issue a stern directive to Wang, who was in charge of the segment at the time: “This issue must be resolved!”
Upon reflection, Wang discovered that the root of the problem lay in the communication module, which was a black box testing solution purchased from a European supplier. Nio’s internal team could detect anomalies in the module but had difficulty pinpointing the exact vulnerabilities.
Ultimately, Li personally called the supplier’s CEO. Nio’s teams in China and the US had daily meetings with the supplier’s European team, and after extensive user data testing, they helped the supplier identify the root cause of the issue. “But if it had been our own code, we could have resolved it in two days.”
This experience solidified Nio’s determination to control the underlying technology of its vehicles.
Despite the controversy over significant investment, Nio has not wavered in prioritizing technology R&D. It’s an extensive endeavor comprising top-level smart applications, diving into smart driving chips and even the more fundamental full-vehicle operating system.
On July 27, Nio unveiled its full-vehicle operating system, SkyOS, during Nio IN 2024, its annual technology day event.
It’s not uncommon for car companies to explore operating systems, but these usually serve areas like smart driving and digital cockpits. In contrast, Nio’s self-developed SkyOS aims to manage the entire vehicle, including smart driving, vehicle control, vehicle networking, and digital cockpits. It’s quite comprehensive.
Nio has even delved into the underlying software for self-developed chips. “We provide a complete set of underlying software capabilities for the Shenji chip, including simulation, virtualization, operating system, middleware, and toolchain,” Wang said.
Building a full-vehicle OS is no small feat. The hardware managed by operating systems in phones and computers does not exceed ten components, while an intelligent vehicle has hundreds of electronic components, dramatically increasing hardware coordination needs and software complexity. By extension, the system requires high data throughput, low latency, safety, and stability.
SkyOS is the result of four years of dedicated effort by Wang and his team of over 300 people.
Specifically, SkyOS consists of a virtualization platform, four OS kernels, and numerous middleware toolchains. According to Wang, the virtualization platform at the lowest level integrates and reallocates resources, providing a shared resource pool for different types of applications.
Above the virtualization platform, the kernels cover smart driving, vehicle control, vehicle networking, and digital cockpits. For instance, the SkyOS-R kernel can deploy most smart driving functions, characterized by high performance and real-time capabilities.
In an interview with 36Kr, Wang shared the reasons why Nio has committed to developing a full-vehicle OS.
“Vehicles will become artificial intelligence-driven entities in the future,” Wang emphasized multiple times. At the Nio IN 2024 event, Li also affirmed the importance of AI, saying that a successful EV company must also be a successful AI company.
Wang believes that future vehicles will increasingly integrate smart features rather than just undergo individual digital upgrades. For example, Nio’s SkyRide chassis can keep champagne glasses stacked on the hood steady while driving over bumpy roads, demonstrating a typical cross-domain application. Achieving this function requires calling computing power from the smart driving chip platform.
As automotive architectures evolve from distributed to cross-domain integration, and then to central integration, the realization of smart EV functions will gradually be handed over to a few or even a single computing platform.
“So when a new electronic and electrical architecture is born, a corresponding OS is needed to support centralized central computing, high AI computing power, high throughput, and complex calls,” Wang said.
The next step for SkyOS is to support the implementation of Nio’s self-developed Shenji NX9031 chip, cockpit-driving integration, and AI-native applications within the car.
With large models, Wang feels that high computing power and memory will be needed on the vehicle end, and localized deployment of AI models will be a clear trend. “But we don’t want local resources to just run the models and exhaust the vehicle’s computing power resources. Therefore, resource optimization and precise use will be a long-term theme.”
The insights above were derived from an interview conducted by 36Kr with Wang. The following transcript is a translation of that interview and has been edited and consolidated for brevity and clarity.
36Kr: Currently, most automakers are developing systems for intelligent cockpits and smart driving at the application layer. What effects does Nio hope to achieve by developing a full-vehicle OS?
Wang Qiyan (WQ): First, with a full-vehicle OS, some intelligent functions that were previously impossible become achievable. For example, Nio’s SkyRide chassis integrates smart driving, chassis, gateway, cloud, mobile, communication, and data sharing, forming a highly complex system.
If each software stack exists independently without interconnection, high latency will make it impossible to respond in time or perform complex algorithms. By integrating the software platform, we can achieve more sophisticated functions.
Another dimension is that intelligent vehicles have been evolving for nearly a decade, and software product maintenance throughout the entire lifecycle is becoming a more prominent issue. Can we provide users with the latest experience throughout the entire lifecycle? For a car company with multiple brands, product lines, models, regions, and eventually millions of users, achieving this is highly challenging.
For example, a car has about 50–60 electronic control units (ECUs), each with different versions. The entire vehicle has hundreds of major functions and hundreds of minor functions. If a software update is required, the overall testing workload would be enormous. Therefore, we need a platform that can layer and decouple, maintaining software update efficiency while continuously launching new models. As the number of vehicles increases, the foundational capability of the system will become even more crucial.
36Kr: When mentioning operating systems, people think of Windows, Android, iOS. On what basis is Nio’s SkyOS developed? Are there any open-source components?
WQ: We will not rely on external vendors or partners because this capability may serve not only ourselves in the future but also other industry peers. This determined some of our decisions when designing the OS.
Our OS does not depend on any external elements. Most of it is designed and developed by our engineers. There is a small part that’s open-source, just like Android grows from the Linux kernel. We hope to achieve autonomy and control by leveraging some open-source projects and self-development.
36Kr: Is it fair to assume whether a company believes in intelligent vehicles or not depends on if it develops a full-vehicle OS?
WQ: You can say that. Everyone’s understanding of the form of intelligent EVs will determine how the technology progresses. We believe that future cars will be AI-driven entities, fully mobilizing the vehicle’s capabilities, so a base platform that integrates the vehicle with cloud and external environments is needed.
36Kr: As a pioneer, what are the major challenges in the development process? What technical hurdles exist?
WQ: When talking with some friends, they often mention the first problem they encounter: strategy. Deciding to undertake this requires enough determination and clear thinking, which might be the first hurdle. Then come design and supply chain requirements. Fortunately, William Li had the foresight and provided substantial support, so we bypassed the initial major difficulty and went straight into execution.
In terms of technical challenges, we need to proceed in stages. For example, in the “Nio Technology 2.0” (NT2.0) stage, we first tackled the most urgent areas to establish capabilities and then continuously optimized them. We may not cover everything, but we must meet specific needs. For instance, supporting high computing power, resource scheduling, communication latency, and reliability under the new architecture—we strive to achieve this with minimal resources and time.
36Kr: What are the boundaries of Nio’s full-vehicle OS development? Does it involve the underlying software of the chips?
WQ: Some chip manufacturers do indeed have restrictions on the underlying software. This depends on the company’s strategy. For example, for smart driving, we’re now using Nvidia’s chip, and we will also have our own Shenji chips later. We provide a complete set of underlying software capabilities for the Shenji chip, including simulation, virtualization, OS, middleware, and toolchain.
36Kr: What is the most direct value and experience SkyOS can bring to users?
WQ: For instance, the SkyRide chassis uses the computing power of the smart driving Orin chip. This is achieved through hardware virtualization, providing a shared resource pool for different types of applications—it’s a typical virtualization action. Additionally, our systematic bottom-level support ensures better safety and reliability, such as reducing autonomous emergency braking (AEB) time by 50%.
In NT3.0, we will have both Shenji and Orin chip configurations. We have a complete SkyOS strategy for Shenji. Nvidia indeed has requirements for the underlying software—it doesn’t mean it can’t run, but there are some limitations.
36Kr: Will there be differences in OS needs between Xpeng Motors, Li Auto, and Nio?
WQ: The new players are generally consistent with their product planning, but may differ in terms of path, strategy, and pace. We take a longer-term approach, not something that can be completed in six months. Maintenance costs and efficiency issues for many models will gradually become apparent. We foresaw this in 2020.
36Kr: HarmonyOS is also used in cars. How does it differ from Nio’s SkyOS?
WQ: HarmonyOS mainly targets the cockpit domain, whereas we considered the entire vehicle’s integration needs from the earliest design stages. As an original equipment manufacturer (OEM), we have inherent advantages.
Through our first-generation platform and early development process, we accumulated extensive experience and learned valuable lessons. We understand the OS support required for full lifecycle maintenance, which goes beyond just covering the cockpit.
36Kr: Has the internal development approach changed after the full-vehicle OS was introduced?
WQ: We’ve indeed entered a stage of rapid growth with multiple brands and models. If we stuck to our old rhythm, we couldn’t have advanced so many models simultaneously. With a standardized platform, we provide standard interfaces, enabling different hardware configurations to develop concurrently, boasting a module sharing rate of over 90%.
Moreover, people often overlook the toolchain. OS development demands effective toolchains. In the AUTOSAR era, the DaVinci toolchain was the standard, but it had limitations. Today, car manufacturing requires collaboration, rapid iteration, and continuous testing. We’ve invested significantly in building a comprehensive toolchain that spans design, development, integration, testing, simulation, and debugging. This is the key to SkyOS’s faster iteration efficiency and greater reusability.
36Kr: Previously, AUTOSAR was a software protocol for component suppliers. Will Nio’s relationship with suppliers change due to SkyOS? Will the value of supplier components decrease?
WQ: The shift in supplier roles is inevitable with the evolution of automotive architecture technology. We used to rely on many small black boxes in the car, unaware of how their functions were implemented. But with SkyOS, we can integrate these functions into the domain controller, saving significant costs and boosting efficiency while cutting iteration expenses.
What can suppliers do during this transition? They can focus on honing their functions, accumulating know-how, and exploring new cooperation models with OEMs, such as developing functions on our platform. This shift in supplier roles isn’t solely driven by the full-vehicle OS but by the broader transformation in automotive technology architecture, which reshapes the scope of collaboration.
We’ve also developed tools to convert AUTOSAR code to be compatible with our OS. However, AUTOSAR is a two-decade-old architecture with inherent design flaws. While it can be converted and adapted to our interface, it’s not the most optimal solution.
36Kr: Will Nio deploy cockpit-driving integration? How does SkyOS support this integration?
WQ: Vehicle hardware resources can be classified based on high safety, low latency, and high reliability by categorizing the operating environment required by the application. However, the division of computing resources may not align with the system-on-chip (SoC) hardware—instead, it is achieved through virtualization technology.
Virtualization has been an industry standard in cloud systems for 20 years. If each application had its server, most server resources would be utilized only 10% of the time, with 90% wasted. Sharing resources among multiple users significantly increases utilization.
In vehicles, both smart driving and cockpit computing power demands are substantial. We’re talking CPUs, GPUs, NPUs, and ISPs. By categorizing and combining these resources through isolation and virtualization, ensuring that resource modules do not affect each other, higher computing power applications can be achieved, resulting in lower bill of materials (BOM) costs.
For example, sharing camera data used to require Ethernet transmission, which occupied significant bandwidth and CPU resources on both ends. But if placed on one hardware and shared through shared memory, resource consumption is minimal. This is the benefit of cross-domain integration.
Cockpit-driving integration is also in our plans, and our chips will support it.
36Kr: Can we expect to see a scenario where Shenji supports multiple domains? When might this happen?
WQ: It will happen in NT3.0. Shenji is a vast resource pool that we must fully utilize, not just for cockpit sharing but also for other smart applications.
RELATED ARTICLE
36Kr: What are the medium- to long-term goals for SkyOS in the next 3–5 years?
WQ: The main target is to further support AI-native application experiences. I believe future cars will become AI entities with comprehensive capabilities. The hottest topic in the robotics field now is embodied intelligence, but cars are more widely used and also a form of robot themselves. Under this product form, there will be new demands in terms of hardware architecture and OS.
36Kr: What challenges do large language models or visual language models pose for full-vehicle operating systems?
WQ: Large models come with massive parameter quantities, demanding high computing power and memory. We must efficiently support their deployment, leveraging heterogeneous computing power.
We have centralized resource pools like Shenji and Qualcomm’s cockpit chips, which we need to integrate and utilize effectively. Vehicle and cloud integration demands careful optimization.
We’re likely the first carmaker to harness edge cloud technology, achieving ultra-low latency between the car and the cloud, delivering low-latency services to users. In this era of high computing power and large models, utilizing the low-latency capability of 5G edge cloud for real-time interaction between the terminal and the cloud is a key strategy.
Localized deployment of AI models is a clear trend, but we don’t want local resources solely running models and draining the vehicle’s computing power. Therefore, optimizing resources and ensuring precise use will be a long-term priority.
KrASIA Connection features translated and adapted content that was originally published by 36Kr. This article was written by Li Anqi for 36Kr.