本文来自《汽车软件开发社区》的系列文章，全文一万余字，主要分为以下四个部分：

　　一直以来，操作系统、数据库、中间件、编程语言及编译器等基础软件领域是我国软件产业的薄弱环节，近几年更是因为一些“卡脖子”事件而备受关注。其实，不同的产业门类有各自不同的基础软件，如PC行业、手机行业、工业控制、云计算等都有自己领域的基础软件，汽车行业也不例外，也有自己专属的一套基础软件。

　　非常可喜的是，相对于PC、手机等行业基础软件几乎完全依赖国外的状况，汽车行业的基础软件在近几年受到了从上到下极高的重视，并取得了一定的实质性进展，大有弯道超车，一雪前耻的逆转势头。

　　在汽车软件领域，随着汽车电子技术的不断发展，尤其是近几年在汽车产业“新四化”趋势的带动下，软件对于汽车的重要性日益凸显，“软件定义汽车”的理念逐步成为行业共识。

　　同时，汽车行业对于新一代集中式E/E架构中的域控制器或车载计算平台所需的基础软件还存在空白，还没有类似PC行业的Windows、手机行业的Android等可供各家整车厂或供应商使用的通用操作系统及中间件，而从事软件的人都知道：得操作系统者得天下。

　　因此，大家不再仅仅关注于应用软件的开发与创新，同时更加重视车载操作系统、中间件、AUTOSAR等汽车基础软件的开发与创新，国内汽车基础软件领域出现了空前的繁荣。

　　诞生了一大批以汽车基础软件为主营业务的企业，如东软睿驰、普华基础软件、经纬恒润、中科创达、伊势智控等，其中很多基础软件产品已实现一定规模的量产。

　　出现了提供包括基础软件在内的“全栈”汽车软件解决方案的大型汽车软件公司，如零束、华为；

　　获得了行业VC风投机构越来越多的青睐。去年10月，东软睿驰拿到国投招商、德载厚合计6.5亿元人民币投资，公司估值超过60多亿人民币。

　　由中汽协牵头，于2020年7月成立了国内首个汽车基础软件领域的生态联盟AUTOSEMO，旨在为中国汽车行业提供面向下一代汽车的标准化的基础软件架构、方法论和应用程序接口标准。

　　向来在各行各业都薄弱的国产基础软件，这次能在汽车行业中逆转么？我们不妨先看下以往其它行业基础软件发展缓慢而没有突破的原因。根据中国软件行业协会在2021年发布的《中国基础软件根技术发展白皮书》和工信部在2017年发布的《信息产业发展指南解读：基础软件和工业软件》两篇文章，国产基础软件发展所存在的主要问题有：

　　很遗憾，在本人看来，这三个问题对于国内当前的汽车基础软件行业同样存在。以下我们以汽车基础软件领域大家耳熟能详的AUTOSAR软件为例进行分析。

　　因为大部分人是近几年通过AUTOSAR来才开始了解汽车基础软件的，在此之前我们对汽车基础软件的了解极少。

　　汽车中各个控制器的基础软件通常由Tier1开发完成，而汽车核心零部件一直是中国汽车行业的坚冰地带，国内汽车零部件公司在行业“新四化”之前，大多以机械件为主，涉及到电子控制的核心零部件极少。国内最早接触基础软件的开发人员大多在Bosch、Conti等外资零部件企业，而且受制于外资企业对核心技术的保护，很多工程师甚至都看不到控制器中的软件源代码。

　　插播个故事：本人2009年曾在一家外资的座椅加热控制器研发部门实习，当时由于国内拿不到源代码，而又急需修改一个重要参数进行产品试验，无奈下只能分析二进制可执行文件（软件编译后生成的Hex文件），通过类似反编译的方式，找到了参数在文件中的位置，直接修改了该参数（庆幸程序中当时没有今天的安全刷新、安全启动等一系列信息安全机制~~），从而保证了产品试验能够按时完成。可见，当时国内工程师连一个简单的座椅加热控制功能软件源代码都看不到。

　　直到近几年，国内新能源和自动驾驶领域诞生了众多初创公司进行相关零部件的自主研发，Vector、ETAS等国外企业适时推出符合AUTOSAR标准的基础软件产品供其使用，才使得国内工程师有机会真正接触汽车基础软件，以至于很多人误认为基础软件就是AUTOSAR，AUTOSAR就是基础软件。而前面提到的几家国产基础软件供应商，其开发人员大多也是参考AUTOSAR标准开发基础软件，之前毫无相关经验。

　　可想而知，对于这些企业而言，要实现汽车基础软件的产品化和工程化会有多么困难。以产品化为例，由于开发人员缺乏实际开发和应用经验，仅凭一堆AUTOSAR标准文档开发产品，面对客户需求时不能合理引导客户而一味地满足客户千奇百怪的需求，难以形成自己的标准化产品，很容易让自己走入死胡同。

　　从前面一点其实也不难看出来汽车基础软件领域专业人才的极度匮乏。而近几年行业内如雨后春笋般出现的大量公司对基础软件人才如饥似渴，使得基础软件工程师身价倍增，流动率极高，不利于个人能力的成长。而从企业角度看，严重不足的开发人员难以支撑企业实现自己的宏图大业。

　　在Bosch，截至2020年，约有1200名专职从事汽车基础软件开发的软件工程师，按照去年Bosch对外发布的信息，其与ETAS整合后形成的“通用汽车软件”开发团队将达到2000多人。在Vector、KPIT等第三方软件供应商，其汽车基础软件开发团队规模也在800~1000人左右。而国内的基础软件企业即使满打满算，大多只有100人左右，有些甚至不足50人，规模最大也没超过200人。就算我们的工程师能力与国外相当，所开发的产品也会打2折，甚至1折。

　　国内汽车产业本就具有非常明显的分散特征，而这一特征在汽车基础软件领域也正在上演，以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为代表的面向智能网联汽车的新一代汽车基础软件有所启发。

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

　　无非就是把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标准已涵盖的模块，而灰色的模块则是AUTOSAR尚未涉及的模块或功能包。需要说明的是，归入复杂驱动中软件从严格意义上来说，并不都属于复杂驱动，只是它们尚未被标准化，而暂时寄存在这里而已，如Hypervisor、功能安全、信息安全、高级以太网驱动、硬件加速模块驱动等。

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

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

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

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

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

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

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

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

　　与国内的整车厂不同，欧美的整车厂大多拥有较强的电子控制器自主开发能力。随着汽车上所集成的电子控制器数量持续增多，整车电子电气系统分布式网络控制（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在内容方面进行了大幅扩展，在细节方面进行更具体的定义，以期更好地满足整车厂的愿望：

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

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

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

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

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

　　面对日益复杂的汽车软件，尤其是域控制器等中央计算平台，仅凭一家之力难以完成，共建软件开发生态，联合多家生态伙伴共同开发是“软件定义汽车”实现的必由之路。而这种多家联合开发控制器软件的模式其实在行业内早已有之，尤其是国外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将只有进行时，没有完成时。

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

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

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

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

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

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

　　因此，我们希望通过论坛这种虚拟的组织形式，打破组织边界，将行业人才汇聚起来，让每个人都成为照亮他人的一束光，促进知识的沉淀。

　　在《人月神话》一书的开头，作者描绘了这样一幅场景：过去几十年的大型系统开发就犹如这样一个焦油坑，很多大型和强壮的动物在其中剧烈地挣扎。他们中大多数开发出了可运行的系统——不过，其中只有非常少数的项目满足了目标、时间进度和预算的要求。各种团队，大型的和小型的，庞杂的和精干的，一个接一个淹没在了焦油坑中……

　　在今天这样一个“软件定义汽车”的时代，这样的场景仍然正在大大小小的软件组织中上演。软件开发本就是复杂的，而汽车软件的开发更是异常复杂。表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢。团队成员每天都陷入各种讨论会，难得写几行代码。对问题的麻烦程度，每个人似乎都会感到惊讶，并且很难看清问题的本质。而我们要想解决这些问题，就必须先去理解它。

　　希望在一次次提问和解答中，有助于大家深刻理解汽车软件开发所要求的高实时性、高可靠性、高安全性、硬件成本敏感、跨学科跨领域、软件集成要求高、维护周期长、法规要求严等一系列特点。在实际的开发过程中，既能保持对传统的敬畏，又不失创新的勇气。

　　声明：本文由入驻搜狐公众平台的作者撰写，除搜狐官方账号外，观点仅代表作者本人，不代表搜狐立场。