Background
During the SAIC Motor shareholders’ meeting, an investor asked whether SAIC would consider cooperating with third-party companies such as Huawei in the field of autonomous driving. In response, SAIC Chairman Chen Hong stated that they do not accept overall solutions from third-party cooperations and that SAIC wants to keep control of the soul of autonomous driving.
However, SAIC is not refusing to cooperate with third-party companies, including Huawei. In fact, SAIC has thousands of third-party suppliers and service providers, including Huawei, Baidu, Alibaba, and Tencent, as do other car makers.
Even joint venture companies in China have chosen many Chinese partners, including traditional parts suppliers and internet and technology companies represented by BAT and Huawei. Baidu has even achieved global cooperation with Toyota and Hyundai. This is all normal and benign.
What Chen Hong means by rejecting overall solutions from third-party cooperations is that car makers do not give one supplier the battery + motor + electronic control unit, nor do they give the engine (and fuel injection controller) + transmission to one supplier, nor do they give the chip + operating system + cloud service + ecology of the information entertainment domain to one supplier… All of these elements are the soul of the car. Over the past decade, the outside world has criticized Chinese automakers for lacking core capabilities.
Of course, each car maker is different, and strategies also vary, so it is difficult to make a universal statement. Some companies choose to fully cooperate with Huawei on one model (that is, accept the overall solution), which is a kind of in-depth learning and a more daring attempt. However, you cannot require all companies to be the same, and Huawei also believes that this model is not possible for everyone.
“All men are driven by profit. Those who are busy with worldly affairs are all pursuing profit.”
—– “Records of the Historian, Biographies of Merchants and Craftsmen”
Below, Cao sir will talk about this issue based on his personal experience.
Coincidentally, a few days ago, Cao sir accompanied company leaders to visit Huawei’s automotive BU, and the high-level executives on both sides had a fairly frank exchange based on their own concerns. Cao sir will share his three insights based on this visit.SOA is widely regarded as the best software architecture for future intelligent cars due to its characteristics of “loose coupling,” “accessible interface standards,” and “easy scalability.” The most important task of the SOA architecture is to establish a unified service interface API, with the key step being the software support for each functional domain component of the car. This is a heavy and challenging task, and Huawei has adopted a self-developed + cooperative strategy. For the powertrain domain with fewer components and lower thresholds, Huawei has independently developed the DriveONE three-in-one electric drive system. For the body domain with many parts and low thresholds, as well as the chassis domain with fewer parts and higher thresholds, Huawei has patiently negotiated cooperation with industry-leading suppliers. Judging by the list of cooperative suppliers shown by Huawei, the body domain suppliers account for a large proportion, while the chassis domain suppliers have a lower participation rate. Especially, there is no sign of cooperation from Bosch, which Huawei highly values. If these suppliers join in support of Huawei’s API in their own driving layers in the future, Huawei can easily call the signals of these parts at the system application layer to control these components’ relevant actions.
This is not only Huawei’s work. SAIC Lingmu is also doing this, as well as other OEMs. However, it is impossible for every supplier to support every API interface. In the end, the result depends on which company has a higher market share, as they will support that company’s standards. In the fierce competition over SOA standards, SAIC and Huawei are competitors. Normal companies have no reason to give up before the outcome is determined. Therefore, Cao Sir stands with SAIC on this point.
#
The development of automotive controllers follows the V-model, with many professional toolchains used in each step of the V-model process. Looking closely at the first stage, it is the most basic project and product management tool. Currently, software such as Rational Team Concert, SVN, Stages, and Citrix can be used to achieve team collaboration development, version management, release, and building of technical knowledge libraries.
In the second stage, there is requirement and architecture design, and common requirement management tools include Rational Doors, Stimulus, Rhapsody, Reqtify, etc., which are used to realize requirement definition, requirement tracing, requirement changes, test planning, test case design, test execution tracing, test defect tracing, test report traceability, etc., to meet the needs and requirement change impact analysis of the product development and testing process. PREEvision is commonly used for architecture design to achieve functional division at the system level, communication network definition, interface definition, and wire harness design.In the third stage of the automobile industry, which is software development and testing, there is an important software architecture for the development of automotive embedded software – AUTOSAR specification. AUTOSAR (Automotive Open System Architecture) is an open and standardized automotive embedded system software architecture. The AUTOSAR architecture defines a layered architecture, methodology, and application interface specifications, which realize the separation of software and hardware. This allows car development to be implemented in a dispersed manner between different companies under an open and universal standard, and then centralized configuration.
In order to support the provision of “packaged” software construction services for cars under this public architecture and optimize the software body in a “modular” way, some software tool suppliers have successively launched embedded system software development tools that comply with the AUTOSAR specification.
Mathworks has added code generation functionality that complies with the AUTOSAR specification in its model-based design tool MATLAB/Simulink/Stateflow, which supports Modeling/MIL at the application layer.
Vector has launched the Da Vinci series of tools and v VIRTUALtarget series of tools. The Da Vinci series of tools mainly includes Da Vinci Configurator Pro for designing software component architecture and integrating basic software, and Da Vinci Developer for generating BSW and RTE code for ECU configuration. The v VIRTUALtarget series of tools mainly includes v VIRTUALtarget basic for creating a virtual ECU on a computer to execute integrated AUTOSAR code, and v VIRTUALtarget pro for verifying logical functionality of software components in a virtual environment built on a computer.
Elektro Bit has launched the basic software configuration tool EB tresos Studio, the basic software protocol stack EB tresos Auto Core, the safety-related EB tresos Safety tool, and so on.To run AUTOSAR code package on chips, commonly used compilers include the PowerPC Green Hills Multi series and Altium TASKING. To support efficient debugging of the code, commonly used debuggers include Lautebach TRACE32, Green Hills Probe, and i SYSTEM i C500. For software testing, QAC can be used for static testing and Tessy for dynamic testing.
The fourth stage is controller verification, commonly using NI Veristand simulation design tool, NI Teststand test management tool, Labview graphical interface tool, and corresponding signal simulators and power loads for hardware-in-the-loop testing (HIL).
The final stage is system-level verification, using CANape and INCA for calibration, CANoe and Vehicle Spy for bus simulation testing and diagnostic functions, and vFlash for Bootloader.
Since joining AUTOSAR in October 2018, Huawei has actively participated in specification and architecture development and has quickly become a Premium Partner in the organization. Based on years of deep software development experience, Huawei has developed a full-stack toolchain for automotive software development by integrating diagnostic, simulation, measurement, calibration, and other tools, as well as an automated toolchain for vehicle-level IO configuration. This full-stack toolchain maximizes tool compatibility and integration, promotes flexibility, and helps OEMs significantly shorten their development cycles. However, the software code generated by this toolchain is best suited for Huawei’s self-developed chips, meaning that when working with Huawei and using this toolchain, it is best to use Huawei’s controller hardware as well. This bundling of software and hardware may make some partners hesitant, and on this point, Cao sir stands with the automotive industry.
The administrative staff at Huawei who are responsible for reception are all elegant and courteous, with beauty that surpasses that of flight attendants. Compared to the reception etiquette of other companies, they are definitely textbook examples. On this point, Cao sir stands with Huawei.At the negotiation meeting, Huawei repeatedly mentioned that they were doing the dirty work for the mainframe manufacturers and were good at being low-key. Everyone responded with a knowing smile, knowing that once the so-called dirty work was completed, they would have the power and dominance in the industry. Therefore, SAIC’s decision to cooperate or not with Huawei is blameless, as it is a commercial issue on the surface, but essentially a struggle for the initiative in the future industrial structure.
The essence of cooperation is actually a balance of interests!
Regarding the body and soul, Cao Sir published an article titled “Hardware and Software: Body and Soul” last year. Interested friends can read it.
This article is a translation by ChatGPT of a Chinese report from 42HOW. If you have any questions about it, please email bd@42how.com.