Industry Insights: Can weak domestic basic software be reversed in the automotive industry?

01 .

The current situation and challenges of domestic automotive basic software

Basic software fields such as operating systems, databases, middleware, programming languages ​​and compilers have always been weak links in my country's software industry. In recent years, they have attracted much attention due to some "stuck" incidents. In fact, different industry categories have different basic software. For example, the PC industry, mobile phone industry, industrial control, cloud computing, etc. all have basic software in their own fields. The automotive industry is no exception and also has its own set of basic software.

What is very gratifying is that compared to the situation where the basic software of industries such as PC and mobile phones is almost completely dependent on foreign countries, the basic software of the automotive industry has received great attention from top to bottom in recent years and has made certain substantial progress. There is a strong tendency to overtake in corners and reverse the situation.

In the field of automotive software, with the continuous development of automotive electronics technology, especially driven by the "new four modernizations" trend of the automotive industry in recent years, the importance of software to cars has become increasingly prominent, and the concept of "software-defined cars" has gradually become Industry consensus.

At the same time, the automotive industry still has gaps in the basic software required for domain controllers or in-vehicle computing platforms in the new generation of centralized E/E architecture. There is no such thing as Windows in the PC industry or Android in the mobile phone industry that can be used by various vehicle manufacturers. General-purpose operating systems and middleware used by manufacturers or suppliers, and people who are engaged in software know that: whoever gets the operating system wins the world.

Therefore, everyone no longer only focuses on the development and innovation of application software, but also pays more attention to the development and innovation of automotive basic software such as in-vehicle operating systems, middleware, AUTOSAR, etc. The domestic automotive basic software field has seen unprecedented prosperity.

• A large number of companies with automotive basic software as their main business have been born, such as Neusoft Reach, Puhua Basic Software, Matrix Partners, Zhongke Chuangda, Ise Intelligent Control, etc. Many of these basic software products have achieved a certain scale of success. mass production.

• Large automotive software companies have emerged that provide "full-stack" automotive software solutions including basic software, such as Zero Bundle and Huawei;

• It has gained more and more favor from industry VC venture capital institutions. In October last year, Neusoft Ruichi received a total investment of 650 million yuan from SDIC Investment and De Zaihou, and the company's valuation exceeded 6 billion yuan.

• Led by the China Automobile Association, AUTOSEMO, China's first ecological alliance in the automotive basic software field, was established in July 2020, aiming to provide the Chinese automotive industry with standardized basic software architecture, methodology and application program interface standards for next-generation cars.

Can domestic basic software, which has always been weak in all walks of life, be reversed in the automotive industry this time? We might as well first look at the reasons why basic software in other industries developed slowly without breakthroughs in the past. According to two articles, the "China Basic Software Root Technology Development White Paper" released by the China Software Industry Association in 2021 and the "Interpretation of the Information Industry Development Guide: Basic Software and Industrial Software" released by the Ministry of Industry and Information Technology in 2017, the Domestic Basic Software Development Institute The main problems are:

1. Domestic basic software does not have a deep grasp of core technologies, and there is still a certain gap between product performance, functionality, user experience, stability, and maturity compared with mainstream foreign products. There is also a large gap with foreign companies in terms of productization and engineering.

2. There is insufficient training and reserve of professional talents. There is insufficient investment in basic software technology, and the training of professional talents lacks pertinence, especially the lack of comprehensive talents.

3. The scale of the industry is small, the power is dispersed, and no ecosystem has been formed.

Unfortunately, in my opinion, these three problems also exist for the current domestic automotive basic software industry. Below we take the AUTOSAR software, which is familiar to everyone in the field of automotive basic software, as an example for analysis.

First of all, our grasp of the core technology of basic automotive software is far from deep enough.

Because most people have only begun to understand basic automotive software through AUTOSAR in recent years. Before that, we had very little understanding of basic automotive software.

The basic software of each controller in the car is usually developed by Tier1, and the core parts of the car have always been the ice zone of China's automobile industry. Before the "new four modernizations" of the industry, domestic auto parts companies mostly focused on mechanical parts. There are very few core components related to electronic control. Most of the earliest domestic developers who came into contact with basic software were from foreign-funded parts companies such as Bosch and Conti. Moreover, due to the protection of core technologies by foreign-funded companies, many engineers could not even see the software source code in the controller.

Here’s a story: I worked as an intern in the research and development department of a foreign-owned seat heating controller in 2009. At that time, because the source code was not available in China and I urgently needed to modify an important parameter for product testing, I had no choice but to analyze the binary executable file. (Hex file generated after software compilation), through a method similar to decompilation, the location of the parameter in the file was found, and the parameter was directly modified (fortunately, the program did not have a series of information security mechanisms such as today's safe refresh and safe startup. ~~), thereby ensuring that product testing can be completed on time. It can be seen that at that time, domestic engineers could not even see the source code of a simple seat heating control function software.

It was not until recent years that many start-up companies were born in the domestic new energy and autonomous driving fields to conduct independent research and development of related components. Foreign companies such as Vector and ETAS timely launched basic software products that comply with AUTOSAR standards for their use, giving domestic engineers the opportunity to Really exposed to the basic software of automobiles, many people mistakenly think that the basic software is AUTOSAR, and AUTOSAR is the basic software. As for the several domestic basic software suppliers mentioned earlier, most of their developers also developed basic software with reference to the AUTOSAR standard and had no previous relevant experience.

One can imagine how difficult it would be for these companies to realize the productization and engineering of basic automotive software. Take productization as an example. Due to the lack of practical development and application experience among developers, developers only rely on a bunch of AUTOSAR standard documents to develop products. When faced with customer needs, they cannot reasonably guide customers and blindly meet their various needs. It is difficult to form their own standardized products. , it is easy to lead yourself into a dead end.

Secondly, there is a serious shortage of professional talents, fierce competition for talents in the industry, and poor job stability.

It is not difficult to see from the above that there is an extreme shortage of professionals in the field of basic automotive software. In recent years, a large number of companies have sprung up in the industry and are hungry for basic software talents. The value of basic software engineers has doubled, and the turnover rate is extremely high, which is not conducive to the growth of personal abilities. From an enterprise perspective, a serious shortage of developers is difficult to support the enterprise in realizing its ambitions.

In Bosch, as of 2020, there are approximately 1,200 software engineers dedicated to the development of basic automotive software. According to the information released by Bosch last year, the "General Motors Software" development team formed after its integration with ETAS will reach more than 2,000 people. Among third-party software suppliers such as Vector and KPIT, the size of their automotive basic software development teams is also around 800 to 1,000 people. However, even if domestic basic software companies are fully equipped, most of them only have about 100 people, some even have less than 50 people, and the largest one does not exceed 200 people. Even if the capabilities of our engineers are equivalent to those of foreign countries, the products we develop will be discounted by 20% or even 10%.

Thirdly, the industry is small in scale, resources are dispersed, concentration is low, and there is even vicious competition.

国内汽车产业本就具有非常明显的分散特征，而这一特征在汽车基础软件领域也正在上演，以AUTOSAR产品为例，国内目前已至少有东软睿驰、普华基础软件、经纬恒润、道纬科技、知从科技等五家宣称可提供相关产品与服务。另外，还有一件让人费解的事情：2020年11月，“中国智能网联汽车产业创新联盟基础软件工作组”成立了，这是国内第二个基础软件生态联盟，而前一个AUTOSEMO刚刚成立不到半年。

本就稀少的资源变得更加分散，而资源分散是致命的，内耗太多，难以成事。为了拿到项目，相对于国外产品普遍按照授权使用范围或产量进行定价的模式，一些国内企业在产品单价远低于国外产品的情况下，进一步采取不限制使用范围的一口价策略，后期用户使用过程中甚至还可以以极低费用甚至免费提供工程服务直至量产，大大低估了基础软件的价值和应用难度，导致利润极低，甚至亏损。部分企业已经出现增长乏力甚至是负增长。

据高工智能汽车报道：“作为中国软件企业中最早进入AUTOSAR高级合作伙伴的普华基础软件，截至去年底，其AUTOSAR汽车级软件平台产品已量产超过500万套，但公司营收却并没有起色。数据显示，该公司2017年营收为7,232.14万元，利润仅为24.81万元；到了2020年，营收为9,387.57，利润153.28万元，营收年复合增长百分比仅为个位数，公司整体估值仅为3.36亿元。最新数据显示，普华基础软件2021年1-9月营收为5672.82万元，净利润亏损580.53万元，在汽车软件行业整体向好的背景下，却凸显业务增速的乏力。”

总的来看，汽车基础软件的国产化之路已经开启，但同样道阻且长。基础软件技术一向是门槛高、投入大、周期长、回报慢，希望每一个真正有志于国产汽车基础软件的同行都能坚守初心，行稳致远。

要想做好汽车基础软件，首先应当搞明白什么是汽车基础软件。本人不才，一直从事于汽车动力总成领域的控制器基础软件开发，对于以AUTOSAR Adaptive为代表的面向智能网联汽车的新一代汽车基础软件缺乏实际应用经验。以下基于自身有限的工作经验，仅就传统ECU领域的基础软件，阐述自己对于到底何为汽车基础软件的理解，以及它的诞生与演变历史，希望有助于国内以应用AUTOSAR Classic 平台为主的ECU零部件供应商更高效地开发更高质量、更加安全的关键核心零部件，同时对于我们开发以AUTOSAR Adaptive为代表的面向智能网联汽车的新一代汽车基础软件有所启发。

02.

汽车基础软件的定义

汽车基础软件，又称为底层软件，虽然现在经常被提到，大家似乎都很熟悉了，但仔细考究就会发现，目前并没有一个被行业各方都认同的统一的定义。就连专注于汽车基础软件的AUTOSAR标准，给出的定义也非常鸡肋

——“The Basic Software (BSW) provides the infrastructural(schematic dependent and schematic independent) functionalities of an“Electronic Control Unit”.”，

无非就是把Basic一词换成了Infrastructure，没有实质内容（此处仅指概念上，AUTOSAR标准所定义的内容当然是非常多的）。所以目前每个开发组织对于基础软件的理解细究起来其实并不完全相同。一个非常典型的例证就是实际开发过程中底软团队和应用层开发团队之间经常就某个功能应该由谁来开发而争个不休，比如对某个开关信号的Debounce操作。

其实，AUTOSAR标准所定义的基础软件是各家会员单位基于自己对基础软件的理解相互沟通妥协后的结果，是各家会员单位具有普遍共识的部分。除此以外，还有大量的基础软件模块并没有被标准化。

以最常见的MCU驱动（Mcal）为例，AUTOSAR标准中仅对GPT、Watchdog、Flash、CAN、SPI、ADC、Port等MCU外设驱动进行了标准化，如下图中橙色部分所示。而MCU其它常见的外设，如I2C、MSC、DMA、UART、MPU、EMM、GTM等许多模块并没有被标准化，如下图中灰色部分所示。

BMW和Bosch分别是九大核心成员中OEM和Tier1的代表。我们来看下他们对于基础软件的理解。

BMW尽管是一家OEM，但其软件开发能力却毫不逊色，这也是为什么它能牵头推动AUTOSAR标准的制定。BMW在集团范围内定义了名为BSP（BMW Software Platform）的标准软件平台，这个平台主要包括BMW AUTOSAR Core（简称BAC）和adaptive BMW AUTOSAR Core（简称aBAC）。在这里面，除了常规的AUTOSAR标准中所定义的内容，还包含有用于软件更新的Bootloader、信息安全增强软件包、以太网诊断扩展包等众多独门秘技。这些内容以企标或软件模块的形式传递给供应商，由供应商进行实现或集成。

Bosch作为汽车电子领域常年排名世界第一的零部件供应商，一直在引领着汽车技术的进步，在汽车基础软件方面其实也毫不例外，只是从来没有专门拿出来说而已。Bosch早在2005年左右就已经形成自己较为成熟的基础软件，当时称为Core Software，它主要包含Base System和Diagnosis System 两大部分，其中前者主要包含硬件相关功能组件，如OS、启动管理、复位管理，刷新用Bootloader、硬件封装模块、服务函数库、标定与测量驱动等，而后者主要包含常规通信、诊断通信、故障管理、网络管理、网关等功能组件。如今AUTOSAR标准中所提及的复杂驱动当时并不属于Core Software，后来，随着软件架构的不断发展，Bosch对于基础软件范围的定义也持续进化。如今，Bosch的汽车基础软件虽然也大多采用了AUTOSAR标准，但在标准之外，仍然存在远超标准内容的功能组件，尤其是在功能安全、信息安全、外设驱动、Ethernet等关键核心功能领域。

由此可见，对于基础软件的具体内涵，目前各家都有自己的定义，AUTOSAR所定义的内容更多的只是各家的共性部分。如果非要给基础软件下一个定义的话，倒是可以参考国内AUTOSEMO组织在《中国汽车基础软件发展白皮书1.0》中的描述：

汽车基础软件是用于实现汽车系统软硬件解耦，且与用户应用功能无关，但为应用功能提供一系列服务的支撑软件集合。

对于不熟悉汽车基础软件的人而言，这种定义可能还是过于抽象。如果要用一种形象的方式解释什么是基础软件，本人认为可以将基础软件比作人体的神经系统，相对应地，控制器硬件可以理解为身体，而应用软件可以理解为大脑。如下图所示。

以AUTOSAR架构为例：

• 系统技术栈部分可以理解为负责控制 新陈代谢 的神经

• 存储技术栈可以理解为负责 记忆 的神经

• 通信技术栈可以理解为我们的 听觉和语言 神经

• IO和复杂驱动技术栈可以理解为负责 感觉和运动 的神经

举个例子，应用软件准确计算出了某个结果，希望驱动某个执行器开启或关闭但控制器却没有发出用于控制执行器的物理信号，而此时控制器硬件没有任何问题，这很像一个人想活动四肢，但却因为神经系统出现问题而动弹不得。

上图是本人总结的传统汽车基础软件全景图。其中橙色的模块是AUTOSAR标准已涵盖的模块，而灰色的模块则是AUTOSAR尚未涉及的模块或功能包。需要说明的是，归入复杂驱动中软件从严格意义上来说，并不都属于复杂驱动，只是它们尚未被标准化，而暂时寄存在这里而已，如Hypervisor、功能安全、信息安全、高级以太网驱动、硬件加速模块驱动等。

那这些尚未被AUTOSAR标准化的内容占比有多少呢？不同的组织或许有不同的答案，如果对标Bosch，占比则不低于50%！

综上所述，汽车基础软件没有严格的定义，但可以明确的是，AUTOSAR不等于基础软件，基础软件的范畴要远超AUTOSAR标准中所定义的内容，二者不能划等号，它们的关系更像是早餐与豆浆油条的关系。AUTOSAR只是标准化了各家会员单位的共识部分，各家的还有很多“独门秘籍”并没有拿出来标准化。

对于组织而言，按照AUTOSAR标准只能开发出或采购到自家产品所需的部分基础软件模块，一定还有需要额外自行开发的基础软件；在实际项目中，必须明确基础软件的具体范围，而不能描述的过于笼统或者简单的与AUTOSAR划等号。否则，我们的项目将每天都有很多“意外”，很难“On Time，On Spec，On Cost”地交付。

对于个人而言，基础软件除了AUTOSAR以外，还有众多待研究和开发的地方，而这些尚未标准化的内容往往是具有更高价值的功能，因此我们有充足的个人职业发展空间，而不会让自己局限为一个简单的所谓的“工具人”，除非我们自我设限。

或许在接下来我们了解了汽车基础软件的发展历史后，我们会更加充满信心。

03.

汽车基础软件的起源与演进

欲知大道，必先为史。本节重点谈谈汽车基础软件的起源与演进。汽车基础软件不是随着汽车电子控制器一起诞生的，而是伴随着控制器功能日益复杂而逐渐形成的。早期的汽车电子控制器由于功能较少，软件比较简单，并没有基础软件的说法。随着控制器中软件功能的日益增多，软件架构设计的重要性日益凸显，如何提高软件的复用率，避免重复开发，提高开发效率受到越来越多的关注。

首先，国际领先的汽车电子控制器研发组织是汽车基础软件的创造者。

不仅Tier1，还有OEM，因为纵观全球汽车零部件格局，汽车零部件公司大致分两种：一种是创立之初就是独立零部件厂商；另一种则是诞生于汽车整车厂体系下。前者比如博世、麦格纳，后者比如电装、德尔福。

上世纪八九十年代，在领先的电子控制器研发组织内，控制器中的软件逐渐被细分为若干相对独立的模块，从最顶层看，整个系统的软件逐渐被分为与产品功能直接相关的应用软件和不直接相关的基础软件两大部分，从而使得研发组织内部的各个产品之间和同一产品的不同代系之间的软件复用率大幅提升，减少重复开发。

举个例子，下图展示了Bosch在2010年左右设计的同时兼容传统发动机控制和新能源汽车电机控制的软件架构。其中上半部分为应用软件ASW，而下半部分可以理解为基础软件，其中包括HDS（硬件相关软件）、Dia（诊断软件）、ComSys（通信软件）、DE（传感器与执行器等设备封装软件）、CDrv（复杂驱动）五个部分。这一结构已经很接近我们今天所看到的AUTOSAR分层架构了，而这一软件架构其实早在2005年左右在Bosch内部就已非常成熟，并广泛地应用于发动机、变速箱等控制器。

Bosch动力总成控制器软件架构图

来源：论文《Experiences from a Large Scale Software Product LineMerger in the Automotive Domain》

其次，欧洲整车厂是基础软件标准化的推动者。

与国内的整车厂不同，欧美的整车厂大多拥有较强的电子控制器自主开发能力。随着汽车上所集成的电子控制器数量持续增多，整车电子电气系统分布式网络控制（Networked and Distributed）的特征日益明显，整车厂们发现集成的难度越来越大。德国和法国的OEM及其供应商通过调查发现，大量的工作花费在了开发和调试操作系统、通信和网络管理以及输入输出设备驱动等软件上，以确定应用功能表现异常的原因。也就是说为了分析系统功能异常的原因，花费了大量精力在基础软件层面上。同时发现，各家控制器供应商都投入了巨大的费用用于开发和维护与应用功能无关的软件，即重复开发基础软件，且各家为应用软件提供的基础软件在接口和协议方面相互不兼容。

为此，在1995年，欧洲整车厂们牵头制定了汽车基础软件领域的首份行业标准：OSEK/VDX标准。

OSEK/VDX组织的目标是开发一套标准的API，从而减少应用软件重复开发带来的工作量并提高应用软件可移植性和复用率。其结果是产生了三个相对独立的标准：操作系统、通信和网络管理。在今天看来，这些被标准化的内容是汽车基础软件的重要组成部分，但还远不够完整。以I/O技术栈为例，当时OSEK/VDX组织已意识到并没有对这部分开发对应的标准，而采用了推荐各家在公司内部自行开发自家标准的方式来处理这一问题。

从技术和商业两个方面来看，OSEK/VDX标准在一定程度上满足了整车厂最初的目标，但仍然不够。随着汽车电子的发展，这些领先的整车厂逐渐将重点聚焦在与用户使用体验直接相关的应用功能软件，以打造品牌的差异性，硬件和基础软件则交由供应商提供，产生了OEM和Tier1联合开发控制器软件的模式（我们将在下一节介绍与此相关的更多信息）。

为了使得这些自主研发的应用软件方便地集成到不同控制器供应商的产品中，打破供应商的制约，在2003年，进一步成立了AUTOSAR组织，制定了有史以来定义最全面的基础软件标准——AUTOSAR标准，最大程度地实现了应用功能软件与控制器硬件的解耦，也就是我们现在常说的“软硬件解耦”。AUTOSAR组织的目的其实和OSEK/VDX组织差别不大，只是AUTOSAR在内容方面进行了大幅扩展，在细节方面进行更具体的定义，以期更好地满足整车厂的愿望：

• 自主开发车辆应用软件，实现差异化竞争；

• 自主开发的应用软件可以方便地在不同供应商的控制器之间移植；

• 自主开发的应用软件可以方便地在不同车型之间移植；

• 自主开发的应用软件可以方便地在不同应用场景之间移植；

图：AUTOSAR 愿景

需要特别指出的是，以上这些愿望都是整车厂的愿望，而不是供应商的。因此在早期，Bosch、Conti等零部件巨头对AUTOSAR并没有热情，甚至是抗拒。这使得AUTOSAR标准早期的推广并不顺利，直到发展到R4.0版本才相对较为成熟，这也是当前业内普遍采用的版本。以Bosch为例，其产品从2015年左右才开始大规模采用AUTOSAR标准开发基础软件。同时，直到近几年，在宝马等车厂的一些项目中，Bosch的产品仍然因为对AUTOSAR的支持能力不足而没有获得项目定点。

最后，开源 —— 基础软件标准化的新尝试。

AUTOSAR标准虽然已经定义的非常细，但毕竟仍然只是个标准，而不是具体的实例。其所倡导的“在标准上合作，在实现上竞争”的理念，在实际落地过程中也出现了各种各样的问题，导致各家基于同一个标准开发的AUTOSAR产品彼此之间并不兼容，使得整车厂们的愿望被大打折扣。Bosch对此深有感触，并牵头发起了一个类开源项目：COMASSO，以期联合各方共同开发一套符合AUTOSAR标准的基础软件及其工具。其背后的动机可参考如下来自其官网的描述。

After 10 years of AUTOSAR development we observe theexistence of various implementations without competition relevantdifferentiation, causing integration effort in case of SW exchange and reuse.We want to reduce this higher integration effort in case of SW exchange andresuse by supporting a common implementation of the AUTOSAR standard. Thisprovides the members a higher degree of freedom to concentrate on innovation.

从2013年Bosch和ETAS共同成立COMASSO开始，这个项目已运行近十年，20多家组织加入，不过可能受制于开源模式不够彻底，目前依然不温不火，知名度很低，影响力有限。但这未尝不是一种新的尝试，或许在未来的某个恰当时机，将犹如Linux一样被普遍采用。

综上所述，汽车基础软件的诞生是汽车软件日益复杂的必然结果，符合软件发展的客观规律，是各个研发组织自我进化的自然结果。而汽车基础软件的标准化则体现了汽车行业的特点，是由整车厂牵头推动才形成的，体现了整车厂的意志，对于供应商而言，由于自己的一部分业务被整车厂收回了，因而其实是弊大于利。

展望未来，汽车基础软件的标准化是继续走下去，还是出现类似手机行业Android和苹果iOS等不同阵营的操作系统实例，以及是否会出现安全可靠的开源解决方案，让我们拭目以待。

04.

基础软件支持“软件定义汽车”的早期形态

面对日益复杂的汽车软件，尤其是域控制器等中央计算平台，仅凭一家之力难以完成，共建软件开发生态，联合多家生态伙伴共同开发是“软件定义汽车”实现的必由之路。而这种多家联合开发控制器软件的模式其实在行业内早已有之，尤其是国外OEM，早在上个世纪就开始了“软件定义汽车”的探索，只不过那时的软件主要聚焦车辆的性能，而今天的软件更多强调终端消费者的使用体验，即所谓的“千人千面”。了解这些早期“软件定义汽车”理念的具体实现方法对于实现今天的“软件定义汽车”无疑具有重要的指导意义。本节介绍本人所了解到的传统控制器中存在的各种软件联合开发模式，希望能有助于国内同行以更务实的态度推进“软件定义汽车“的落地，少走弯路。

相对于软件和硬件均由供应商完全开发的传统控制器开发模式，控制器软件由两方及以上共同进行开发的项目都可认为属于软件联合开发模式，Bosch还专门将这种开发模式定义为Software-Sharing。

为了体现自己的技术优势和产品特性，OEM通常会对直接影响车辆功能的应用软件提出个性化需求，避免全部采用供应商的默认方案。因此软件联合开发模式通常在OEM和Tier1之间展开。而这种合作开发，离不开安全可靠的基础软件的高效支持。

OEM参与软件开发程度的深浅以及双方对开发相关的一系列数据交互形式，对于实际合作方法的影响巨大，必须区别对待。以下以常见的针对应用软件的联合开发为例，根据联合开发程度由浅到深，划分为五种模式，依次进行介绍。

联合开发模式一

该模式是指OEM以非源代码的形式，如Simulink模型或UML模型，提供一小部分应用层功能的控制策略详细需求，源代码仍由供应商进行开发，且供应商需要开发双方软件之间的交互接口层，如图中灰色部分所示。

这一模式是程度最小的一种软件联合开发模式。对OEM而言，无需掌握软件开发能力，也能够提出自己对某部分控制功能的独特见解，使得最终的系统功能有别于供应商提供的标准解决方案。模式一适用于在个别应用层功能点采用自主方案，同时具备功能建模能力但不具备软件开发能力，软件仍由供应商开发，且同意自主方案对供应商公开的OEM。

联合开发模式二

该模式是指OEM以目标代码（软件编译之后的Object文件）的形式提供一小部分应用层功能的控制策略。

相对于模式一，由于合作方交互过程中看不到具体的控制策略，因此这一模式可以保护OEM的自主创新不泄露，不过同时要求OEM具备软件开发能力，这对于双方的合作提出了更高更细的要求，比如提前约定好各自的函数与变量的命名空间，编译器的具体版本等，而且由于供应商得不到源码，导致软件调试难度增大。模式二适用于在个别应用层功能点采用自有方案，同时具备功能建模能力和一定的软件开发能力，软件集成仍由供应商负责，且自主方案要求保密，不对供应商进行开放的OEM。该模式在发动机控制器领域较为常见。

联合开发模式三

该模式是指OEM除了自身参与应用层软件开发以外，还邀请了其它若干家供应商提供部分应用层软件，大部分应用层软件均不再使用控制器供应商的标准方案，并且最终的软件集成由OEM进行。这就使得OEM能够将各家供应商之所长集于一身，更大程度地掌控系统控制策略，同时又能依托控制器供应商深厚的硬件、软件、功能安全和信息安全等开发能力和强大的生产能力。

相对于模式二，涉及的合作方更多，合作各方直接的接口数量大幅度增加，且都要求访问基础软件的提供的接口，因此合作的难度大幅增加，同时对于OEM的软件开发及系统集成与测试能力都提出了更高的要求。模式三适用于在较多应用层功能点采用自有方案和第三方方案组合的形式，同时具备功能建模能力和较强的软件开发能力，软件集成仍由供应商负责，且自主方案和第三方方案要求保密，不对供应商进行开放的OEM。

联合开发模式四

该模式是指OEM开发大部分应用层软件，仅有一小部分应用层软件继续采用控制器供应商的标准方案。该模式的合作方法与模式三基本类似，对于OEM的自主开发能力要求大幅提高，但由于不涉及其它供应商，因此项目合作难度有所降低。该模式能够使OEM重用其自身已有的较为全面的能力，基本掌控系统控制策略。

模式四适用于大部分应用层功能采用自有方案，同时具备很强的软件开发能力，能够负责软件集成，且自主方案要求保密，不对供应商进行开放的OEM。

联合开发模式五

该模式是指OEM开发全部应用层软件，控制器供应商仅提供硬件和基础软件（含复杂驱动）。该模式的合作方法与模式四基本类似，但由于不涉及其应用层软件之间的交互，因此项目开发难度有所降低。该模式同样能够使OEM重用其自身已有的较为全面的能力，并完全掌控系统控制策略。模式五适用于全部应用层功能采用自有方案，同时具备较强的软件开发能力，能够负责软件集成，且自主方案要求保密，不对供应商进行开放的OEM。该模式在变速箱控制器、整车控制器等领域较常见。

总结

通过以上对各种软件合作开发模式的细分介绍可见，不同的合作模式所支持的“OEM自由度”是不同的，同时自由度越高，所需的软件开发能力要求也越高，当然投资也会更大。下表以OEM视角，从多个角度对各种软件联合开发模式进行了定性对比。实际项目中，OEM（或者仅负责应用功能开发的组织）可以根据自己所期望的“自由度”，结合自身技术能力和公司资源情况，并考虑对知识产权的保护，量力而行，选择最适合自己的联合开发模式，稳妥推进自己“软件定义汽车”的梦想。

最后，需要强调的是，基础软件对于控制器软件联合开发的影响极其重大。这是因为在联合开发过程中，基础软件决定了整个系统的状态管理及任务调度、内存模型、底层API接口、开发与调试工具、软件构建方法（各类文件解析与编译）等整个软件开发所依赖的基础设施。

因此，OEM们最头疼的就是由于各家供应商的基础软件在上述各个方面的差异而导致的巨大的移植工作量。这种问题与手机领域中一个APP通常至少要开发Android和iOS两个版本在本质上是一样的。

讲到这里，相信大家就明白了为什么AUTOSARLogo中间那个字母“O”最特殊，绝不是仅仅出于设计美感的考虑，而是强调Open，开放！逆向思考一下：谁不开放了？谁想开放？自然是OEM希望Tier1们对自己更加开放。于是，BMW等一众OEM强拉着Bosch等Tier1巨头对基础软件进行标准化，从而形成了以架构、应用接口和方法论为三大支柱的AUTOSAR标准，以期减少OEM软件的移植工作量。

汽车的基础软件还在持续不断的发展，AUTOSAR将只有进行时，没有完成时。

05.

关于《汽车软件开发交流公益社区》

汽车软件领域浩瀚无边，而且还在持续扩张，为此，我们创建了一个专门面向国内汽车软件工程师的交流社区，域名：www.basicsw.cn（即将开通）, 目前已开启公测通道（http://175.24.230.121/），欢迎点击文末“ 阅读原文 ”开始体验。

关于社区创办的目的，我们总结了以下三点，希望我们的初心能够得到大家的认同和支持。

1. 促进交流与分享，加速个人成长

随着汽车电动化、智能化、网联化的发展，以及“国产替代“概念的推动，汽车行业上至整车厂、下至芯片、开发工具供应商，甚至猎头等人才服务机构一片热火朝天。汽车行业百年未有之大变局带火了汽车工程师，尤其是汽车软件开发工程师，甚至原本做金融、财经业务的猎头也大批量转做汽车猎头，而被猎最多的就是汽车软件工程师。许多人正跑步加入汽车软件开发的行列，或为高薪、或为未来、或为情怀。

然而面对AUTOSAR、ASAM、OSEK、ISO26262、ASPICE等一大堆汽车行业百年积淀下来的专业知识，突然觉得自己陷入了一片无边无际的汪洋大海，少有人带教，看不到尽头，找不到方向。与此同时，一大批热心的汽车软件行业老兵通过知乎、微信、CSDN等平台积极分享着自己的宝贵经验。然而这些知识”碎片化“特征明显，缺少归纳和归类，也缺少互动。

因此，我们希望通过论坛这种“古老”的形式，为大家提供专注于汽车软件这一细分领域的自由交流与分享的场所，帮助大家共同成长。

2. 打破组织边界，凝聚全行业人才的智慧

国外经常在报告中使用“fragmented”一词来描绘中国汽车市场的特点，国内汽车产业的分散特征由此可见一斑。由于产业分散，彼此间缺少合作，没有形成生态，导致人才资源分散，而人才资源分散对于核心技术的掌握是致命的，使得大家疲于学习国外已有的技术，无暇进行更深层次的创新。

而伴随着智能网联汽车的发展，诞生了越来越多的汽车类企业，使得原本就稀缺的汽车软件人才更加分散，每家都有数量远不及预期的少数汽车软件开发人才。

Therefore, we hope that through the virtual organizational form of the forum, we can break down organizational boundaries and bring together industry talents, so that everyone can become a beam of light that illuminates others and promote the accumulation of knowledge.

3. Deeply understand the characteristics of automotive software development and maintain awe without losing courage.

At the beginning of the book "The Myth of the Man-Moon", the author describes a scene: the development of large-scale systems in the past few decades is like such a tar pit, in which many large and powerful animals struggle violently. Most of them develop working systems—but only a very small number of these projects meet goals, schedules, and budgets. Various teams, large and small, complex and capable, were submerged in the tar pit one after another...

In today's era of "software-defined cars", such scenes are still being played out in software organizations large and small. Software development is inherently complex, and automotive software development is even more complicated. On the surface it may seem like no single problem is causing difficulty and each can be solved, but when they become entangled and accumulate, the team becomes slower and slower. Team members are involved in various discussions every day and rarely write a few lines of code. Everyone seems surprised at how troublesome the problem is and has difficulty seeing what it is. And if we want to solve these problems, we must first understand it.

I hope that the questions and answers will help everyone gain a deeper understanding of the high real-time, high reliability, high security, hardware cost-sensitive, cross-disciplinary and cross-domain requirements of automotive software development, high software integration requirements, and long maintenance cycles. , strict regulatory requirements and a series of characteristics. In the actual development process, we can maintain our respect for tradition without losing the courage to innovate.

Each icon represents one million lines of code

Communicate, share, and grow. I hope every automotive software person can feel the professional joy here~

Scan the QR code to add the author on WeChat

Click " Read the original text " below to start experiencing the " Automotive Software Development Community "

References :

1. China Software Industry Association, "White Paper on the Development of China's Basic Software Root Technology", 2021

2. AUTOSEMO, "China Basic Software Development White Paper 1.0", 2020

3. Advanced Engineering Intelligence, "Automotive Basic Software "All Living Things"", 2022

4. Bread Finance, "The Ice Zone of China's Automobile Industry: It's Easy to Make Complete Vehicles, But Hard to Make Core Components", 2018

5. www.autosar.org

6. www.osek-vdx.org

7. www.comasso.org

8. Bosch, Experiences from a Large Scale Software Product Line Merger in the Automotive Domain, 2011

9. Fu Baojun et al., "Application of Software Cooperative Development Model in the Field of Automotive Electronics", 2018

10. GM, "TheNew General Motors Diesel Engine Management System.pdf", 2011