编译autosar

① 嵌入式操作系统的分类

嵌入式操作系统的分类 篇1

第一类、传统的经典RTOS：

最主要的便是Vxworks操作系统，以及其Tornado开发平台。Vxworks因出现稍早，实时性很强(据说可在1ms内响应外部事件请求)，并且内核可极微(据说最小可8K)，可靠性较高等，所以在北美，Vxworks占据了嵌入式系统的多半疆山。特别是在通信设备等实时性要求较高的系统中，几乎非Vxworks莫属。Vxworks的很多概念和技术都和linux很类似，主要是C语言开发。像Bell-alcatel、Lucent、华为等通信企业在开发产品时，Vxworks用得很多。但Vxworks因价格很高，所以一些小公司或小产品中往往用不起。目前很多公司都在往嵌入式Linux转(听说华为目前正在这样转)。但无论如何，Vxworks在一段长时间内仍是不可动摇的。与Vxworks类似的稍有名的实时操作系统还有pSOS、QNX、Nucleus等RTOS。

第二类、嵌入式Linux操作系统：

Linux的前途除作为服务器操作系统外，最成功的便是在嵌入式领域的应用，原因当然是免费、开源、支持软件多、呼拥者众，这样嵌入式产品成本会低。Linux本身不是一个为嵌入式设计的操作系统，不是微内核的，并且实时性不强。目前应用在嵌入式领域的Linux系统主要有两类：一类是专为嵌入式设计的已被裁减过的Linux系统，最常用的是uClinux(不带MMU功能)，目前占较大应用份额，可在ARM7上跑；另一类是跑在ARM9上的，一般是将Linux2.4.18内核移植在其上，可使用更多的Linux功能(当然uClinux更可跑在ARM9上)。很多人预测，嵌入式Linux预计将占嵌入式操作系统的50%以上份额，非常重要。缺点是熟悉Linux的人太少，开发难度稍大。目前很多教材和很多大学都以ucOS/II为教学用实时操作系统，这主要是由于ucOS/II较简单，且开源，非常适合入门者学习实时操作系统原理，但ucOS/II的缺点是功能有限，实用用得较少，所以要学习就应学直接实用的，比如uClinux就很实用。况且熟悉了Linux开发，不仅在嵌入式领域有用，对开发Linux应用软件，对加深操作系统的认识也有帮助，可谓一举多得。据说，目前Intel、Philip都在大搞ARM+LINUX的嵌入式开发，Fujitum则是在自己的处理器上大搞Linux开发。目前在嵌入式Linux领域，以下几个方面的人特别难找，一是能将Linux移植到某个新型号的开发版上；二是能写Linux驱动程序的人；三是熟悉Linux内核裁减和优化的人。

第三类、WindowsCE嵌入式操作系统：

Microsoft也看准了嵌入式的巨大市场，WinCE出来只有几年时间，但目前已占据了很大市场份额，特别是在PDA、手机、显示仪表等界面要求较高或者要求快速开发的场合，WinCE目前已很流行(据说有一家卖工控机的公司板子卖得太好，以至来不及为客户裁减WinCE)。WinCE目前主要为4.2版(.NET)，开发平台主要为WinCEPlatformBuilder，有时也用EVC环境开发一些较上层的应用，由于WinCE开发都是大家熟悉的VC++环境，所以学习Windows程序设计课程不会有多大难度，这也是WinCE容易被人们接受的原因，开发环境方便快速，微软的强大技术支持，WinCE开发难度远低于嵌入式Linux。对于急于完成，不想拿嵌入式Linux冒险的开发场合，WinCE是最合适了(找嵌入式Linux的人可没那么好找的)，毕竟公司不能像学生学习那样试试看，保证开发成功更重要。根据不同的侧重点，WinCE还有两个特殊版本，一个是MSPocketPC操作系统专用于PDA上(掌上电脑)，另一个是MSSmartPhone操作系统用于智能手机上(带PDA功能的手机)，两者也都属于WinCE平台。在PDA和手机市场上，除WinCE外，着名的PDA嵌入式操作系统还有PalmOS(因出现很早，很有名)、Symbian等，但在WinCE的强劲冲击下，Palm和Symbian来日还能有多长?据观察，目前在嵌入式平台上，LINUX是叫得最响，但还是WinCE实际用得更多。嵌入式LINUX可能更多地是一些有长远产品计划的公司，为降低成本而进行长远考虑。WinCE和多媒体(如MPEG技术)是微软亚洲工程院目前做得较多的项目领域之一，他们很需要精通WinCE的人。

嵌入式操作系统的分类 篇2

目前我国已推出一些应用比较成功的EOS产品系列。随着Internet技术的发展、信息家电的普及应用及EOS的微型化和专业化，EOS开始从单一的弱功能向高专业化的强功能方向发展。嵌人式操作系统在系统实时高效性、硬件的相关依赖性、软件固态化以及应用的专用性等方面具有较为突出的特点。EOS是相对于一般操作系统而言的，它除了是具备了一般的操作系统最基本的功能，比如：任务调度、同步机制、中断处理、文件功能之外的话，它还含有以下的特针：

(1)可装卸性：开放性、可伸缩性的体系结构。

(2)强实时性：EOS实时性一般较强，可用于各种设备控制当中。

(3)统一的接口：提供各种设备驱动接入。

(4)操作方便、简单、提供友好的图形GUI，图形界面，追求易学易用。

(5)提供强大的网络功能，支持TCP/IP协议及其它协议，提供TCP/UDP/IP/PPP协议支持及统一的MAC访问层接口，为各种移动计算设备预留接口。

(6)强稳定性，弱交互性：嵌入式系统一旦开始运行就不需要用户过多的干预，这就要负责系统管理的EOS臭有较强的稳定性。嵌入式操作系统的用户接日一般不提供操作命令，它通过系统调用命令向用户程序提供服务。

(7)固化代码：在嵌入系统中，嵌入式操作系统和应用软件被固化在嵌入式系统计算机的ROM中。辅助存储器在嵌入式系统中很少使用，因此，嵌入式操作系统的文件管理功能应该能够很容易地拆卸，而用各种内存文件系统。

(8)更好的硬件适应性，也就是良好的移植性。

国际上用于信息电器的嵌入式操作系统有40种左右。现在，市场上非常流行的EOS产品，包括3Corn公司下属子公司的PalmOS，全球占有份额达50%，Microsoft公司的WindowsCE不过29%。在美国市场，PalmOS更以80%的占有率远超WindowsCE.开放源代码的Linux很适于做信息家电的开发。

然而我们常见的嵌入式系统有：Linux、uClinux、WinCE、PalmOS、Symbian、eCos、uCOS-II、VxWorks、pSOS、Nucleus、ThreadX、Rtems、QNX、INTEGRITY、OSE、CExecutive.嵌入式操作系统的发展也必将带动新一轮的科技竞争。

嵌入式操作系统的分类 篇3

常见的嵌入式系统有这么多：

Linux、uClinux、WinCE、PalmOS、Symbian、eCos、uCOS-II、VxWorks、pSOS、Nucleus、ThreadX、Rtems、QNX、INTEGRITY、OSE、CExecutive、autosar......

什么是嵌入式操作系统?

嵌入式操作系统是一种支持嵌入式系统应用的操作系统软件，它是嵌入式系统的重要组成部分。嵌入时操作系统具有通用操作系统的基本特点，能够有效管理复杂的系统资源，并且把硬件虚拟化。

从应用角度可分为通用型嵌入式操作系统和专用型嵌入式操作系统。常见的通用型嵌入式操作系统有Linux、VxWorks、WindowsCE.net等。常用的专用型嵌入式操作系统有SmartPhone、PocketPC、Symbian等。

按实时性可分为两类：

实时嵌入式操作系统主要面向控制、通信等领域。如WindRiver公司的VxWorks、ISI的pSOS、QNX系统软件公司的QNX、ATI的Nucleus，很多汽车电子行业都是利用实时性很强的操作系统等。

非实时嵌入式操作系统主要面向消费类电子产品。这类产品包括PDA、移动电话、机顶盒、电子书、WebPhone等。如微软面向手机应用的SmartPhone操作系统。

嵌入式系统的设计和实现而言，基本上需要四种不同的工作：系统设计工作，硬件设计工作，驱动程序和操作系统移植工作和应用程序设计开发工作。

1、 系统设计工作

在系统的设计阶段，系统分析师将根据需求确定系统的硬件的基本构成，根据系统的需求选择使用那种处理器，使用哪种操作系统，使用那些软件开发工具。系统分析师往往是较为完整的参与过嵌入式系统设计的全过程，对于系统应用的行业较为了解，对于嵌入式系统本身的开发流程十分清楚的人。

2、硬件设计工作

系统硬件设计人员需要根据系统分析师的设计结果，进行硬件原理图的设计。通常需要硬件设计人员熟悉嵌入式系统的硬件构成。硬件设计人员需要了解常用的嵌入式系统处理器，存储器(Flash，SDRAM)，以太网MAC芯片，音频/视频编解码芯片，电源管理芯片，总线接口电路(USB,PCI)，液晶显示模块，可编程逻辑器件(FPGA/CPLD)，无线网络通信模块(Bluetooth,WLAN,GPRS)等硬件电路构成元素的基本工作原理，连接使用方法，使用注意事项，基本调试方法等内容。在网络上能找到很多公司的评估板的原理图，对于这些原理图要仔细研究，摸清处理器同存储器，网卡，液晶模块等器件的连接方法和原因。通过对这些电路的研究，能够较快地了解整个嵌入式系统的构成，这些电路同实际产品中的电路虽有一定差别的，特别是对于手持设备，但这些差别不影响初学者学习嵌入式系统的硬件设计基本构成。

1)学习Linux系统安装、常用命令、应用程序安装。

2)学习Linux下的C编程、这本书必学《UNIX环境高级编程》、《UNIX网络编程》，RechardStevens写的，C高手大都学习过《C和指针》、《C缺陷与陷阱》、《高质量C/C++编程指南》、《C专家编程》、《TheCprogrammingLanguage》

3)程序员大都要学：数据结构，嵌入式程序员数据结构必学！

4)底层开发人员大都要学：微机原理、计算机体系结构，嵌入式开发人员必学！

5)单片机可以让一个从事软件开发的人了解和如何操作硬件，有必要学，因为一开始就从ARM入手，不太现实！

6)ARM体系结构，其中有汇编。

7)数字电路有必要学习，不然你在做底层开发时真的会不知道怎么看原理图，起码也得懂与或门吧。

8)ARM+Linux应用程序开发。(前提是要有开发板)

9)要做底层开发，就必须知道软硬件之间是如何衔接和配合工作的，那么电子技术应该要好好学习了，很多时候会用到模拟电路知识，这是区别好手与菜鸟的不同之处之一。

10)Linux下的汇编要学，这样你才能真正了解你写的程序是如何在一个特定的硬件上跑的。这是区别好手与菜鸟的不同之处之二。

11)TCP/IP协议栈要学，所有的嵌入式高手都得掌握的东西，这是区别好手与菜鸟的不同之处之三。

12)有了这些东西，拿下Linux驱动已经不再话下，需要你去学习Linux内核源代码和Linux驱动程序设计，这是一个技术升华。

13)音频、视频的解码译码技术你得学。

14)各种IC，各种bootloader你能够参与其开发设计。

15)自行设计开发新产品，新技术。

学到这个地步差不多要花个3年的时间吧。但是后面的路该怎么走呢?嵌入式系统性的东西搞了一个产品之后，基本上一些套路都摸清楚了。

不同的行业，对于系统的要求是不一样的，比如汽车行业，航空航天行业等一些高精度，高安全的需要对实时性要求非常之高，对于安全性和可靠性的要求非常严格。而有些行业比如消费类产品，娱乐类的，生活用具方面的对于用户体验是不一样的，数码产品对于一些图像声音的处理，要求更高，需要高清，高品质的。而对于一些通信设备类对于网络的应答数据传输要求就非常严格，等等。这些根据不同的要求，选择符合自己的操作系统，能对开发工作有更大的帮助。

嵌入式操作系统的分类 篇4

DOS

微软一开始选用了派特森的Q-DOS“QUICKANDDISKOPERATINGSYSTEM”为基础然后再扩充功能而成MS-DOS，主要是采用由IBM提供的使用8088微处理器的计算机作开发平台，它是以16字节单人单工操作系统，特别适合一些功能简单装置使用。

WindowsCE

虽然微软Windows系统已经称霸了PCDesktop环境。但是对于嵌入式系统这块大饼，微软也是垂涎已久，桌上型的Windows桌业系统对于嵌入式系统来说自然是太过于肥大的产物，于是微软推出精简版的WindowsCE作为进攻嵌入式系统的主力。目前主要应用于PDA上头，但是跟微软一系列Windows系统一般，WindowsCE也承袭了原有的缺点：耗系统资源、不稳定、效率不佳等等。毛病实在太多，后来将整个架构重新改写后推出WindowsCE3.0版，或称为PocketPC。改版之后的确改进了不少缺点。

WindowsCE可应用于PDA、WebPAD、ThinClient等等。是采用WindowsCE为操作系统的SIMPad(西门子公司所有)。

Palm

由PalmComputing公司的嵌入式操作系统，目前最大的应用在PDA，是市场占有率最高的PDA操作系统，Palm操作系统架构非常简洁，因为少去了很多功能，如内存管理、多任务等等，使得Palm可以非常不耗系统资源，硬件需求低，连带的整体耗电量便可压缩到非常低，因此采用Palm操作系统的PDA都有待机时间长的优点。

EPOC

由英国手持装置大厂Psion所开发，常用于PDA与手机结合的场合。最有名的例子Nokia9110系列手机，它就是采用EPOC系统。

着名的嵌入式实时系统

实时系统是嵌入式系统里头非常重要的一环，很多人都误以为实时系统执行速度非常快的系统，事实上不然，所谓实时代表的意义是‘实时反应’，一般多人多任务操作系统如：Windows、UNIX，在上面执行的软件都一起分享CPU，因为CPU速度快，所以我们感觉好象可以同时执行多支软件，其实在系统内部的同一时间内都只有一个程序在执行，每个软件都必须排队，而且规定只能用一小段时间后就要换下一位，但是因为CPU速度够快，很快又可以被执行到，所以人们感觉并不会很明显软件是一段一段在执行。这是一般所谓的非实时性的操作系统运作模式，而实时操作系统具有立即反应而且不能让出资源的特性，例如汽车的ABS煞车系统，如果不采用能够立即反应的实时系统，后果可就不堪设想。而这类的应用多半多属体积小、功能简单的地方，所以也算是嵌入式系统。QNX的QNXOS、WindRiver的VxWorks、Microware的OS9、pSOS等等，都是有名的嵌入式实时系统公司。

Linux

Linux不是都用来做服务器吗?不然就是Cluster，怎么会跟嵌入式系统扯上关系?不要怀疑，Linux除了对伺服工作应付自如外，嵌入式系统也难不倒Linux。

那么究竟Linux有怎样独特的能耐，可以想变大就变大想缩小就缩小?又用Linux来发展嵌入式系统有什么优点?请看底下介绍。

开放原始码、模块化设计

Linux采用GPL授权，除了把原始码公开以外，任何人都可以自由使用、修改、散布，而Linux核心本身采模块化设计，让人很容易增减功能，例如我的平台并不需要蓝芽的功能，我只要不把这项功能加入，有需要就加入，不需要就删除，由于这样的高的弹性，我们可以调校出最适合我们硬件平台的核心出来。

相较于Linux，Windows是走封闭原始码路线，所以我们完全无法得知或修改它的核心部份。另外因为是采用GPL授权自然就没有什么权利金或保密协议的约束。

稳定性够

Linux不属于任何一家公司，但是它的开发人员却是全世界最多的，每天在全球都有无数的人参与LinuxKernel的改进、除错、测试，这样严苛的条件造就了稳定度高的Linux。

就因为如此，Linux虽不是商业的产物但是品质却不逊于商业产品。

网络功能强大

Linux的架构是参造UNIX系统而来，因此Linux也承袭了UNIX强大的网络功能。在这个每样事情都讲求网络的时代下，只能说是Linux大放异彩的年代。未来可能家里的电冰箱、冷气、电视机都会连上网络，如何增加这些家电的网络功能，Linux可以替他们办到。

跨平台

Linux一开始是基于Intel386机器而设计，但是随着网络的散布，各式各样的需求涌现，因此就有许多工程师致力于各式平台的移植，造成了Linux可以在x86、MIPS、ARM/StrongARM、PowerPC、Motorola68k、HitachiSH3/SH4、Transmeta..等等平台上运作的盛况。这些平台几乎涵盖了所有嵌入式系统所需的CPU，因此选择Linux就可以把更多的`硬件平台纳入考量的范围。

嵌入式环境不如x86PC那样单纯，嵌入式环境所采用的CPU架构之多，使用Linux作开发，就等于有更多硬件的选择，硬件成本是商业公司考量的一大重点，选择多自然可以找到最合适的硬件，对于公司的竞争力是有极大的帮助。

应用软件众多

自由软件世界里有个很大的特色就是软件超级多，而且几乎都是符合GPL标准，换句话说，大家都可以自由取用，因为这些软件多半是由工程师业余空暇时间所发展，而且不以营利为性质，所以并不能担保这些软件完全没有BUG，但是仍旧有许多杀手级的软件出现，大家熟知的KDE与GNOME便是很好的证明，当然与嵌入式系统较为相关如：gcc编译器、Kdevelop整合式开发环境等等。

通常我们都会先在PC端造出仿真出嵌入式的环境，并直接在上头开发，因此用的工具也都与开发一般Desktop软件类似，良好的工具能够增加开发的速度。

选择多样

如果公司有能力可以自己实作Linux嵌入式系统，因为程序代码全部都开放在那里，您可以随心所欲的设计出自己想要的EmbeddedLinux系统，但是有更多的公司的业务重点不在于此，这时候您也可以选择购买商业版的EmbeddedLinux系统，像是有名的Redhat公司、Lineo、MontaVista..等等，这些都是商业的Linux公司，购买他们的产品就可以得到完整的服务。因此商业或非商业全都在于您的需求。

自行开发系统

当然您也可以自行开发系统，严格控制硬件，但是相对的必须投注更大的成本在于研发系统上，原则上如果目标简单明确只是一些基本的I/O控制，例如：跑马灯。便适合自己开发，但是如果系统过于复杂则必须审慎评估自行研发的难度与时程的控管。

嵌入式操作系统的分类 篇5

进程的同步(直接制约)：synchronism

指系统中一些进程需要相互合作，共同完成一项任务。具体说，一个进程运行到某一点时要求另一伙伴进程为它提供消息，在未获得消息之前，该进程处于等待状态，获得消息后被唤醒进入就绪态。同步是指在互斥的基础上(大多数情况)，通过其它机制实现访问者对资源的有序访问。在大多数情况下，同步已经实现了互斥，特别是所有写入资源的情况必定是互斥的。少数情况是指可以允许多个访问者同时访问资源。

进程的互斥(间接制约)mutualexclusion

由于各进程要求共享资源，而有些资源需要互斥使用，因此各进程间竞争使用这些资源，进程的这种关系为进程的互斥。某一资源同时只允许一个访问者对其进行访问，具有唯一性和排它性。但互斥无法限制访问者对资源的访问顺序，即访问是无序的。

相关概念：

互斥：指多个进程不能同时使用同一个资源；

死锁：指多个进程互不相让，都得不到足够的资源；

饥饿：指一个进程一直得不到资源(其他进程可能轮流占用资源)

临界资源：系统中某些资源一次只允许一个进程使用，称这样的资源为临界资源或互斥资源或共享变量

临界区：进程中访问临界资源的一段代码。

临界区问题

临界区(criticalsection)：进程中访问临界资源的一段代码。

进入区(entrysection)：在进入临界区之前，检查可否进入临界区的一段代码。如果可以进入临界区，通常设置相应"正在访问临界区"标志

退出区(exitsection)：用于将"正在访问临界区"标志清除。

剩余区(remaindersection)：代码中的其余部分。

使用临界区应遵循的准则

有空让进：当无进程在临界区时，任何有权使用临界区的进程可进入

无空等待：不允许两个以上的进程同时进入临界区

多中择一：当没有进程在临界区，而同时有多个进程要求进入临界区，只能让其中之一进入临界区，其他进程必须等待

有限等待：任何进入临界区的要求应在有限的时间内得到满足

让权等待：处于等待状态的进程应放弃占用CPU

平等竞争：任何进程无权停止其它进程的运行进程之间相对运行速度无硬性规定

Linux下的进程包含以下几个关键要素：

有一段可执行程序；

有专用的系统堆栈空间；

内核中有它的控制块(进程控制块)，描述进程所占用的资源，这样，进程才能接受内核的调度；

具有独立的存储空间

进程和线程有时候并不完全区分，而往往根据上下文理解其含义。

嵌入式操作系统的分类 篇6

1、绪论

电控机械式自动变速器(,AMT)具有传动效率高、成本低、操作容易、驾驶舒适等优点，已成为车辆自动变速器发展的一个重要方向。AMT的核心部件是电控单元(TCU)，实时采集和检测输入信号(发动机转速、输入轴转速和车速，油门踏板位置、节气门开度、变速箱油温等以及各种状态信号)并进行调理、存储，同时，TCU根据这些运行参数进行工况判断并发出控制信号，完成车辆的平稳起步或自动换挡，从而使车辆获得优良的舒适性、燃油经济性与动力性能。较之传统的控制器，TCU有更多的传感器，执行器以及更为复杂的控制算法，若TCU设计不合理，难以满足实时性与可靠性的要求，同时，如果换挡规律不合理，汽车难以获得较好的燃油经济性和动力性。本文从TCU硬件和软件设计做了相应的介绍。

2、TCU软件设计

TCU软件部分的核心是控制策略，其主要部分是最佳换挡规律。本控制器采用两种换挡控制策略，即经济性换挡规律，综合性换规律，通过模式选择开关进行切换，使用Simulink搭建的换挡控制策略。

Simulink模型无法直接烧写到单片机中运行，编写好的程序通过Simulink提供的RTW工具生成可用的C代码，编写接口嵌入到软件系统中。生成的C代码是上层核心算法程序，只提供与底层程序的接口，而底层程序则须自己编写并留出对应接口和上层代码对应接口进行连接[3]。然后把相应的C代码添加到CCS中的工程文件中，并编写代码的接口，实现软件三部分的无缝连接；其中驱动程序包括信号输入通道设置与信号处理驱动程序、输出通道设置与输出处理、通信设置与数据转换。

3、TCU硬件设计

根据TCU的功能需求，把硬件电路划分以下几个部分：信号采集输入调理电路、执行器控制电路以及主控电路。

(1)主控电路：TCU的硬件电路选择了TMS320F2812主控芯片，两个16位通用定时器，以负责离合器转速信号、车速信号等脉冲信号的采集；8个16位的脉宽调制(PWM)通道、可以实现对离合器电磁阀、换挡电磁阀的控制；16通道A/D转换器，在采集节气门位置、离合器位置等传感器输入的多路模拟信号的应用中，可以简化硬件，提高系统可靠性；拥有改进的局域网络(eCAN)支持CAN2.0B协议，以实现串行信号的输入输出以及与汽车发动机ECU的信息交换,实现ECU之间的CAN通信。

(2)输入电路：对于主控芯片TMS320F2812芯片上带有AD转换模块的处理芯片，其输入的模拟信号需要经过简单的滤波、放大后才可接入DSP。开关量信号采用光电隔离来实现信号的转换，数字信号调理部分的作用是将仿正弦信号经过处理后，变成电平范围在DSP允许范围内的方波信号。数字信号调理部分的设计采用先滤波后整形，最后光电隔离的办法。

(3)TMS320F2812主控芯片EV外设提供的PWM外设功能，对电路进行控制，但，由控制器输出的PWM波的峰值电压只有5V，不足以驱动电磁阀，这就需要电磁阀驱动电路将PWM控制信号的功率进行放大，从而控制电磁阀正常工作。

4、结论

自行设计了TCU软硬件，对设计的TCU做了相应的硬件在环试验，利用RealTimeWorkshop实现控制模型向C代码的转化，优化后下载到TCU，进行了硬件在环仿真实验，篇幅有限，本文不做具体说明。试验结果表明，设计的该TCU，能按照控制策略实时、准确、可靠的控制AMT的换挡过程，同时，同时获得了较好的经济性以及动力性能。为AMT控制器的开发提供了参考。

② 如何在c++定义一个学生类以实现平均成绩的计算和查询功能

一．中间件的定义与作用
1.什么是中间件？
图片摘自公众号“筋斗云与自动驾驶”
笔者在交流中发现，不同的人对中间件的理解并不一样，甚至可以说，到现在，这个概念还是模糊不清的。比如：
（1）有的人认为中间件仅指位于OS内核之上、功能软件之下的那部分组件，为上层提供进程管理、升级管理等服务；而有的人则认为中间件还应包括功能软件和应用软件中间的那部分（参见上图）。按茅海燕的说法，前者是“通用中间件”，而后者是“专用中间件”。本文中提到的“中间件”，若不做专门说明，便特指“通用中间件”。
（2）有一些人提到的自动驾驶中间件，包括了AUTOSAR（又分为AUTOSAR CP和AUTOSAR AP），还有一些人口中的中间件，特指ROS2、Cyber RT、DDS等。
（3）未动科技VP萧猛认为，“中间”一词是相对的，当有多层堆叠的时候，每一层都是其上下两层的中间层，因此，在用“中间件”这个词的时候，我们需要特别指明它究竟位于“哪两层之间”。按萧猛的说法，当我们称“ROS/ROS2 为中间件”时，其含义与 “AUTOSAR AP为中间件”并不是对等的关系。
(4)Vector产品专家蔡守群说，他理解的中间件，“是给App开发提供功能支撑的，对外是没有功能表征的；但是站在操作系统内核的角度，中间件跟App并没有本质的区别”。
2.中间件的作用
汪浩伟说：“专用中间件原本是应用程序的一部分，只是很多公司做自动驾驶都需要用到，就被抽象出来了。”
那么，它究竟有什么用？
毕晓鹏认为，自动驾驶中间件最主要的作用是：对下，它能够去适配不同的OS内核和架构；对上，它能够提供一个统一的标准接口，负责各类应用软件模块之间的通信以及对底层系统资源的调度。
据毕晓鹏解释，前者，使开发者们无需考虑底层的OS内核是什么，也无需考虑硬件环境是什么，即不仅实现了应用软件与OS的解耦，也实现了应用软件与硬件的解耦；而后者则确保了数据能够安全实时地传输、资源进行合理的调度。
为什么要通过中间件来支持软硬件解耦？毕晓鹏解释道：
我开发一个应用软件，其中很多内容都是与具体应用逻辑无关的，包括数据通信、通信安全、系统资源调度等，比如，有十个进程需要数据交互，完全没有必要在十个程序的软件代码里各自进行实现和配置。针对这种情况，我们就可以把重复的部分抽象成一种服务，单独封成一层东西（这就是中间件），并提供统一的库、接口和配置方法，供上层去调用。这样的话，有一部分人专门去做中间件的，而做上层应用的人也不需要考虑跟底层交互的事情。
举例说，如果要做一个自动泊车系统，它有各个模块或业务逻辑独立的不同软件，在进行通信、数据交互，或者调用底层资源时，只需要中间件的一个接口就可以实现，其他事情不需要考虑，这样开发人员就可以专注于自己的业务逻辑。
又比如，一个摄像头需要感知前面的车道线、红绿灯等，开发人员就专门做红绿灯和车道线检测算法，与外界的数据交互只需要使用中间件的通信服务（例如订阅摄像头信息，发布检测结果），而不必关心数据从哪里来、发给谁。
Nullmax纽劢科技系统平台总监苗干坤博士在此前的一篇文章中写道：
“芯片算力大幅增长，摄像头像素呈翻倍之势，激光雷达出现在更多新车规划上……没有谁能够断言车上的传感器应该有多少，又或者是将来的汽车还会增加哪些硬件，但所有人都知道硬件的变化将会来得更加猛烈。
“所以我们也可以看到，汽车对软硬件架构的要求也越来越高，既要能满足当下的需求，还要具备相当的前瞻性、兼容性和扩展性，能够支持接下来软硬件升级换代、增减模块的需求。而自动驾驶的中间件，就正是这样一个可以按需调整、满足各样需求的现代温室。
“在早期开发中，中间件可以化整为零，将巨大的软件工程分解成若干小任务，分散解决。在后期应用时，它又可以化零为整，像拼积木一样，根据需求将一个个模块组合成一个整体，严丝合缝。”
在春节前的一场直播中，东软睿驰产品销售总监安志鹏说，在软硬件解耦、模块化管理后，再遇到问题，就不用整个系统都改，只改相对应的部分就行了。这样，软件的可复用程度就极大地提升了，同时，验证的工作量也会减少许多，整体开发效率也会因此提升。
相反，没有中间件的话，应用层就得直接调用操作系统的接口，后期要是换了操作系统，应用层的代码和算法可能就要推倒重来。
简言之，中间件通过对计算平台、传感器等资源进行抽象，对算法、子系统、功能采取模块化的管理，并提供统一接口，让开发人员能够专注于各自业务层面的开发，无需了解无关细节。
按东软睿驰产品销售总监安志鹏的说法，搞AUTSOAR这样的中间件，并不是只对OEM有利，“零部件供应商的选择面也大了——应用做好了，下面的软件、芯片可以选好几家供应商的，要比传统的开发模式快很多，因而，零部件供应商也是受益者”。
用萧猛的话说，中间件最直接的好处就是“为上层屏蔽底层的复杂性”，软件开发人员可以忽略芯片、传感器等硬件的差异，从而高效、灵活地将上层应用及功能算法在不同平台上实现、迭代、移植。萧猛认为，中间件可以看做是自动驾驶应用背景下的一项“新基建”。
（图片摘自冯占军博士的《AUTOSAR对基础软件开发是喜还是忧？》一文。AUTOSAR只是中间件的一种，但这里写的“AUTOSAR开发优势”基本也适用于其他中间件。）
不过，站在开发者的角度看，中间件的意义也未必全部是正面的。如冯占军博士在《AUTOSAR对基础软件开发是喜还是忧？》一文中就提到了如下两点：
底层软件工程师变成了工具人，“只要你去点点鼠标，用工具配合就可以了”，很多原本由自己做的测试也改由供应商来做，进而导致工程师的成就感严重降低；时间久了，工程师从0到1开发的能力也会降低。
（图片摘自冯占军博士的文章。尽管文章说的是Autosar,但实际上这些问题在ROS等其他中间件的使用过程中也会存在。）
对软件工程师来说，中间件造成的“能力退化”这一问题几乎是无解的。但冯占军博士认为，“如果这个中间件在开发过程中，有使用公司的工程师深度参与，提出需求并一起实施，会好一些”。
此外，殷玮在一篇文章提到，使用AUTOSAR这样的中间件，Tier 1们应该是很不情愿的，“因为不到增加了成本，还有可能逐步沦为硬件生产商”。但这个也不能说是中间件的锅，在软件定义汽车大大趋势下，这几乎是必然的。
二．常见的基本概念
1. AUTOSAR CP 与 AUTOSAR AP
在所有的中间件方案中，最着名的非AUTOSAR莫属了。
严格地说，AUTOSAR并非特指由某一家软件公司开发出来的某款操作系统或中间件产品，而是由全球的主要汽车生产厂商、零部件供应商、软硬件和电子工业等企业共同制定的汽车开放式系统架构标准。不过，在实践中，各公司基于AUTOSAR标准开发出来的中间件也被被称为“AUTOSAR”。
当前，AUTOSAR可分为Classic Platform和Adaptive Platform两个平台，两者分别被简称为AUTOSAR CP与AUTOSAR AP。
简单地说，AUTOSAR CP主要跑在8bit、16bit、32bit的MCU上，对应传统的车身控制、底盘控制、动力系统等功能，如果涉及到自动驾驶的话，AUTOSAR CP可能无法实现；而AUTOSAR AP主要跑在64bit以上的高性能MPU/SOC上，对应自动驾驶的高性能电子系统。
严格地说，AUTOSAR CP并不只是个“中间件”，它是相当于“OS内核+中间件”的一套完整的“操作系统”。 AUTOSAR CP定义了基本的上层任务调度、优先级调度等。
在基于分布式架构的ADAS功能中，AUOTSAR CP便是最常见的“操作系统”。在AUTOSAR的生态形成后，很多芯片厂商的MCU上标配的就是AUTOSAR CP，主机厂没有什么选择权。
由于分布式架构下的芯片主要是MCU，因此，便有了“AUTOSAR CP主要跑在MCU上”的说法。
在分布式架构下，不同的功能对应着不同的MCU，而每一个MCU上都需要跑一套AUTOSAR CP，若传感器的类型比较多，则仅ADAS相关功能就需要很多套AUTOSAR CP，那怎么收费呢？
常规的做法是：根据MCU的类型来收费——如果MCU是两个异构的MCU，那AUTOSAR CP就按两套来收费；如果MCU是同构的，那AUTOSAR CP就按一套来收费。
随着EE架构从分布式向集中式演进、芯片由MCU向SOC演进，计算量及通信量成数量级地上升，另外，多核处理器、GPU、FPGA以及专用加速器的需求，还有OTA等，都超出了AUTOSAR CP的支持范围。
（图片摘自安志鹏的直播课）
2017年，为更好地满足集中式架构+SOC时代的高等级自动驾驶对中间件的需求，AUTOSAR联盟推出了通信能力更强、软件可配置性更灵活、安全机制要求更高的AUTOSAR AP平台。
需要强调的是，不同于AUTOSAR CP自身已经包含了基于OSEK标准的OS，AUTOSAR AP只是一个跑在Lunix、QNX等基于POSIX标准的OS上面的中间件——它自身并不包含OS。
结合aFakeProgramer于2020年发表在CSDN上的《为什么要用AP？Adaptive AutoSAR到底给企业提供了一些什么？》一文及东软睿驰安志鹏在2022年春节前的一场直播中讲的内容，AUTOSAR CP与AUTOSAR AP最主要的区别有如下几点：
1）.编程语言不同——AUTOSAR CP基于C语言，而AUTOSAR AP基于C++语言；
2）.架构不同——AUTOSAR CP 采用的是FOA架构（function-oriented architecture），而AUTOSAR AP采用的则是SOA架构（service-oriented architecture）；
3）.通信方式不同——AUTOAR CP采用的是基于信号的静态配置通信方式（LIN\CAN...通信矩阵），而AUTOSAR AP采用的是基于服务的SOA动态通信方式（SOME/IP）；
4）.连接关系不同——在AUTOSAR CP中，硬件资源的连接关系受限于线束的连接，而在AUTOSAR AP中，硬件资源间的连接关系虚拟化，不局限于通信线束的连接关系；
5）.调度方式不同——AUTOSAR CP采用固定的任务调度配置，模块和配置在发布前进行静态编译、链接，按既定规则顺序执行，而AUTOSAR CP则支持多种动态调度策略，服务可根据应用需求动态加载，并可进行单独更新。
6）.代码执行和地址空间不同——AUTOSAR CP中，大部分代码静态运行在ROM，所有application共用一个地址空间，而在AUTOSAR AP中，应用加载到RAM运行，每个application独享（虚拟）一个地址空间。
这些区别，带给AUTOSAR AP的优势有如下几点——
1）.ECU更加智能：基于SOA通信使得AP中ECU可以动态的同其他ECU同其他ECU进行连接，提供或获取服务；
2）.更强大的计算能力：基于SOA架构使得AP能够更好地支持多核、多ECU、多SoCs并行处理，从而提供更强大的计算能力；
3).更加安全：基于SOA架构使得AP中各个服务模块独立，可独立加载，IAM管理访问权限；
4).敏捷开发：Adaptive AUTOSAR服务不局限于部署在ECU本地可分布于车载网络中，使得系统模块可灵活部署，后期也能灵活独立更新（FOTA）；
5).高通信带宽：可实现基于Ethernet等高通信带宽的总线通信；
6).更易物联：基于以太网的SOA通信，更易实现无线、远程、云连接，方便部署V-2-X应用。
（图片摘自东软睿驰）
当然了，在某些方面，AUTOSAR AP与AUTOSAR CP相比是有一些“劣势”的。比如，AUTOSAR CP的时延可低至微秒级、功能安全等级达到了ASIL-D，硬实时；而AUTOSAR AP的时延则在毫秒级，功能安全等级则为ASIL-B，软实时。
上述区别也导致了两者应用领域的不同：AUTOSAR CP一般应用在对实时性和功能安全要求较高、对算力要求较低的场景中，如引擎控制、制动等传统ECU；而AUTOSAR则应用在对实时性和功能安全有一定要求，但对算力要求更高的场景中，如ADAS、自动驾驶，以及在动态部署方面追求较高自由度的信息娱乐场景。
尽管AUTOSAR AP有种种优点，但总的来说，它目前还不够成熟——主要是信息安全及UCM等模块不成熟。量产车上装AUTOSAR AP的不少，但主要用在娱乐场景，真正用在自动驾驶场景的还很少。
此外，由于SOC+MCU组合的现象会长期存在，因而，在今后相当长一段时间内，AUTOSAR AP都不可能彻底取代AUTOSAR CP——最常见的分工会是，需要高算力的工作交给AUTOSAR AP,而需要高实时性的工作则交给AUTOSAR CP。
（图片摘自超星未来）
2.ROS 2
ROS是机器人操作系统（Robot Operating System）的英文缩写，原生的ROS本是机器人OS，并不能直接满足无人驾驶的所有需求，用作自动驾驶中间件的是ROS 2。
ROS 2与ROS 1的主要区别如下：
（1）.ROS 1主要构建于Linux系统之上，主要支持Ubuntu；ROS 2采用全新的架构，底层基于DDS(Data Distribution Service)通信机制，支持实时性、嵌入式、分布式、多操作系统，ROS 2支持的系统包括Linux、windows、Mac、RTOS，甚至是单片机等没有操作系统的裸机。
（2）.ROS 1的通讯系统基于TCPROS/UDPROS，强依赖于master节点的处理；ROS 2的通讯系统是基于DDS，取消了master，同时在内部提供了DDS的抽象层实现，有了这个抽象层，用户就可以不去关注底层的DDS使用了哪个商家的API。
（3）.ROS运行时要依赖roscore，一旦roscore出现问题就会造成较大的系统灾难，同时由于安装与运行体积较大，对很多低资源系统会造成负担；ROS2基于DDS进行数据传输，而DDS基于RTPS的去中心化的通信框架，这就去除了对roscore的依赖，系统的稳定性强，对资源的消耗也得到了降低。
(4).由于ROS 缺少Qos机制，topic的稳定性与质量难以保证；ROS2则提供了Qos机制，对通信的实时性、完整性、历史追溯等功能有了支持，这便大幅加强了框架功能，避免了高速系统难以适用等问题。
不过，ROS2的QoQ配置较为复杂，目前主要是国外一些专业的大学或实验室在使用,国内仅有极少数公司在尝试;此外，ROS 2的生态成熟度远不如ROS,这也给推广应用带来了不便。
跟AUTOSAR AP一样，ROS 2也是跑在soc芯片上、用于满足高等级自动驾驶的需求的。不过，萧猛在去年的一批文章中却特别强调：当我们称 “ROS/ROS2 为中间件”时，其含义与 “AUTOSAR AP为 中间件”并不是对等的关系。
萧猛的文章称：
当我们说 AutoSar是中间件时，这个中间件是很明确的 L.BSW层语义，即处于计算机OS与车载ECU特定功能实现之间，为 ECU功能实现层屏蔽掉特定处理器和计算机OS相关的细节，并提供与车辆网络、电源等系统交互所需的基础服务；
ROS/ROS2 是作为机器人开发的应用框架，在机器人应用和计算机OS之间提供了通用的中间层框架和常用软件模块(ROS Package)，而且， ROS团队认为这个框架做得足够好，可以称作操作系统（OS）了。
ROS 2尽管在功能上跟AUTOSAR AP有不少重叠之处，但两者的思路是不一样的：
（1）.从表现形式上看，AUTOSAR AP首先是一套标准，这个标准定义了一系列基础平台组件，每个平台组件定义了对应用的标准接口，但没有定义实现细节，和平台组件之间的交互接口（这些部分留给AUTOSAR AP供应商实现）；ROS2则从一开始就是代码优先，每个版本都有完整的代码实现，也定义有面向应用标准API接口。
（2）AUTOSAR AP从一开始就面向ASIL-B应用；ROS 2不是根据ASIL的标准设计的，ROS 2实现功能安全的解决方案是，把底层换为满足ASIL要求的RTOS和商用工具链(编译器）。
ROS 2“过不了车规”似乎已成为一个很广泛的行业共识。但在萧猛看来，ROS2本来就不是为实时域设计的，如果一定要把实时性要求高的车辆控制算法运行在 ROS2中，“那是软件设计的错误，而不是ROS2的问题”。
萧猛认为，只要能补齐 L.BSW层所需要完成的所有功能、补齐 A 轴所有切面要求的特性，ROS 2就能用于自动驾驶量产车。如前段时间刚拿到采埃孚等多家巨头投资的Apex.AI公司基于ROS 2定制开发的Apex.OS就已经通过了最高等级的ASIL D认证。
萧猛说：“这实际上是基于 ROS 2的架构去实现一套 AUTOSAR AP 规范。这可以成为一个单独的产品，投入时间+人+钱可以开发出来，只是看有没有必要，值不值得”。
在具体的实践中，ROS 2跟AUTOSAR AP存在直接竞争关系——尽管对用户来说，并不存在严格意义上的“二选一”问题，但通常来说，若选了ROS 2，就不会选AUTOSAR AP了；若选了AUTOSAR AP，就不会选ROS 2了。
3. CyberRT
Cyber RT是网络Apollo开发出来的中间件，在Apollo 3.5中正式发布。Cyber RT和ROS2是比较像的， 其底层也是使用了一个开源版本的DDS。
网络最早用的是ROS 1,但在使用的过程中逐渐发现了ROS 1存在“若ROS Master出故障了，则任何两个节点之间的通信便受到影响”的问题，所以就希望使用一个“没有中间节点”的通信中间件来代替ROS 1，那时还没有ROS2，所以自己去做了一个Cyber RT。
为了解决 ROS 遇到的问题，Cyber RT删除了master机制，用自动发现机制代替，这个通信组网机制和汽车网络CAN完全一致。此外，Cyber RT的核心设计将调度、任务从内核空间搬到了用户空间。
（图片出处：https://blog.csdn.net/xhtchina/article/details/118151673）
其相对于其他系统，Cyber RT的一大优势是，专为无人架驶设计。网络已将Cyber RT开源，某互联网巨头的自动驾驶团队使用的中间件便是网络开源出来的Cyber RT。
Cyber RT跟ROS 2之间也存在竞争关系。
在谈到AUTOSAR AP、ROS 2与Cyber RT这些中间件的关系时，Vector产品专家蔡守群的解释是：
“不需要很机械地去分类，你可以把AUTOSAR AP, ROS和Cyber RT都想象成一个提供一组中间件的超市，用户可以按需从不同的超市购买，并不是说从一个超市买过一个中间件，就不能从其他超市买了。
蔡守群说：AUTOSAR AP中也包含了对ROS接口的支持。说不准哪天ROS和Cyber RT就会加入AUTOSAR AP的组件，或者 AUTOSAR AP会引入Cyber RT的组件。
4.DDS（通信中间件）
（1）什么是DDS？
在自动驾驶领域，中间件的功能涉及到通信、模块升级、任务调度、执行管理，但其最主要的功能就是通信。当前市场上，无论是Cyber RT还是 ROS，基本上90%的功能就是通信，狭义上说就是通信中间件。
通信中间可以分成开源和闭源的两种。开源的为OPEN DDS、FAST DDS、Cyclone等，闭源的就RTI的DDS和Vector的SOME/IP。DDS的全称为Data Distribution Service ，指一种数据分发服务标准，由对象管理组织(OMG)制定。
DDS能够实现低延迟、高可靠、高实时性的数据融合服务，能够从根本上降低软件的耦合性、复杂性，提高软件的模块化特性。高等级自动驾驶现在基本上都在探索依靠DDS来解决异构通信、低时延等CP解决不了的挑战。
融合了DDS的汽车软件能够更好地运行在下一代汽车的体系架构中，更能降低开发的成本、缩短研发的时间，更快地将产品推向市场。
（2）DDS与ROS 2、AUTOSAR AP之间的关系
ROS 2和Cyber RT的底层都使用了开源的DDS，将DDS作为最重要的通信机制。但也有自动驾驶公司的工程师认为，DDS可以起到替代ROS 2的作用，站在用户的角度看，两者之间其实存在“二选一”的关系。
AUTOSAR CP里一直没有包含跟DDS有关的东西，但AUTOSAR AP在 2018年3月的最新版（版本18-10）里开始支持DDS标准。将DDS与AUTOSAR AP结合使用，不仅可以保证和扩展AUTOSAR AP系统内部互操作性的功能，而且还可以将其开放给来自不同的生态系统（即ROS 2）。
从工程角度来看，将AUTOSAR和DDS结合起来的最大优势是，功能域和网络拓扑不再是对手，而是车辆中的盟友。网络拓扑结构能够更好地适应车辆的物理约束，功能域在物理车辆的顶部提供了一个灵活的覆盖层，这就是所谓的分区体系结构。
当然，DDS仅是通信中间件的一种。关于各类通信中间件之间的异同，我们将在本系列的第二篇做更详细的阐释。
三．AUTOSAR AP的地位正在弱化？
尽管AUTOSAR是当下最有名的自动驾驶中间件，但《九章智驾》在对诸多中间件厂商们的调研中得出一个结论：AUTOSAR在产业链中的地位可能正在弱化。 当然了，那些专注于AUTOSAR系统的厂商们并不认同这一观点。
我们在上文已经提到，随着EE架构从分布式向集中式演进、MCU被SOC取代，CP AUTSAR被AUTOSAR AP、ROS 2和Cyber RT等取代已是大势所趋，在下文，我们主要谈的是“AUTOSAR AP的地位会不会弱化”。
2021年12月中旬，两家AUTOSAR发起公司大陆集团、丰田联合采埃孚、積架路虎、沃尔沃、海拉等多家汽车行业龙头企业宣布投资车载操作系统初创公司Apex.AI，而Apex.AI的主力产品Apex.OS则是基于ROS 2发展起来的。
拿到了Apex.AI公司15%股权的采埃孚方面在接受媒体采访时说：“这意味着，我们可以为客户提供AUTOSAR AP的替代方案。”
尽管AUTOSAR AP已经有了标准，但还没有落地。安波福、采埃孚、大陆这些公司提供的方案，仍然是基于AUTOSAR CP标准的接口。事实上，越来越多的OEM不太想完全用AUTOSAR去解决智能驾驶操作系统的问题。
不仅特斯拉没有用AUTOSAR AP,国内的几大造车新势力也没有用(他们用的是AUTOSAR CP+DDS)。甚至，连一些正在转型的传统车企也没打算用AUTOSAR AP。
从产业链中各方的反应来看，AUTOSAR AP“地位不稳”的原因主要有以下几个：
1．使用成本太高
冯占军博士在《AUTOSAR对基础软件开发是喜还是忧？》一文中透露，AUTOSAR的费用通常是“几百万起”，并且，针对不同的域控制器、不同的芯片需要“重复收费”，一般小厂根本吃不消。“可能还没有什么产出，几百万就花出去了”。
除购买成本高外，毕晓鹏和萧猛都提到，AUTOSAR前期的学习难度很大、学习成本也非常高。为了学会如何使用AUTOSAR,企业甚至不得不专门培训一批人,如果受培训的人临时离职了，那培训费用就打了水漂。
2.效率不高
毕晓鹏认为，AUTOSAR AP的配置非常多，它是通过配置加上一部分代码去实现自己的功能，但配置多了之后，效率不高，而且代码臃肿。
3.静态部署与动态部署的理念冲突
毕晓鹏博士提到，AUTOSAR AP其实是从AUTOSAR CP发展而来的，AUTOSAR CP是静态部署，只适用于相对简单的业务逻辑和功能，其代码是固化的，有点像以前的功能手机——功能无法改变，不可能往里面再加一个APP；但AUTOSAR AP有点像现在的智能手机，软件开发人员开发一个APP，跨平台就可以用不同手机上了，这种动态部署的理念和之前的静态部署概念不甚相同，而其方法论却是基于静态部署衍生而来的，因此在实践层面会遇到不少问题。
4.无法满足智能网联的需求
由于云端跟车端所使用的操作系统不一样，AUTOSAR只能负责车内的通信，不能支持车端到云端的通信，因而无法支持车路协同场景（车端跟云端的通信，是通过MQTT、kafka等中间件来实现的）。除此之外，AUTOSAR能否兼容车辆网联化中需要用到的数据平台、通信平台和地图平台，也存在很大的疑问。
毕晓鹏说，在发现了这些问题后，有一些OEM开始逐渐放弃AUTOSAR架构，“转而自己去研发一套更适合动态部署、成本较低的新型软件架构”。
传统车厂是从使用CP过来的，所以在惯性上，他们可能还会考虑AP是否适合智能驾驶，但慢慢地也在尝试转型。如奥迪和TTTech合作做的通信中间件——zFAS，也没有采用AP。
不同于AUTOSAR CP已经是非常标准化的东西，大家用起来没什么问题，AUTOSAR AP现在的标准也不是很完善，每年也在更新，具体AP能发展成什么样，这个谁也不知道，大家更多也是观望的态度。
毕晓鹏认为，AUTOSAR标准并不能很好地支撑自动驾驶应用和创新的发展，因此，我们有必要建立一套更适合中国智能驾驶发展、且自主可控的技术架构和生态体系。
萧猛认为，由于从AUTOSAR CP到AUTOSAR AP一脉相承，一些已经对AUTOSAR形成路径依赖的公司会坚持使用AUTOSAR AP,但在经历过招人难、开发周期长等教训之后，他们有可能转向ROS 2。
当然，以AUTOSAR为主业的公司，显然不会认可上述“涉嫌唱衰”AUTOSAR AP的观点的。
比如，Vector蔡守群就认为，AUTOSAR AP只会越来越重要，因为它是顺应车载技术不断发展的一套规范，覆盖面会越来越广。
东软睿驰茅海燕也认为，要将整车域控制器和智驾域控制器合并到统一的中央计算平台上，没有AUTOSAR AP的支持很难搞定。“不是每家公司都能像特斯拉一样自己从头搭建系统的，目前,最好的工具还是AUTOSAR AP”。

③ autosar源码需要工具链吗

autosar源码需要工具链。

编译工具链一般最简化的为binutils+gcc+glibc+kernel-header组合的环境。GCC就是编译器，他的输出每次安装只能有针对一个架构的指令输出。如果要多个架构输出，那就要装多个。

工具链光有 GCC 是不行的，还需要一个 binutils 的二进制连接器，以及一个最基本的目标架构的 C 库，C 库还需要一个目标架构的内核源代码才能完全工作(当然不是必须的，但编译有的时候需要)。

又因为 GCC 、binutils 不能实现单软件同时多架构输出，所以需要单独另装，又加上 C 库和内核头文件需要目标架构的东西而不能用本机本地架构的数据。

源代码主要有如下两种作用：

1.生成目标代码，即计算机可以识别的代码。

2.对软件进行说明，即对软件的编写进行说明。为数不少的初学者，甚至少数有经验的程序员都忽视软件说明的编写，因为这部分不会在生成的程序中直接显示，也不参与编译。但是注释代码对软件的学习、分享、维护和软件复用都有巨大的好处。

需要指出的是，源代码的修改不能改变已经生成的目标代码。如果需要目标代码做出相应的修改，必须重新编译。