操作系统是汽车软件的核心，车企角力车载OS，软件定义汽车时代下，汽车软件架构不断演进
随着汽车不断向智能化、网联化方向发展，以单片机为核心的传统分布式电子电气架构已经很难满足未来智能汽车产品的开发需求。
因此，汽车电子电气架构从传统分布式架构正在朝向域架构、中央计算架构转变，而集中化的EE架构是实现软件定义汽车重要的硬件基础。
软件层面上，由于软件迭代周期越来越短，汽车软件架构也逐步由面向信号的架构（Signal-OrientedArchitecture）向面向服务的软件架构（Service-OrientedArchitecture，SOA）升级，以更好实现软硬件解耦与软件快速迭代。
车载操作系统是汽车软件的核心，可分为狭义OS和广义OS：
狭义OS：指OS内核，又称为“底层OS”，提供操作系统最基本的功能，负责管理系统的进程、内存、设备驱动程序、文件和网络系统，决定着系统的性能和稳定性，是系统软件层的核心。
广义OS：指控制和管理车载硬件和车载软件资源的程序系统集合，在汽车软件架构中起到承上启下的作用，不仅为上层应用的实现提供了高效、稳定环境的支持。
是各类应用调度底层硬件资源的“桥梁”。在汽车软硬件架构中，广义OS指系统软件层（包括硬件抽象层、OS内核、中间件组件）与功能软件组成的软件集合。
对于车企而言，自研OS内核成本高，更多地是在现有内核的基础上开发形成各自研自动驾驶OS。
目前自动驾驶OS内核竞争格局较为稳定，主要包括QNX、Linux、Android（基于Linux开发）、VxWorks、WinCE等。因打造全新OS需要花费太大的人力、物力，目前基本没有企业会开发全新的OS内核。
由于各内核存在差异，车企在选择OS内核时，主要考虑安全性、可靠性、开放性、可扩展性、易用性及成本等因素，再结合自己的需求及能力体系来做权衡。
例如，实时性、安全性好的RTOS（Real-timeOS，实时OS），如QNX、RTLinux等，车企会优先考虑运用到对实时性、功能安全要求更高的驾驶域；
对应用生态丰富度要求高的座舱域，车企可以在Linux、Android等开放性好的内核基础上打造座舱域OS。
根据对OS内核改造程度不同，车企自研车载操作系统可大致分为三类：
定制型操作系统：指在基础型操作系统之上进行深度定制化开发，覆盖系统内核层到应用程序层，最终（一般是Tier1和主机厂一起）实现座舱系统平台或自动驾驶系统平台。
ROM型汽车操作系统：基于Linux或Android进行有限的定制化开发，不涉及系统内核更改，一般只涉及汽车服务、车辆服务以及应用程序等内容的修改。
一方面开展各种合作，利用开源软件组织，减少开发周期和成本。Linux基金会在2012年启动了开源项目AutomotiveGradeLinux（简称AGL）。
此项目的最终目标是提供满足安全关键系统的功能安全，从而服务自动驾驶应用。
按照AGL的设想，未来成员企业可以共享70%的代码，另外30%则是不同品牌厂商进行差异化开发，从而保障各自的商业化利益，目前AGL成员已超过100家。
由于QNX的高安全性以及Linux开源、免费等优势，国外车厂大多选择QNX与Linux作为底层操作系统进行开发；
由于国内Android应用生态更好，国内车企以及造车新势力大多基于Android定制操作系统。Android内核相较QNX与Linux在某些方面具备独有的优势。
从架构来看，Android的硬件抽象层对Linux内核驱动程序进行了封装，把对硬件的支持分成了两层，一层放在用户空间（UserSpace），一层放在内核空间（KernelSpace）。
其中硬件抽象层运行在用户空间，而Linux内核驱动程序运行在内核空间。Linux作为宏内核，把对硬件的支持和管理全部放在内核空间中，复杂的内核结构会带来稳定性较差的问题
QNX作为微内核，内核中只有最基本的调度、内存管理，驱动、文件系统等，但频繁的系统调用与信息传递会使OS的运行效率较低。Android内核居于QNX与Linux之间，较Linux有更好的稳定性，较QNX有更高的效率。
Android之所以在用户空间新建一个HAL层（指硬件抽象层）来支持硬件设备，是由于Android使用的开源协议是ApacheLicense，此协议比较宽松，其允许开发者获取并修改了源码之后，不用把源码公开出来。
Linux使用的开源协议是GPL，它的要求和限制较多，其中要求开发者添加或修改了源码之后，必须把添加或修改后的代码公开出来。
HAL层保护了开发厂家的利益，但脱离了Linux的开源。安卓是开放的，但不是开源的，这也是为什么把安卓从Linux分出去的主要原因。
根据佐思汽研预测，2026年Android类OS在新车座舱操作系统的占有率将从2021年的25%提升到50%。
由于QNX的定制修改都需要Blackberry来做，BSP需要为硬件定制，具备QNX应用开发能力的开发者数量较少，未来QNX在座舱OS的占有率或将下降。
随着汽车芯片以及软件生态的发展，当前汽车操作系统已步入座舱OS阶段，未来随着座舱域与自动驾驶域的融合，座舱OS将进一步向整车OS迈进。
在2020年初，斑马智行提出了AliOS操作系统演进三部曲战略，即智能车机操作系统、智能座舱操作系统、智能整车操作系统。
根据佐思汽研预测，2024年以后将迈向整车OS阶段。车企加大自研操作系统投入力度，行业规模有望持续增长。
根据麦肯锡数据，2020年全球广义操作系统市场规模为200亿美元，到2025年约370亿美元，到2030年可达500亿美元，可见未来近10年内操作系统市场具有较大的增长空间。
中间件对于汽车软硬件解耦具有重要意义
车载中间件解决方案盘点
软件定义汽车时代下，中间件的作用愈发重要。随着EE架构逐渐趋于集中化，汽车软件系统出现了多种操作系统并存的局面，这也导致系统的复杂性和开发成本的剧增。
从而实现标准的接口、高质量的无缝集成、高效的开发以及通过新的模型来管理复杂的系统，这就是我们所说的“中间件”。
汽车行业中有众多的整车厂和供应商，每家OEM会有不同的供应商以及车型，每个供应商也不止向一家OEM供货。
中间件的存在尽可能地让相同产品在不同车型可重复利用或是让不同供应商的产品相互兼容，这样就能大幅减少开发成本。因此，可以说中间件在汽车软硬件解耦的趋势中发挥了关键的作用。
AUTOSAR：目前应用范围最广的车载电子系统标准规范
AUTOSAR（AutomotiveOpenSystemArchitecture）指汽车开放架构，是由全球汽车制造商、零部件供应商以及各种研究、服务机构共同参与制定的一种汽车电子系统的合作开发框架。
ClassicPlatform（CP）：ClassicPlatform是AUTOSAR针对传统车辆控制嵌入式系统的解决方案，具有严格的实时性和安全性限制。
从架构来看，ClassicPlatform自下而上可大致分为微控制器、基础软件层、运行环境层和应用软件层。
AUTOSARCP是为了传统的车载通信技术CAN设计的，不能很好地兼容以太网，难以支持基于车载以太网的通信。
此外，随着汽车智能化程度提高，诸如自动泊车、环境感知、路径规划等高级功能对处理器的高算力需求远远高于对多核的需求。
虽然AUTOSARCP已经应用于传统的多核处理技术，但依旧无法满足车辆对ECU处理能力的需求。
从处理器和半导体的技术角度来看，提高性能的唯一方法是多核并行运行，而并行运行以及所谓的异构计算也大大超出了CP能够覆盖的范围。
1>支持的芯片平台不同：AUTOSARCP主要跑在8bit、16bit、32bit的MCU上，对应传统的车身控制、底盘控制、动力系统等功能，如果涉及到自动驾驶的话，AUTOSARCP可能无法实现；
AUTOSARAP主要跑在64bit以上的高性能MPU/SOC上，对应自动驾驶的高性能电子系统，能够更好地支持多核、多ECU、多SoCs并行处理，从而提供更强大的计算能力。
定义不同：AUTOSARCP并不只是“中间件”，而是“OS内核+中间件”的一套完整的“操作系统”，定义了基本的上层任务调度、优先级调度等。
分布式架构下的芯片主要是MCU，每一个MCU上都需要跑一套AUTOSARCP，例如在基于分布式架构的ADAS功能中，AUOTSARCP便是最常见的“操作系统”。
不同于AUTOSARCP自身已经包含了基于OSEK标准的OS，AUTOSARAP只是一个跑在Lunix、QNX等基于POSIX标准的OS上面的中间件，因此它自身并不包含OS，进一步地推进了软硬件解耦进程。
架构、通信方式、连接方式不同：AUTOSARCP采用的是FOA架构，而AUTOSARAP采用的则是SOA架构；
AUTOARCP采用的是基于信号的静态配置通信方式（CAN/LIN等），而AUTOSARAP采用的是基于服务的SOA动态通信方式（SOME/IP）；
在AUTOSARCP中，硬件资源的连接关系受限于线束的连接，而在AUTOSARAP中，硬件资源间的连接关系虚拟化，不局限于通信线束的连接关系。
基于SOA通信使得AP中ECU可以动态地与其他ECU进行连接，此外AP中各服务模块独立，具有更高的安全性以及部署灵活性。
例如AUTOSARCP的时延可低至微秒级、功能安全等级达到了ASIL-D，硬实时；而AUTOSARAP的时延则在毫秒级，功能安全等级则为ASIL-B，软实时。
这也导致二者应用领域的不同：AUTOSARCP一般应用在对实时性和功能安全要求较高、对算力要求较低的场景中，如引擎控制、制动等传统ECU；
AUTOSAR则应用在对实时性和功能安全有一定要求，但对算力要求更高的场景中，如ADAS、自动驾驶，以及在动态部署方面追求较高自由度的信息娱乐场景。
最常见的分工是，需要高算力的工作交给AUTOSARAP,而需要高实时性的工作则交给AUTOSARCP。
ROS2：可支持自动驾驶场景的中间件
ROS（RobotOperatingSystem）指的是机器人操作系统，是一套开源的软件框架和工具集，用来帮助开发人员建立机器人应用程序，它提供了硬件抽象、设备驱动、函数库、可视化工具、消息传递和软件包管理等诸多功能。
ROS系统是起源于2007年斯坦福大学人工智能实验室的STAIR项目与机器人技术公司WillowGarage的个人机器人项目（PersonalRobotsProgram）之间的合作，2008年之后就由WillowGarage来进行推动。
ROS项目的初衷是为了给科研机器人WillowGaragePR2提供一个开发环境和相应的工具。
为了让这套软件在更多的机器人上运行，ROS为机器人开发提供了一套相对完善的中间层、工具、软件乃至通用的接口和标准，机器人工业领域的开发者因此能快速开发系统原型并进行测试和验证。
ROS2对ROS1的部分缺陷实现了改进和提升，产品环境适用度更广。ROS推出以后被大量地应用于工业领域，包括科研机器人、工业机器人、轮式机器人、自动驾驶汽车乃至航天无人驾驶设备。
其原来的功能设计已经不能满足海量应用对于某些性能（如实时性、安全性、嵌入式移植等）的需求，ROS2即在这样的背景下被设计和开发。ROS2与ROS1的主要区别包括：
ROS1主要构建于Linux系统之上，主要支持Ubuntu；ROS2采用全新的架构，底层基于DDS（DataDistributionService，是一种专门为实时系统设计的数据分发/订阅标准）通信机制。
支持实时性、嵌入式、分布式、多操作系统，ROS2支持的系统包括Linux、windows、Mac、RTOS，甚至是单片机等没有操作系统的裸机。
ROS1的通讯系统基于TCPROS/UDPROS，强依赖于master节点的处理；ROS2的通讯系统是基于DDS，取消了master，同时在内部提供了DDS的抽象层实现。
ROS1运行时要依赖roscore，一旦roscore出现问题就会造成较大的系统灾难，同时由于安装与运行体积较大，对很多低资源系统会造成负担；
ROS2基于DDS进行数据传输，而DDS基于RTPS的去中心化的通信框架，这就去除了对roscore的依赖，系统的稳定性强，对资源的消耗也得到了降低。
ROS2新增了QoS（QualityofService，质量服务原则），主要对通信的实时性、完整性、历史追溯等方面形成了支持。
这大幅加强了框架功能，避免了高速系统难以适用等问题。ROS1缺少QoS机制，Topic的稳定性与质量难以保证。
ROS2可用作自动驾驶中间件，实现与AUTOSARAP中间件类似的功能，但二者存在差别：
ROS2是作为机器人开发的应用框架，在应用和OS之间提供了通用的中间层框架和常用软件模块（ROSPackage），某种意义上可以称作操作系统了。
AUTOSARAP是一套标准，定义了对应用的标准接口，但没有定义实现细节，平台组件间的交互接口是需要AUTOSARAP供应商实现的；ROS2则是代码优先，每个版本都有完整的代码实现，也定义有面向应用标准API接口。
AUTOSARAP从一开始就面向ASIL-B应用；ROS2不是根据ASIL的标准设计的，ROS2实现功能安全的解决方案是要把底层换为满足ASIL要求的RTOS和商用工具链（编译器）。
例如，Apex.AI基于ROS2定制开发的Apex.OS就已经通过了最高等级的ASIL-D认证，这实际上是基于ROS2的架构去实现一套AUTOSARAP规范。
于是希望使用一个“没有中间节点”的通信中间件来代替ROS1，那时ROS2还没有推出，因此自主研发出了CyberRT。
CyberRT和ROS2类似，其底层也是使用了一个开源版本的DDS；为了解决ROS1的问题，CyberRT删除了master机制，用自动发现机制代替，这个通信组网机制和汽车网络CAN完全一致。
CyberRT的核心设计将调度、任务从内核空间搬到了用户空间。相较于其他中间件方案，CyberRT的一大优势是其专为无人架驶设计，包括基础库、通信层、数据层、计算层。
Iceoryx：博世自主研发的针对高级自动驾驶应用的通信中间件
Iceoryx是博世旗下子公司ETAS推出的中间件解决方案。ETAS（易特驰）成立于1994年，是博世的全资子公司。
博世在量产ADAS领域装配率长期占据市场前三的份额，因此他们对于如何将自动驾驶数据高效流转的需求更为迫切。
2020年7月，ETAS推出了针对高级自动驾驶应用的中间件——Iceoryx（冰羚），Iceoryx是一个适用于各种操作系统的进程间通信（IPC）的中间件。
目前已支持Linux、macOS和QNX，可兼容ROS2和AUTOSARAP的接口，以满足不同开发阶段的需求。
以Linux系统为例，不同进程之间传播或交换信息，由于不同进程地址空间相互独立，传递数据时不停的来回拷贝数据，建立和释放堆栈，这个不生成任何价值的拷贝的过程浪费和占有了大量系统资源并产生了不期望的延迟。
为了解决IPC低效率问题，Iceoryx设计了一种“零拷贝”的内存共享技术。
“零拷贝”通过事前定义好的通用接口，将需要消费的数据（图片原始RGB或者激光点云数据）放入由Iceoryx申请好的内存空间，然后引入“记数器”这个概念，来记录内存空间中各块数据是否被调用还是释放。
当计数器为0时，就表示该块数据可以被释放。这样所有的数据调用都发生在共用的内存区域中，免去了各进程将数据拷贝到自己私有存储内，大大提高了数据通信的效率。
基于共享内存的拷贝并不是一种创新的通信机制，但Iceoryx采用了发布/订阅架构、服务发现、和计数器相结合的机制。
通过添加避免复制的应用程序编程接口，实现了所说的真正的零拷贝——一种从发布者到订阅者的端到端的方法，而无需创建一个拷贝。
Iceoryx还需要更多的量产车型的验证以及持续的打磨优化。Iceoryx是开源的，遵从Apache-2.0许可证，任何个人或者团队都可以免费使用源代码。
Iceoryx取决于POSIXAPI，由于不同操作系统的API会有细微差异，因此将Iceoryx移植到另一个基于POSIX的操作系统时，可能需要进行细微的改动。
另外由于自动驾驶感知信息种类越来越多，激光点云数据、摄像头RGGB帧、3D毫米波雷达目标信息以及4D毫米波雷达点云信息、整车信号数据等，如何高效申请和分配内存块也是实现真正“零拷贝”的前提，这也需要在实际项目中不断打磨优化。
其他通信中间件：SOME/IP与DDS等，根据源代码是否开放，通信中间件可简单地分为闭源和开源两种：
闭源的通信中间件主要有Vector公司的SOME/IP、RTI公司的DDS等；开源的通信中间件主要有OPENDDS、FASTDDS、CycloneDDS等。
SOME/IP
严格来说，SOME/IP不是一款特定的产品，而是一种技术标准。2011年，BWM设计和提出了SOME/IP，SOME/IP全称为ScalableService-orientedMiddlewareoverIP。
拆分起来理解就是以Server-Client服务形式进行通信，并且服务具备高度可扩展性。在传统以太网中，OSI将以太网分层七层，但汽车行业将OSI5-7层统称为应用层，因此车载以太网只有5层。
SOME/IP协议是一种应用层协议，运行在TCP/UDP传输协议之上（车载以太网第四层以上），作为以太网通信中间件来实现应用层和IP层的数据交互，使其不依赖于操作系统。
同时又能兼容AUTOSAR和非AUTOSAR平台。因此SOME/IP可以独立于硬件平台、操作系统和编程语言。
SOME/IP可支持AUTOSARCP、AUTOSARAP以及非AUTOSAR平台之间的通信交互。BWM设计SOME/IP协议之后，SOME/IP被AUTOSAR纳入其正式标准。
随着CP规范发布而被广泛用于车载以太网，因此可以说是AUTOSARCP推动了SOME/IP的广泛使用。
借助SOME/IP协议的高度平台扩展性，可以实现不同平台的数据交互，而统一的SOME/IP通信机制是不同平台通信的前提。
为了在不同软件平台上运行SOME/IP，使得整车以太网上实现SOA架构通信机制，所以AP规范中也同步引入了SOME/IP，因此对于AUTOSAR系统，CP和AP之间实现SOME/IP通信，是比较容易的。
为了使非AUTOSAR软件平台和车内CP和APECU更好地交互，GENIVI系统同样也开发了一套开源vSOME/IP软件源码，以便和CP/AP交互。
但vSOME/IP是开源的，所以性能会差一些，因此需要统一的规范来做约束，从而做一些深层次的二次开发。当前，全球最大的商用SOME/IP产品供应商是Vector，开源版的vSOME/IP则是由GENIVI协会来维护的。
DDS
DDS（DataDistributionService）指的是数据分发服务，是由OMG发布的分布式通信规范。
OMG（ObjectManagementGroup）成立于1989年，是一个国际性、开放性、非盈利性技术标准联盟，由供应商、终端用户、学术机构、政府机构推动，到现在已有30多年历史
OMG工作组会针对各种技术和行业制定企业集成标准，并开发可为数千个垂直行业提供现实价值的技术标准，其中包括统一建模语言SYSML、UML，以及中间件标准CORBA、DDS等。
DDS最早应用于美国海军系统，用于解决军舰系统复杂网络环境中大量软件升级的兼容性问题。随着DDS被ROS2以及AUTOSAR引入，目前DDS已被广泛应用于航空、航天、船舶、国防、金融、通信、汽车等领域。
DDS采用发布/订阅模型，提供多种QoS服务质量策略，以保障数据实时、高效、灵活地分发，可满足各种分布式实时通信的应用需求。
DDS将分布式网络中传输的数据定义为“主题”，将数据的产生和接收对象分别定义为“发布者”和“订阅者”，从而构成数据的发布/订阅传输模型（Data-CentricPublish-Subscribe，DCPS）。
各个节点在逻辑上无主从关系，点与点之间都是对等关系，通信方式可以是点对点、点对多、多对多等，在QoS的控制下建立连接，自动发现和配置网络参数。
目前DDS已被多个车载中间件平台引入。2018年，DDS首次被引进AUTOSARAP，以作为可选择的通信方式之一。
2018年3月，DDS的主要提供者RTI公司宣布，AUTOSARAP当时的最新版本（版本18-03）已经具有DDS标准的完整网络绑定。
AUTOSARCP的标准规范中是不支持DDS的，但做一些变通后也可以在CP上集成DDS。
如前文所述，ROS2和CyberRT的底层也均使用了开源的DDS，将DDS作为最重要的通信机制。与中间件相对应，Xavier、Orin等面向自动驾驶的SOC芯片上也都预留了DDS接口。
目前，全球DDS最大的供应商是美国的RTI（Real-TimeInnovations）公司，约占据市场80%的份额。RTI作为OMG组织董事会的成员，也主导了DDS标准的制定，在行业内有足够的权威。
开源DDS是相对于商用的RTIDDS等而言的，其也是根据OMG官方标准开发的，但源代码开放，主要包括FastDDS或OpenDDS等。
尽管开源DDS会对RTI的商用DDS形成一定竞争，但开源DDS也存在不足：开源DDS的使用门槛高。
例如RTIDDS的服务策略有50多个，但开源DDS的服务策略只有23个，完整程度远不及前者；RTI的DDS已经通过了ASIL-D的认证，但开源DDS还没有。
SOME/IP与DDS的不同
SOME/IP与DDS是目前自动驾驶上用得最多的两类通信中间件，二者的共同点主要有：都是面向服务的通信协议；都采用了“以数据为中心”的发布/订阅模式。
当然SOME/IP与DDS在很多方面也存在不同，主要区别如下：
DDS是一个工业级别的强实时的通信标准，它对场景的适应性比较强，但在用于汽车/自动驾驶领域时需要做专门的裁剪。
当AUTOSARAP与DDS一起构建通信框架时，该框架不仅可以与现有API及应用程序兼容，并且在可靠性、性能、灵活性和可伸缩性等方面，都可以提供重要的好处。
订阅方和发布方是否强耦合：在SOME/IP中，在正常数据传输前，订阅方需要与发布方建立网络连接并询问发布方是否提供所需服务，在这个层面上，节点之间仍然具有一定耦合性。
在DDS标准下，每个订阅方或发布方只需要在自己的程序里面订阅或发布传感器数据就行了，不需要关心任何连接。因此在DDS中，服务订阅方和发布方的解耦更加彻底。
服务策略不同：较好的QoS是DDS标准相比于SOME/IP最重要的特征。SOME/IP只有一个QoS；
RTIDDS和开源DDS里面分别有50多个和20多个QoS，这些QoS基本上能涵盖绝大多数可以预见到的智能驾驶场景。
应用场景不同：从应用场景的角度来看，SOME/IP比较偏向于车载网络，且只能在基于网络层为IP类型的网络环境中使用；
DDS在传输方式上没有特别的限制，对基于非IP类型的网络，如共享内存、跨核通讯、PCI-E等网络类型都可以支持。
DDS也有完备性的车联网解决方案，其独有的DDSSecurity、DDSWeb功能可为用户提供车-云-移动端一站式的解决方案。
在商业落地中，SOME/IP与DDS是直接竞争关系，但由于二者在应用领域、灵活性、服务策略等方面存在差异，因此整车厂可以按需进行选择合适的通信中间件，二者甚至是可以共存的。这也是为什么AUTOSARAP既支持SOME/IP也支持DDS。
车载中间件有望成为国内汽车软件供应商的机遇点
车企在中间件方案上有多种选择，AUTOSARAP目前或难以“一枝独秀”。随着EE架构逐渐由分布式向集中式演进，MCU也将逐步被SoC取代。
AUTOSARCP被AUTOSARAP、ROS2、CyberRT等中间件方案替代也是大势所趋。然而，并不是所有的车企都选择了AUTOSARAP，主要原因包括：
使用成本高：AUTOSARAP的费用可达几百万元，此外对于不同的域控制器、不同的芯片需要重复收费，这会给小型车企带来很大的成本压力。
存在效率不高的问题：AUTOSARAP的配置很多，它是通过配置加上一部分代码去实现自己的功能。但配置多了之后，会存在代码臃肿以及低效的问题。
静态部署与动态部署的理念的冲突：AUTOSARAP是从AUTOSARCP发展而来的。AUTOSARCP是静态部署，只适用于相对简单的业务逻辑和功能，其代码是固化的，功能是无法改变的，类似于过去的功能手机；
AUTOSARAP则类似现在的智能手机，APP可以跨平台、跨机型部署。这种动态部署的理念和之前的静态部署概念不甚相同，而其方法论却是基于静态部署衍生而来的，因此在实践层面会存在不少问题。
当前无法满足智能网联的需求：云端跟车端所使用的操作系统不一样，而AUTOSAR只能负责车内的通信，不能支持车端到云端的通信。
因而无法支持车路协同场景（车端跟云端的通信是通过MQTT、Kafka等中间件来实现的）。除此之外，AUTOSAR能否兼容车辆网联化中需要用到的数据平台、通信平台和地图平台也存在疑问。
由于当前AUTOSARAP还存在如上的一些问题，越来越多的OEM不太想完全用AUTOSAR去解决智能驾驶操作系统的问题。
安波福、采埃孚、大陆等公司提供的方案，仍然是基于AUTOSARCP标准的接口。不同于已经非常标准化的AUTOSARCP，AUTOSARAP目前标准还不是很完善，标准每年在更新。
因此很多主机厂也采取了观望的态势，毕竟AUTOSARAP成本较高。在这个背景下，ROS2、CyberRT等其他中间件方案也有望得到更多车企的青睐。
车企自研中间件难度较大，由软件供应商提供中间件方案或与供应商共同开发中间件更具性价比。中间件技术更加偏底层，目的是帮助主机厂降低上层软件的开发难度，提高开发效率。
此外，随着中间件越来越成熟，最终有望形成一套被广泛应用的标准化软件，对于主机厂而言没必要投入大量人力、物力去自研中间件，由中间件供应商提供更具性价比。
当然也有主机厂认为，中间件的功能对于实现自动驾驶有重要意义，例如数据通信、资源管理、任务调度等，同时中间件对应用功能的实现也会有影响，因此中间件还是需要存在差异性的，此时部分主机厂会选择自研中间件。
但对于主机厂而言，对软件及中间件Know-how积累较浅，也没有太多成功的案例，即使通过大规模地招聘，若没有软件公司的思维也难以协调好众多的软件人才。
对于软件/中间件供应商而言，他们更加容易与多家主机厂达成合作，从而扩大软件和中间件应用的范围和场景，对Know-how的积累是显著优于主机厂的。
因此对于主机厂而言，更可行的道路还是跟专业的中间件厂商合作，以此保证自己开发的个性化软件可以顺利地与通用化软件组合起来，而供应商也可以在提供标准产品的基础上再为主机厂提供半定制化的服务。
尽管目前海外厂商及开源中间件依旧为主流，但本土中间件解决方案提供商的机会正在来临。
对于通信中间件而言，购买国外产品可能会遇到“卡脖子”问题，因为核心技术由外方掌握，应用于某些关键业务场景就可能存在隐患。
国外的通信中间件一开始不是以智能驾驶领域为目标，基本上是以军工和工业互联网为目标开发的，最近几年才慢慢被AUTOSAR引入。
因此，对于车厂而言，在国外产品上进行针对智能驾驶场景的开发难度比较大，成本也非常高。
另一方面，海外的厂商在国内没有庞大的技术支持团队，因此大多情况下只是给车企提供基础软件或一揽子解决方案，难以提供定制化开发服务。
本土中间件解决方案提供商的优势在于，可以为车厂提供定制化开发的服务，服务相应也会比国际厂商及时，并且在收费上更具弹性。
公司在操作系统底层技术上积累深厚。成立初期，公司聚焦智能终端操作系统的开发，并与产业内的移动芯片、智能终端、应用软件等厂商建立起了坚实的合作关系，逐步在底层系统领域取得了优势。
上市之后，公司通过连续的收购加强了视觉技术及车载系统的技术积累，同时凭借着多年底层系统开发经验顺利地切入车载及IoT操作系统领域。
逐步实现了底层OS到应用层的延伸，而各业务支撑的核心依旧是公司的操作系统能力以及视觉、AI等方面长期的算法积累。
目前，公司在Android、Linux、RTOS、ROS、鸿蒙等操作系统，以及智能视觉、智能语音、UI引擎等领域已有深厚积累，其核心技术涵盖通信协议栈、深度学习、图形图像算法、操作系统优化和安全技术等多个方面。
公司具备提供从底层系统软件、中间件再到上层应用的全栈式解决方案的能力。
功能软件方面，平台具备提供音频及图像处理、传感器融合、车内网络等模块的能力；上层应用方面，基于Kanzi，平台提供信息娱乐系统、智能仪表、ADAS和影音集成等产品，提供5G、云服务并支持FOTA升级；
平台提供的中间件方案可实现软硬件接口的标准化，进而支持SOA架构汽车的持续迭代升级。总结来看，公司的智能座舱方案实现了场景和服务的解耦，可快速完成场景服务的开发变更及升级迭代。
在智能座舱方面，公司实现了采用“一芯多屏”架构并基于瑞萨R-CAR芯片及Hypervisor技术的智能座舱软件解决方案。
该解决方案基于瑞萨单个高性能核心车载处理器，利用Hypervisor虚拟化技术，同时运行QNX和Android两套操作系统，以不同的中间件、人工智能算法、应用软件为核心，实现液晶仪表、抬头显示（HUD）、信息娱乐以及多屏互动等功能；
在智能驾驶方面，公司深度融合摄像头、超声波雷达与毫米波雷达的感知数据，并结合车辆特性构造包含高实时性的驾驶地图、安全舒适的智能驾驶路径计算及车辆控制算法等功能或技术的智能驾驶软件解决方案。
东软睿驰在创建之初就成立了基础软件团队，参与AUTOSAR组织，不断将发展中积累的对新兴软件平台和工具的认识，进行总结提炼，融合到自主研发的基础软件平台产品NeuSAR之中。
NeuSAR获颁ISO26262产品认证证书，标志着东软睿驰已建立起符合功能安全最高ASIL-D级别的产品开发流程体系，同时产品已经达到国际先进水平。
NeuSAR产品主要由cCore、aCore、中间件和工具链组成，其中NeuSARcCore基于AUTOSARClassicPlatform标准开发，主要针对传统控制系统等实时性要求较高的汽车产品开发场景。
3月，公司正式升级为AUTOSAR高级合作伙伴。公司于2009年与AUTOSAR联盟结缘，成为AUTOSAR组织的AssociatePartner，是国内首家加入AUTOSAR组织的基础软件供应商。
旨在为国内的OEM和供应商提供稳定可靠、便捷易用的AUTOSAR平台。2020年3月，EAS获得了ISO26262产品功能安全ASIL-D证书。