SRS与SWS在autosar中的含义

SRS,Supplemental Restraint System，即辅助约束系统，安全气囊就属于这一系统,如果你是在汽车上的座骑和方向盘上看到意思就是有安全气囊。不知道你是不是在车里看到的！

一直以来， 汽车 厂商都会对自家的自动驾驶架构三缄其口。

但宝马这次的 *** 作很是让人意外：在前不久的发布会上，宝马毫无保留地将自动驾驶平台架构对外进行了分享。

在这次的线上发布会上，宝马罗列了整合进自家车辆的关键构件与主要芯片供应商。

如此透明的分享，也让外界认识了 宝马自动驾驶的硬件架构 及其 量产路径 。

1、软件与硬件的可扩展性与复用性

通过这次分享，宝马的自动驾驶平台架构也能帮助我们更加理解这家德国巨头在自动驾驶设计上的优先级。

纵观宝马乘用车型，无论是Level 2还是Level 4/5 级别自动驾驶，其硬件和软件（例如ECU和摄像头）都非常重视复用性，因为这样可以节省大量成本。

宝马的基础平台基于AUTOSAR（ 汽车 开放系统架构）打造，使用了大量传统微控器（比如英飞凌的Aurix）。

随着自动驾驶级别的不断提升与功能的增加，宝马开始通过增加额外的传感器系统与高端微处理器来满足性能要求。例如，前置立体相机的相关应用使用英飞凌 Aurix微控器与瑞萨 R-CAR SoC来优化。对 Level 3车型 ，宝马选择在平台中整合两颗 Mobileye EyeQ5 芯片，两个英特尔Denverton CPU和一个额外的Aurix微控器。

在更高级别的 Level 4/5车型上 ，宝马则另外增加了一颗 EyeQ5，一个Xeon 24C和一个Aurix微控器。

2、用设计来提升安全

按照自动驾驶堆栈的划分：

L1/L2被归为 ADAS ，而L3/L4/L5则属于 HAD （高级别自动驾驶），自动驾驶能力则随着级别的不同而逐步递增。

在宝马的架构下，L2则成了L3的一个备份。系统会运行独立的ECU，同时用到传统的和适配的AUTOSAR。

到了HAD的范畴后，就需要依靠ASIL-B通道。

总体而言，系统的安全性甚至大于其他各部分之和。

在推动自动驾驶研发的过程中，“安全至上”已经是许多 汽车 厂商的重要议题。

不过，到底如何 用设计来提升安全 依然是一个很少被公开提及的问题。

宝马则直接披露了在高级别自动驾驶架构下的 自动驾驶路线图 和 安全第一战略 。

在发布会上，宝马集团自动驾驶首席专家 Simon Fürst 表示：

为了保证L3/L4/L5的安全性，宝马在车辆里安装了双重处理架构，一台是主力机，另一台则是备份机。

在这样的架构下，主要和次要两个ASIL通道分别承担了车辆主轨迹计算和主通道的监督工作。

只要次通道发现主通道生成了可能会导致事故或碰撞的轨迹，它就会发出警告，并将车辆拉回次通道提供的安全轨迹。

主次通道一直进行交叉检验——Fürst指出，这是经典的行为检查方法。

当主次通道发现自己在轨迹问题上存在分歧时，系统将进入降级模式。

降级模式下，会有另一个处理模块出面“主持工作”，其背后是一套独立的电源。即使出现重大供电故障，车辆也能继续以降级模式运行。

简言之，宝马的L2堆栈是L3的备份。

这个通道的功能独立于主系统，它可以驱动冗余的制动/转向系统，使车辆进入安全位置。

但正如Fürst所讲的那样，由于能力有限，这套冗余单元无法执行全部功能。

另外，我们来谈一谈传感器的融合难题。

一般来说，搭载在车辆上的不同传感器，负责不同的功能。

在进行传感器评估时，主要部分就是其道路上物体的探测能力，包括乘用车、卡车、摩托车、自行车和行人。

当然，这里重要的不仅仅是目标探测，计算这些目标的轨迹并找出“安全区域”也相当重要。

自动驾驶系统除了能利用一些基于计算视觉的机制来监控道路状况，还能借助雷达和激光雷达的输入甚至来自其他车辆的数据来探测障碍物。

此外，借助地图获得的定位也相当重要，它是系统计算线路和轨迹的重要依据。

但搞定传感器融合并非易事——因为数据也分： 原始数据 、 分类数据 和 高级数据 。

举例来说，原始数据来自于雷达、激光雷达和摄像头，不同的传感器还要配合不同的算法，再加上不同等级的数据，复杂性可想而知。

另外，当 汽车 厂商想要更新现有传感器时，他们需要一个通用接口来简化过程。

同时，如果数据结构标准化，那么新的分类和预处理数据投入使用后，就能帮助工程师大大改善传感器融合水平。

因而，Fürst 认为， 标准化接口 和 数据结构 至关重要。

3、为什么需要一个全新的ISO标准？

关于车辆安全，业界有很多标准。

但当下专门针对自动驾驶 汽车 的 DTR-4804 ，被视为朝着 ISO标准化迈出的第一步。

去年，11家行业巨头：安波福、奥迪、百度、宝马、大陆、戴姆勒、FCA、HERE、英飞凌、英特尔和大众齐聚一堂，共同推出了名为 SaFAD （自动驾驶安全优先）的白皮书。

现在，他们正在力推SaFAD，希望将白皮书变成 ISO DTR 4804的基础。

今年2月，这 11 家公司还专门在法国巴黎召开了启动会议，同时吸纳了丰田、日产、电装、马自达、法雷奥等重量级公司。

Fürst 坦言，想让这个草案成为正式的ISO标准可能还需要2 到 3年时间。不过越早开始，业界就越有机会尽早拿出自动驾驶安全标准。

为何标准这么重要？如果 汽车 行业不制定安全标准，会带来什么后果？

如果没有标准，最终带来的后果是：不同的 汽车 厂商、不同的技术供应商会开发出具有不同风险的车辆。

而这，与自动驾驶安全标准的目标——最大程度降低总体风险是相悖的。

最后，如何评价宝马的自动驾驶平台架构？

有业内人士指出：宝马的这一平台架构在传统与现代之中取得了平衡。

简单理解，就是现代化的 AI 主要负责感知，而备份则基于传统的确定性算法。

Fürst 也强调，这类系统设计的优势在于：系统的主要部件都符合 ASIL B，只有一些小部件才依赖 ASIL D。

据悉，这些小部件包括车辆动态 ECU（动作控制），轨迹追踪控制，失效降级 ECU 和选择器等。

至于车辆功能安全性问题，宝马的安全架构“算得上是业界领先”。

这是宝马的情况，其它 汽车 厂商是什么水平呢？据悉，目前行业内走的差不多都是宝马这条路子。

AUTOSAR（ 汽车 开放系统 架构 ）于 2017 年 3 月 31 日首次发布其自适应平台，作为电子控制单元 (ECU) 的标准化集成平台。

AUTOSAR 自适应平台基于 POSIX *** 作系统，是新 汽车 大趋势的 ECU 标准。它结合了基于微控制器的 ECU 的安全性和基于微处理器的多媒体 ECU 提供的高性能

新标准避免了 OEM 及其供应商使用专有和单独的方法重复开发此类软件平台的关键和复杂功能的昂贵替代方案。

AUTOSAR的“核心合作伙伴”有宝马集团、博世、大陆集团、戴姆勒、福特、通用 汽车 、PSA集团、丰田和大众集团。

Rust 是一种多范式、通用编程语言，旨在提高性能和安全性，尤其是安全并发性。Rust 在语法上与 C++ 相似，但可以在不进行垃圾收集的情况下保证内存安全。Rust 被称为系统编程语言，除了 函数式编程 等高级特性外，它还提供了低级内存管理机制。

在提升 C++14 编码指南方面经验丰富 AUTOSAR 希望保持其创新传统，并成为以功能安全和 汽车 网络安全为重点的标准化机构。

因此，决定在功能安全工作组 (WG-SAF) 内成立一个小组并调查 Rust 在 AUTOSAR 自适应平台中的使用情况。

Rust工作组将于 2022 年 4 月正式启动，并计划制作两份文件。其中一份文件将提供有关如何在 AUTOSAR 自适应平台项目的上下文中使用 Rust 的指导。另一份文件将提出关于 Rust 的编码指南。

原文：>

电动汽车的动力输出依靠电池，而电池管理系统BMS(Battery Management System)则是其中的核心，负责控制电池的充电和放电以及实现电池状态估算等功能。通常情况下，BMS主要包括硬件、底层软件和应用层软件三部分，下面就来给大家详细介绍一下。

硬件

1、功能

硬件的设计和具体选型要结合整车及电池系统的功能需求，通用的功能主要包括采集功能(如电压、电流、温度采集)、充电口检测(CC和CC2)和充电唤醒(CP和A+)、继电器控制及状态诊断、绝缘检测、高压互锁、碰撞检测、CAN通讯及数据存储等要求。

2、架构

BMS硬件架构分为分布式和集中式：

(1)分布式包括主板和从板，可能一个电池模组配备一个从板，这样的设计缺点是如果电池模组的单体数量少于12个会造成采样通道浪费(一般采样芯片有12个通道)，或者2-3个从板采集所有电池模组，这种结构一块从板中具有多个采样芯片，优点是通道利用率较高，节省成本;

(2)集中式是将所有的电气部件集中到一块大的板子中，采样芯片通道利用最高且采样芯片与主芯片之间可以采用菊花链通讯，电路设计相对简单，产品成本大为降低，只是所有的采集线束都会连接到主板上，对BMS的安全性提出更大挑战，并且菊花链通讯稳定性方面也可能存在问题。

3、通讯方式

采样芯片和主芯片之间信息的传递有CAN通讯和菊花链通讯两种方式，其中CAN通讯最为稳定，但由于需要考虑电源芯片，隔离电路等成本较高，菊花链通讯实际上是SPI通讯，成本很低，稳定性方面相对较差，但是随着对成本控制压力越来越大，很多厂家都在向菊花链的方式转变，一般会采用2条甚至更多菊花链来增强通讯稳定性。

4、结构

BMS硬件包括电源IC、CPU、采样IC、高驱IC、其他IC部件、隔离变压器、RTC、EEPROM和CAN模块等。其中CPU是核心部件，一般用的是英飞凌的TC系列，不同型号功能有所差异，对于AUTOSAR架构的配置也不同。采样IC厂家主要有凌特、美信、德州仪器等，包括采集单体电压、模组温度以及外围配置均衡电路等。

底层软件

按照AUTOSAR架构划分成许多通用功能模块，减少对硬件的依赖，可以实现对不同硬件的配置，而应用层软件变化较小。应用层和底层需要确定好RTE接口，并且从灵活性方面考虑DEM(故障诊断事件管理)、DCM (故障诊断通信管理)、FIM(功能信息管理)和CAN通讯预留接口，由应用层进行配置。

一．中间件的定义与作用

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。

（摘自超星未来）

2ROS 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是中间件时，这个中间件是很明确的 LBSW层语义，即处于计算机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的问题”。

萧猛认为，只要能补齐 LBSW层所需要完成的所有功能、补齐 A 轴所有切面要求的特性，ROS 2就能用于自动驾驶量产车。如前段时间刚拿到采埃孚等多家巨头投资的ApexAI公司基于ROS 2定制开发的ApexOS就已经通过了最高等级的ASIL D认证。

萧猛说：“这实际上是基于 ROS 2的架构去实现一套 AUTOSAR AP 规范。这可以成为一个单独的产品，投入时间+人+钱可以开发出来，只是看有没有必要，值不值得”。

在具体的实践中，ROS 2跟AUTOSAR AP存在直接竞争关系——尽管对用户来说，并不存在严格意义上的“二选一”问题，但通常来说，若选了ROS 2，就不会选AUTOSAR AP了；若选了AUTOSAR AP，就不会选ROS 2了。

3 CyberRT

Cyber RT是百度Apollo开发出来的中间件，在Apollo 35中正式发布。Cyber RT和ROS2是比较像的， 其底层也是使用了一个开源版本的DDS。

百度最早用的是ROS 1,但在使用的过程中逐渐发现了ROS 1存在“若ROS Master出故障了，则任何两个节点之间的通信便受到影响”的问题，所以就希望使用一个“没有中间节点”的通信中间件来代替ROS 1，那时还没有ROS2，所以自己去做了一个Cyber RT。

为了解决 ROS 遇到的问题，Cyber RT删除了master机制，用自动发现机制代替，这个通信组网机制和汽车网络CAN完全一致。此外，Cyber RT的核心设计将调度、任务从内核空间搬到了用户空间。

（出处：>

以上就是关于SRS与SWS在autosar中的含义全部的内容，包括:SRS与SWS在autosar中的含义、从硬件架构看宝马自动驾驶量产路径、汽车开放系统架构AUTOSAR宣布在成立Rust工作组等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！