Group Chat | For joining the “Sensor Group/Skateboard Chassis Group“, please add WeChat ID: xsh041388
Group Chat | For joining the “Automotive Basic Software Group”, please add WeChat ID: ckc1087
Note: Group Name + Real Name, Company, Position
When it comes to the main control SoC chip used in cockpit domain controllers, the first one that comes to mind is Qualcomm’s SA8155P. Currently, in the mid-to-high-end models newly launched by OEMs, the main control SoC chip in the cockpit is mostly Qualcomm’s SA8155P. Why has the SA8155P gained favor from many OEMs? Let’s take a look at the iteration history of Qualcomm’s cockpit SoC chips.
Iteration History of Qualcomm’s Cockpit Chips
The Computing Power of Qualcomm’s Fourth-Generation Cockpit SoC Chips
By comparing Qualcomm’s fourth-generation cockpit chips, we can reflect that the computing power demand of smart cockpits is continuously increasing, whether it is CPU computing power (DMIPS), GPU computing power (FLOPS), or NPU computing power (TOPS).
Predicted Demand for CPU and NPU Computing Power (Source: IHS Markit)
So, what are the driving forces behind the continuous growth of computing power demand in smart cockpits?
1) Continuous Upgrading of EE Architecture Promotes Integration of Cockpit Functions
Smart Cockpit System Architecture Diagram (Source: Continental Group, CICC Research Department)
The functions integrated into the cockpit are increasing, and the amount of data that needs to be processed is also increasing and becoming more complex. Therefore, the demand for computing power in the cockpit will continue to grow. Currently, the external manifestations of the functional integration of cockpit domain controllers mainly include: one chip, multiple screens, integration of in-cabin perception technologies, and integrated docking.
2) Expansion of In-Cabin Application Scenarios
Traditionally, the cockpit only served the driver. Now, the concept of the cockpit has expanded from “driver’s cabin” to the entire “cockpit”, and the service targets are no longer focused solely on the driver but also include the front passenger and rear passengers.
Jin Hui, Senior Product Marketing Director of Hailan Technology, said: “The traditional vehicle machine system basically only interacts with the driver, while the current smart cockpit system needs to interact with multiple passengers at the same time, that is, multi-person interaction.“
As the autonomous driving capability transitions from human-machine co-driving to fully autonomous driving, the application scenarios of the cockpit are continually expanding. In addition to traditional driving/safety-related needs such as navigation and safety warnings, various human-machine interactions and entertainment experiences are becoming increasingly prominent, gradually extending the application scenarios of the cockpit to office, life, and entertainment.
The continuous expansion of application scenarios will naturally give rise to new functional demands, thereby indirectly promoting the growth of computing power demand in the cockpit.
3) Emphasis on Data Security
The application ecosystem in the cockpit is becoming increasingly rich, and its requirements for security are also becoming higher. “Everyone wants to protect their privacy, and the country has also introduced laws and regulations related to data protection and personal privacy protection. The handling of data security will, to some extent, raise the demand for computing power in the cockpit,” said Chen Yuan, CTO of Junlian Zhixing China.
This article will first start from the hardware architecture characteristics of smart cockpit domain controllers, and then discuss the technological development trends of smart cockpit domain controllers from three dimensions: functional integration performance, product form, and data security.
1. Characteristics of Cockpit Domain Controller Hardware Architecture
1.1 Hardware Architecture Scheme of Cockpit Domain Controller: SoC + MCU
Currently, the hardware architecture of cockpit domain controllers is very similar to that of intelligent driving domain controllers, both being SoC + MCU schemes.
The main control SoC chip of the cockpit domain controller is used to run complex operating systems and handle big data processing, such as the processing of unstructured data like images, videos, and audio.
However, the current smart cockpit main control SoC chip architecture is mostly migrated from the mobile side, and it does not have onboard network access interfaces, such as CAN, MOST, LIN, etc. Therefore, it needs to be paired with an MCU to access the vehicle network. Thus, complex cockpit domain controllers generally adopt two types of chips: SoC + MCU.
1) The SoC runs a Hypervisor, on which two types of operating systems run. The safety domain module, which has higher real-time and security requirements, runs on QNX or Linux systems; the entertainment domain module, which has lower real-time requirements but higher ecosystem requirements, runs on Android systems;
2) The MCU runs the AUTOSAR system for waking up, communication, and power management of the CAN/LIN bus.
Software Architecture of Cockpit Domain Control System (Source: Public Account-Abao1990)
Why is the MCU an indispensable part of the cockpit domain control hardware architecture? Chen Lishun, Deputy General Manager of Nobuo Automotive, explained: “The real-time and reliability requirements of the MCU are very high. The startup wake-up is at the millisecond level and needs to support various vehicle communication buses like CAN and LIN. The information exchange between the cockpit domain controller and the body, power, and other controllers needs to be completed through the MCU. Additionally, the MCU needs to manage the power and monitor the status of the SoC.
“Some manufacturers intend to integrate an MCU module into the SoC to replace the external MCU, but the reliability of the current integrated MCU scheme needs to be verified, and the power supply for the integrated MCU and SoC needs to be independently powered to reduce static power consumption, which is relatively complex to implement.
“Compared to MCU, the power consumption of SoC is very high (static current is large), so in the sleep state of the entire machine, the SoC is generally in a powered-off state while the MCU is powered. When the MCU detects a wake-up source, it will wake up the SoC, and then the SoC will start working; if the SoC needs to enter sleep mode, the MCU will cut off the power to the SoC.
“Moreover, the entire product-level controller’s power management is implemented through the MCU, making the MCU indispensable.”
1.2 Differences Between Cockpit Main Control SoC Chips and Intelligent Driving Main Control SoC Chips
Like the intelligent driving main control SoC chip, the cockpit main control SoC chip also adopts a heterogeneous multi-core architecture, and the internal architecture of both is generally similar—both include various heterogeneous resources such as CPU, GPU, and NPU. However, the cockpit and intelligent driving are two different application scenarios, which determines that the cockpit SoC chip and intelligent driving SoC chip will have different focuses during the design phase.
1) Different Focuses of Heterogeneous Architecture
The focus of the cockpit domain controller’s main control SoC chip is on CPU and GPU, while the focus of the intelligent driving domain controller’s main control SoC chip is on CPU and NPU.
-
CPU is used for general logic operations, such as system scheduling and external resource access. Whether in the cockpit system or the intelligent driving system, CPU resources are indispensable.
-
GPU has strong floating-point operation capabilities, but on intelligent driving SoC chips, there is generally no need to integrate a very strong GPU because the internal NPU’s tensor units are already strong enough, eliminating the need for GPU to perform tensor operations and acceleration calculations. The cockpit SoC chip needs to perform 3D rendering of images, image stitching, and run large 3D games, so the cockpit SoC chip has higher requirements for GPU capabilities than the intelligent driving SoC chip.
-
NPU, as an accelerator for neural network algorithms, is responsible for processing AI-related computing needs. There is no doubt that intelligent driving has a high demand for NPU computing power; some cockpit SoC chips also have NPU modules to handle basic driving assistance functions like DMS or LDW, but overall, the performance of the NPU in cockpit main control SoC chips is weaker than that in intelligent driving main control SoC chips.
In summary, the cockpit main control SoC chip has stronger general-purpose cores than specialized cores, while the intelligent driving main control SoC chip has stronger specialized cores than general-purpose cores.
2) Differences in Interface Definitions
The interface definitions of cockpit domain controller main control SoC chips and intelligent driving domain controller SoC chips also have significant differences. Chen Yuan, CTO of Junlian Zhixing China, believes that the cockpit’s application scenarios focus more on in-cabin human-machine interaction capabilities. Human-machine interaction requires a large amount of data output, such as video, sound, and other projected images; at the same time, it also needs to acquire data input from within the vehicle, mainly the data input from the cabin personnel—there’s video (DMS/OMS) and sound (microphone) involved. Therefore, cockpit SoC chips will face diversified sensor data input and output requirements.
Nobuo Automotive’s Deputy General Manager Chen Lishun also basically agrees with this view, saying: “The focus of cockpit peripherals is on large data input and output, such as audio and video. For example, how many DP or DSI interfaces are supported—this determines how many displays can be connected; how many TDM channels are supported—this determines whether more complex multi-scenario audio pathways can be achieved; it also needs to support GNSS, WIFI, Bluetooth, and other module interfaces. In summary, cockpit SoC chips have very high requirements for peripheral interfaces.”
“In autonomous driving system solutions, millimeter-wave radar signals are generally transmitted via CAN bus, while LiDAR signals are generally transmitted via Ethernet. These are standard communication interfaces; therefore, the peripheral interfaces of intelligent driving main control SoC chips are relatively simple, with a primary focus on camera connectivity.”
3) Differences in Functional Safety Design
“Functional safety is not chip-specific but product-specific. Functional safety design is a system engineering task, which can involve designing some redundancy or adding state detection at the chip level, or conducting system-level monitoring and functional decomposition for the controller product itself.”
“When chip manufacturers design SoC chips, if they consider functional safety, they must take into account the specific application scenarios, whether it is for cockpits or driving, or even specific working conditions, and then make targeted functional safety designs based on the corresponding scenarios and working conditions,” said Chen Lishun, Deputy General Manager of Nobuo Automotive.
The cockpit SoC chips and intelligent driving SoC chips do not have significant differences in functional safety certification, but there are certain differences in functional safety design.
According to relevant industry insiders, in addition to the functional safety design of the chip itself, other designs are also needed to jointly ensure that the functional safety requirements of intelligent driving are met. The chip is only part of it; the system solution is another part. If a system solution backup is to be made, the chip design itself needs to have some interfaces that can support redundant communication methods.
Relatively speaking, the cockpit system has much lower requirements for functional safety design. Even for safety and real-time requirements that are relatively high for instrument or HUD modules, a functional safety level of ASIL B is sufficient to meet the requirements.
2. Manifestations of Functional Integration in Cockpit
The overall vehicle EE architecture is upgraded from a distributed architecture to a domain centralized architecture, driving the integration of independent ECUs in the cockpit into a cockpit domain controller DCU. As the cockpit needs to integrate more and more functions, what are the principles for integrating functions in the cockpit? Which functions are suitable for integration?
2.1 Principles of Function Integration
1) Within the Capability Boundary of Cockpit Main Control SoC Chip
The integration of certain functions depends on the capabilities of the cockpit main control SoC. The OEM or Tier 1 will evaluate how many channels and the resolution of cameras and displays that the cockpit main control SoC can support; at the same time, it must also check whether the safety level of the integrated function can be covered by the cockpit chip (not exceeding ASIL B). If the processing capability or performance of the main control SoC can cover this function, then it can be preliminarily determined that this function is suitable for being integrated as an extension of cockpit functions.
2) No Additional Hardware Needed
If adding one or several functions can be done without adding hardware, only requiring the algorithms and software to be ported to the cockpit domain controller, while also being cost-competitive, then this function is suitable for integration.
2.2 Three Manifestations of Functional Integration in Cockpit
With the continuous improvement of the performance of smart cockpit main control SoC chips, and the accelerated penetration of functions like 5G vehicle networking and OTA, both OEMs and Tier 1s have begun to pay attention to the integration of functions in cockpit domain controllers. The functional integration of cockpit domain controllers is mainly manifested in the following aspects:
2.2.1 One Chip, Multiple Screens
In traditional cockpit solutions, systems like the central control and instrument are independent and generally driven by a single chip for a single function/system. With the development of cockpit intelligence, the cockpit domain controller further integrates instruments, HUDs, streaming media rear-view mirrors, and other systems—from a single SoC driving a single system and single screen to a single SoC supporting multiple systems and multi-screen displays.
One Chip, Multiple Screens (Source: Volkswagen Public Presentation Materials)
To support multiple screens on a single SoC chip, from a safety perspective, virtual instruments and HUD need to use QNX or Linux systems; from a software ecosystem perspective, central control navigation, front passenger entertainment, and rear passenger entertainment need to use Android systems.
The current mainstream solution is to use virtual machines—Hypervisors to run multiple operating systems on a single hardware. What shortcomings or areas for improvement exist in the application of Hypervisor technology in cockpits at this stage? Are there other technologies that can serve as alternatives to Hypervisor technology?
Shortcomings or Areas for Improvement in Hypervisor Technology:
1) It can cause a certain amount of hardware performance loss.
Senior Product Marketing Director of Hailan Technology, Jin Hui, explained: “Using software virtualization comes at a cost. Whether it’s CPU, GPU, or NPU, their computing power will lose a portion during the software virtualization process, meaning it is not fully utilized, which results in performance being compromised. Additionally, the performance of peripheral access will also be affected by software virtualization—multiple systems need to access the same interface via software virtualization, requiring some software-level processing in the virtual machine software, which reduces the efficiency and performance of peripheral access.”
“Using Hypervisor will inevitably increase system overhead. When virtualizing resources like GPU, CPU, and NPU, the hardware resources switch between different applications, which will unavoidably increase the overall load of the system.” Junlian Zhixing China CTO Chen Yuan also basically agrees with this viewpoint.
2) The system has not achieved effective isolation.
“Hypervisor technology divides the system through software without achieving effective hardware-level isolation—each system runs on the same layer of software, which means that functional safety and information security are not effectively guaranteed compared to hardware isolation solutions.” Senior Product Marketing Director of Hailan Technology, Jin Hui, stated.
So, are there alternatives to Hypervisor?
Chen Yuan, CTO of Junlian Zhixing China, told Jiuzhang Zhijia: “The industry position of QNX is difficult to shake in the short term. All choices are about finding a balance between cost and efficiency. Currently, some companies are adopting hardware isolation solutions, which is one option; another option is to conduct software isolation on the chip without using hardware isolation.”
The advantage of using Hypervisor technology is that all IP cores (CPU, GPU, DSP, etc.) and surrounding peripherals can be shared, while the problem with hardware isolation is that resources cannot be well shared. For example, resources used for the instrument module in the safety domain may be idle and cannot be allocated for use in the entertainment domain.
However, hardware isolation also has its advantages. Senior Product Marketing Director of Hailan Technology, Jin Hui, stated: “Compared to Hypervisor technology, adopting hardware isolation solutions does not require paying license fees for virtualization software, and the computing power is not compromised, while functional safety and information security can be guaranteed.”
2.2.2 Integration of In-Cabin Perception Technologies
Currently, the mainstream implementation scheme for DMS is based on facial recognition visual technology, which has high requirements for chips—firstly, it needs to meet automotive-grade requirements, passing reliability certifications like environmental tests and life tests; secondly, it has a high demand for AI computing power. For accurate facial recognition of 3D spherical images, not only is a high-resolution camera necessary, but the model also needs to be optimized after image data collection.
With the development of technology, DMS has been extended to OMS, which expands the detection range from the driver to cabin passengers, such as detecting whether passengers are wearing seatbelts or whether children are left in the car when getting off. Currently, many OEMs have already combined DMS and OMS for application.
The DMS and OMS functions are mainly realized through real-time analysis of in-cabin camera data. The computing power and performance of the cockpit main control SoC chips are becoming increasingly strong, not only supporting multi-channel video input capabilities but also integrating dedicated DSP units.
Integrating DMS/OMS functions into the cockpit is not only because the performance of the cockpit SoC chip can cover DMS/OMS but also because by integrating them into the cockpit, they can better interact with other related modules in the cockpit.
For example, Visteon’s HMEye is a DMS based on gaze measurement, which can monitor whether the driver’s hands and gaze are in driving mode. It can also allow the driver to control functions like switching broadcasts, adjusting temperature, and starting navigation through eye movements. This way, the driver can interact with the human-machine interface more safely while driving.
2.2.3 Integration of Parking Functions
The integration of parking into the cockpit also has functional integration factors: early 360-degree surround view systems had separate controllers; later, 360-degree surround view and automatic parking assistance (APA) were integrated, and then upgraded to integrated parking functions, requiring further upgrades to controller performance; as technology developed, the cockpit main control SoC chip gained stronger CPU computing power and AI computing power, which met the conditions for integrating parking functions, leading to the demand for integrating parking functions into the cockpit.
The cockpit integrates basic parking functions: firstly, it can reduce costs, at least saving the original parking controller, thus saving material costs; secondly, integrating into the cockpit allows for better human-machine interaction design in parking scenarios, with the cockpit domain controller receiving more parking signals; finally, the computing power on the cockpit can be maximally utilized.
Chen Yuan, CTO of Junlian Zhixing China, explained: “The parking function is only used in parking scenarios, which coincides with the timing of some applications in the cockpit, like displaying navigation information and driving information, which are used during driving. During parking, these applications are basically inactive, so most of the remaining computing power in the cockpit can be used for parking-related applications.”
3. Changes in the Product Form of Cockpit Domain Controllers
In different stages of autonomous driving, differences in design concepts for cockpit domain control can even lead to significant differences in product forms.
From a technological development trend perspective, we are currently in the human-machine co-driving stage, also known as the driving assistance stage. At this stage, intelligent driving domain control and intelligent cockpit domain control are still two independent controllers. As we transition to the truly autonomous driving stage, industry insiders generally believe that with further upgrades to the vehicle’s electronic and electrical architecture, reaching the so-called central computing platform + regional controller architecture stage, the functions of the cockpit and intelligent driving will be highly integrated, that is, cockpit-driving integration.
Central Computing + Regional Control Architecture (Source: Junlian Zhixing Publicity Materials)
Depending on the EE architecture and the integration capability of the main control SoC chip at different stages, the cockpit-driving integration high-performance computing platform will exhibit different forms:
Currently, some people mention cockpit-driving integration HPC, but it is not a single SoC chip solution; it is basically composed of two boards, one running the smart cockpit system and the other running the intelligent driving system. However, this structural form poses high requirements for heat dissipation and power supply design.
A certain OEM EE architecture expert told Jiuzhang Zhijia: “In the domain controller stage, the intelligent cockpit and intelligent driving still use separate box controls, which is still a relatively good solution at present. If we now change the two independent box solutions to a solution with two boards in one box, costs should be reduced, but it will be more troublesome in engineering: for example, if there are multiple boards in one box, different boards use different suppliers, it will be cumbersome to replace them if they are found to be incompatible midway; if changed to a solution with a single board in one box, it means bundling too many functions on one board, which will inevitably involve multiple parties, making early coordination and later maintenance complex.”
A senior engineer from a certain OEM also agrees with the view that the cockpit system and intelligent driving system should remain independent at this stage, stating: “Purely from the evolution of the vehicle’s EE architecture, cockpit-driving integration is certainly the trend, but in the short term, combining intelligent driving and cockpit purely represents a formal integration, not a result derived from product demands.”
“The application scenarios, function definitions, and performance boundaries targeted by both are different. At least for now, I believe there is no need for them to merge. If we forcibly squeeze them together, whether in terms of chip selection or peripheral circuit design, the requirements will differ. So, in terms of cost and performance considerations, which should we lean toward? In summary, the way of merging the two will bring a series of design difficulties for developers.”
Although only a single SoC chip cockpit-driving integration architecture can achieve true integration of cockpit and intelligent driving, the requirements for cockpit and intelligent driving in functional needs, functional safety requirements, information security requirements, and focuses on different types of computing power needs are all different. If both are placed on one chip, the system will become extraordinarily complex, and it will be difficult to find a single SoC chip that can meet such demands in the short term.
At this stage, the single SoC chip cockpit-driving integration solution still faces several hardware and software issues. What specific problems are faced will not be elaborated here; interested readers can refer to my previous article: “Analysis of the Technological Development Trends of Cockpit-Driving Integration”, which provides a more detailed introduction.
4. Data Security Protection for Smart Cockpits
Now, there are more and more cameras in the cockpit, and the functions within the cockpit are becoming increasingly rich. The cockpit system will use a large amount of user data locally while also needing to maintain real-time data sharing and synchronization with the cloud. The cockpit domain controller is an important port for automakers to collect user data and perform OTA, thus making data security for cockpit systems extremely important.
So, how can we protect users’ private sensitive information from being leaked or used illegally?
4.1 Ensuring the Information Security of the Operating System Itself
First, we need to ensure the information security of the operating system itself. For instance, Android, QNX, and other systems need to perform secure boot verification during startup to prevent the system from being infected by viruses. Additionally, permissions for the operating system should be controlled, minimizing authorization matters to prevent all applications from accessing very private areas.
Second, communication between controllers needs to involve some secure communication processing, such as C2C encryption, where a message needs to be verified for its sender.
4.2 Data Encryption and Masking Processing
Data collection and storage not only require user authorization but also need to undergo encryption and masking processing.
Data Encryption — The cockpit SoC chip has an information security module HSM, which contains an information security encryption engine. With these engines and matching processors, users can build some encryption algorithms on the upper layer, such as national encryption SM2/SM3/SM4/SM9, or some commercial encryption algorithms.
The basic framework of cockpit information security primarily involves private key encryption + public key decryption. Privacy data being transmitted needs to be signed and authorized; secondly, it needs to be encrypted. This means that data is encrypted with a private key and sent to the recipient, who can only view the data after decrypting it with the public key. During transmission, if anyone else does not have the public key, even if they obtain the data, they cannot decrypt it.
Data Masking — When identifying individuals, one cannot recognize their identity or personal characteristics, such as whether they are male or female. Data collection may naturally involve infringing on others’ privacy, so data must undergo masking processing. Moreover, many data must be processed at the endpoint and cannot be sent to the cloud to avoid the risk of data leakage during transmission to the cloud.
In summary, data security protection is a very complex project that needs to be considered from various aspects. While protecting data, we must also prevent hackers from intruding. “Globally, many hackers attack Tesla vehicles to find vulnerabilities and report them to Tesla for rewards. Many vehicles now require penetration testing, meaning they hire a third-party company to hack the vehicle to check for vulnerabilities,” said Chen Yuan, CTO of Junlian Zhixing China.
5. Market Landscape of Cockpit Main Control SoC Chips
Currently, the market landscape for the main control SoC chips of cockpit domain controllers has gradually become clear: in the mid-to-low-end market, traditional automotive chip manufacturers are the main players, such as Renesas, TI, NXP, etc.; in the high-end market, consumer electronics chip manufacturers are the main players, such as Qualcomm, Samsung, Intel, AMD, etc.
Why are consumer electronics chip manufacturers able to enter the cockpit chip market?
Industry experts point out that the barriers for consumer electronics chip manufacturers to enter the cockpit field are not high because the technical requirements of both are highly similar. The special automotive-grade requirements mainly reflect in aspects like lifespan and adaptation to automotive environments. However, consumer electronics chip manufacturers find it not particularly challenging to pass these automotive-grade certifications.
At the same time, consumer electronics chip manufacturers already possess strong design capabilities on the consumer side, enabling them to provide automotive-grade cockpit chips with similar processes and designs in the relatively niche automotive field.
Not only have consumer electronics chip manufacturers entered the cockpit field, but why can they also firmly occupy the high-end market in the cockpit field?
Consumer-grade chip manufacturers can maximize their production capacity on the consumer side to amortize the overall chip design costs. Therefore, when they transfer consumer-grade chips to applications in the cockpit field, they deliver a dimensionality reduction strike against traditional chip manufacturers in cost terms.
Chen Lishun, Deputy General Manager of Nobuo Automotive, said: “Cockpit SoC chips generally include CPU, GPU, NPU, DSP, etc. The IP designs and authorizations are usually sourced from third-party companies like ARM and Imagination. For traditional automotive chip manufacturers, the licensing fees for these IPs are very high. However, for Qualcomm, many of these IPs are self-developed, and ARM’s architecture licensing fees are also much lower than those of some traditional automotive chip manufacturers.”
2) Performance and Iteration Speed Advantage of Chips
Firstly, consumer electronics chip manufacturers’ cockpit chips have significant advantages in advanced processes and high computing power.
Secondly, the iteration speed of cockpit chips from consumer electronics chip manufacturers is fast. They can iterate cockpit chips based on the iterations of intelligent consumer electronics chips, and their chip iterations naturally occur much faster than traditional automotive chip manufacturers.
Basic Information of Qualcomm’s Fourth-Generation Cockpit Platform (Source: Public Data Compilation)
Note: As of now, Qualcomm has released a total of four generations of cockpit chips, all following the underlying logic of “consumer-grade chips first, smart cockpit chips later.”
1. Smart Cockpit Domain Controller (IV)
https://mp.weixin.qq.com/s/IfCPucJ1zjV0bkvvUw0tVg
2. Autonomous Driving “Liberating Hands”? Starting with Standard DMS
https://mp.weixin.qq.com/s/p0heq74SRQmeqLRHZq64jw
3. Integration of Driving and Parking: Connecting the Intelligent Driving”s “Ren and Du Meridians”
PINnopqMj2KDV9tGEUY83Q
4. Smart Cockpit Product Design Series III: Smart Cockpit Monitoring System IMS
https://mp.weixin.qq.com/s/-ujr3X8bizNZjdvU5MLP_Q
5. Big Cow Lecture | Li Xingyu: What Should the Ideal Interaction Mode for Smart Cockpits Look Like?
https://mp.weixin.qq.com/s/v2360jU2YTpJBa63lfrzlg
6. Smart Cockpit Upgrade Solutions for Intelligent Driving Needs
https://mp.weixin.qq.com/s/VGBvdVlqNCkavoWZqfSfrQ
7. Smart Cockpit or Intelligent Driving? Qualcomm Snapdragon Does Not Make a Choice
https://mp.weixin.qq.com/s/LZ1mB_3ePq0rlRU_3RWAiA
8. Securities Report – Automotive Intelligence Series on Cockpit Chips: From One Chip, Multiple Screens to Cross-Domain Integration
Communicate with the Author
If you wish to communicate directly with the article’s author, you can scan the QR code on the right to add the author on WeChat.
Note: Please be sure to include your real name, company, current position, and intended position when adding WeChat. Thank you!
If you are interested in submitting an article to “Jiuzhang Zhijia” (articles of the “Knowledge Accumulation and Organization” type), please scan the QR code on the right to add the staff member on WeChat.
Note: Please be sure to include your real name, company, current position, and intended position when adding WeChat. Thank you!
Quality Requirements for “Knowledge Accumulation” Type Manuscripts:
A: The information density must be higher than that of the vast majority of broker reports and not lower than the average level of “Jiuzhang Zhijia”;
B: The information must be highly scarce, with over 80% of the information not available in other media. If based on public information, it must have particularly outstanding exclusive viewpoints. Thank you for understanding and supporting.
◆ Jiuzhang – 2021 Annual Article Collection
◆ When Candidates Say “I Am Optimistic About the Future of the Autonomous Driving Industry”, I Will Be Cautious—A Review of the First Anniversary of Jiuzhang Zhijia (Part 1)
◆ If Data Collection Is Not Enough and Algorithm Iteration Is Not Fast Enough, “No One Likes Me”—A Review of the First Anniversary of Jiuzhang Zhijia (Part 2)
◆ Moving to the “First City of Autonomous Driving”—A Journey That Can Be Started Anytime
◆ Understand the Application of Data Masking Technology in Smart Vehicles in One Article
◆ Single SoC Chip Solutions May Accelerate the Large-Scale Production and Application of Integrated Parking Solutions
◆ From the Actual Performance of AVP, Looking at the Commercialization Possibility of “L3” Autonomous Driving
