作者：老榴
摘要：在汽车行业，AUTOSAR是一个由汽车原始设备制造商（OEM）、供应商和其他行业成员组成的国际联盟，他们于2003年发布了第一个参考架构AUTOSAR Classic，它的重点不在于独立于底层硬件的动态应用，但是随着SOA和自动驾驶的日益重要，2018年发布的第二个标准Adaptive AUTOSAR则解决了这些需求。然而汽车行业并不是第一个面临向动态和灵活的通信模式转变的行业，在物理系统和机器人技术的环境中，也发生了类似的演变，在这个背景下，广泛使用的ROS1（一套开源的库和工具集，用于软件架构开发）无法满足实时性、安全性和跨平台互操作性的需求，其继任者ROS2以及EDMS等中间件解决了这些缺点，并实现了面向服务的通信。这些中间件在研究环境中被广泛使用，用于实现软件封装和通信，也在汽车电气/电子架构的背景下得到了应用。现在甚至有经过认证的解决方案，满足电气和/或电子系统的功能安全标准（ISO26262）和必要的汽车安全完整性级别（ASIL），关于ADAS功能和高度连接的车辆背景下的面向服务的架构（SOAs），仍有许多问题有待解决。
01.
AP AUTOSAR以及ROS的概念
Adaptive AUTOSAR是一个官方定义的术语，将其描述为 “用于自适应应用程序（ARA）的AUTOSAR运行时。提供两种类型的接口，即服务和API，该平台由功能集群组成，这些功能集群又分组在服务中，并且构成了自适应AUTOSAR基础” 。实际上，它是另一个机器人框架，由以下所称的功能集群组成：该框架的规范由AUTOSAR联盟开发。然后由Vector、ETAS、Elektrobit、东软睿驰、Mathworks、Aubass等公司进行实际实现，开发工作由联盟成员完成，只有规范是公开发布的，Adaptive AUTOSAR基于用于在单核微控制器上编程应用程序的经典AUTOSAR。
汽车的电子/电气（E/E）架构作为一个系统，包括软件（SW）和硬件（HW）组件以及机械部件。传统的分布式架构的特点是HW和SW紧密耦合在许多电控单元（ECU）上。相反面向服务的架构使应用软件和执行硬件相互独立，为了实现这种松耦合的架构，操作系统（OS）和中间件起着关键作用。中间件层主要负责ECU之间的通信，因此，中间件的要求包括在整个车辆架构内或与云和后端基础设施进行抽象和虚拟化通信的执行，这些系统组件之间的通信在系统开发期间可能是未知的，因此，在互连系统中，通信是动态的，需要在运行时灵活地建立链接，在连接车辆中产生的大量数据和面向服务的架构导致了新协议在E/E架构中的集成。作为自适应AUTOSAR规范中指定的动态通信的汽车参考架构，将功能应用程序和一个符合POSIX标准的操作系统与名为自适应应用程序运行环境（ARA）的模块化层分开。在ARA中，定义了接口和服务，用于指定操作系统访问和一个通信中间件，以基于以太网实现面向服务的架构。自适应AUTOSAR的首个版本中，指定了可扩展的面向服务的IP中间件（SOME/IP）作为相应的标准化架构的中间件协议。ROS框架是一个由软件工具、库、协议和API组成的集合，旨在简化为复杂的多传感器、多执行器系统开发软件的任务。在大多数情况下，机器人框架的使用决定了开发软件的一般架构原则。例如软件是集中式还是分散式，实时还是非实时等，关键组成部分是中间件，它是将机器人框架的众多组件粘合在一起的关键，中间件的最基本任务是提供自主车辆中软件节点之间的通信基础设施。ROS框架的典型用例是提供系统的上层（软件）和低层（硬件）组件之间的基本接口。这些接口和组件包括各种操作系统（OS）特定的驱动程序，单个开发人员开发这些驱动程序可能需要很长时间。ROS的架构如下图所示：自适应AUTOSAR规范和ROS两者的关键区别在于ROS采用“先编码，再规范“的方法，因为ROS在机器人领域已经使用和验证了12年，自适应AUTOSAR部分是从零开始编写的，部分采用了经过验证的技术，如SOME/IP3、DLT4和UDS5，自适应AUTOSAR遵循” 先规范，再生成代码“的方法。EDMS (ETAS Deterministic Middleware Solution)是博世智能驾驶架构平台对标ROS开发的中间件。在大型社区和数据记录、回放、可视化和调试等工具方面，EDMS表现出色，它还可以与其他语言（如Python和Java）进行绑定，EDMS利用常见的开源工具，而不是由各个AUTOSAR供应商提供的工具，因此用户群规模较小，自适应AUTOSAR使用面向服务的SOME/IP，而EDMS使用面向数据的DDS，前者只能在UDP和TCP之间切换，而后者具有QoS（服务质量）。由于DDS的存在，EDMS中的数据传输非常高效快速，这得益于共享内存（SHM）和零拷贝实现。
首先，标准平台软件支持 EDMS AD 中间件。由 POSIX 操作系统（QNX 或 Linux）加上特定的硬件加速器、CUDA、Nvsci 等以及 DDS 或 SOME/IP 等标准通信堆栈组成。
除了 AD 中间件，平台软件在 EDMS中由博世的 VRTE AUTOSAR 自适应实现完成。AUTOSAR Adaptive 非常有用，因为它可用于直接托管对安全性和确定性没有强烈要求的非 AD 功能。因此，EDMS可以为此类“标准”uP 应用程序提供完整的 AUTOSAR Adaptive API（具有标准中定义的所有功能）。
此外，EDMS还使用 VRTE 为 EDMS运行时提供基本服务，例如日志记录或诊断。因此，EDMS应用程序可以在 EDMS VCU 中与 AUTOSAR 自适应应用程序一起无缝运行。EDMS可以提供额外的设施来支持和加速 AD/ADAS 开发，同时还可以在同一台机器上启用 AUTOSAR 自适应应用程序，这两个元素都构建在一个通用的基础架构框架上，可以在 EDMS应用程序和自适应应用程序之间实现快速高效的通信。
EDMS提供AD 中间件和全面的工具和元素。EDMS运行时，也称为“中间件”，是 EDMS在ECU 上运行的方面。作为中间件，运行时位于体系结构中的操作系统和硬件之上。它提供 EDMS部署、构建和重新计算工具使用的执行控制、通信服务和数据记录服务，以支持AD/ADAS 应用程序的开发和执行。EDMS中间件 API是 为 AD 应用程序设计的“简约”API，可改进涵盖通信、执行和数据捕获的稳健应用程序开发。
2、 EDMS的特点
EDMS是一个独立的软件包，但在实际项目中它将与 AUTOSAR Adaptive 并行存在，因为有几个功能不是 EDMS的一部分（例如ECU间通信、诊断通信、持久性、密码学等）·通过取证重新计算加快调试速度通过可重现的基于仿真的验证
EDMS旨在解决 AD 问题域，因此确定的要求——硬件独立性、需要快速迭代开发的开放世界问题解决、支持收集验证和验证证据等，旨在由 EDMS解决。
EDMS通过利用多种技术解决了AD/ADAS开发的问题。EDMS亮点包括：·高性能面向服务的通信——零拷贝 IPC 提供 AD/ADAS 中使用的大数据集所需的恒定时间缩放和高带宽 (>10GB/s)·从 HW 和 OS 抽象——一种与 HW 无关的开发方法将功能开发与部署到平台分开——这支持 SW 重用和重新定位以及灵活和可扩展的部署——EDMS中间件可以部署到嵌入式微处理器，以便在实验室中运行应用程序，在测试车，并在生产中·高性能数据记录辅助可重复执行的时间和数据确定性 收集安全和验证证据的分析通过重新计算V&V 的确定性重新计算，记录可以从试驾数据中调试问题。在这里，通过重新计算支持优化开发周期，允许通过重新计算活动中一组可运行对象的历史执行进行验证，并在试驾或实验室设置中记录数据。YAAA 是一种基于文本的域特定语言（DSL），专为 AD 开发而设计。使用 DSL 意味着模型易于人类阅读，因此可以轻松审查，此外，通用源代码控制机制可用于合并更改或以与管理项目源代码完全相同的方式控制访问。YAAA 不仅支持活动和可运行对象的规范，还支持数据如何在可运行对象之间流动，例如可运行对象 A 产生的数据由可运行对象 B 使用。YAAA 还可以指定 SW 中的活动如何被触发—是定期触发还是由数据触发——以及runnables的执行预算。基于该模型，可以离线验证时序约束，或者可以在运行时监控违规情况。基于 DSL，YAAA 支持与编译器一样的工具链集成。实际上，EDMS中就包含了这样一个编译器 YAAAC，它基于 YAAA 模型为 EDMS提供代码生成。YAML-as- architecture方法的基础是将代码和架构放在一起，以便它们可以作为一个整体进行管理；架构即代码的方法。所有工件都是在基于文本的环境中使用基于 YAML 的模板定义的，例如您最喜欢的编辑器。EDMS包括编辑器插件等便利功能，可通过语法高亮显示等 “必备“ 功能简化流程。一个例子是广泛使用的 Visual Studio Code 的编辑器扩展插件；这既支持通常的自动完成编码支持，YAAA DSL 的语法高亮显示，也支持通过 GNU 调试器 (GDB) 进行的调试支持。虽然 YAAA 非常适合确保开发人员将代码和架构作为一个整体来管理——从而确保它们保持同步——但有时获取架构的图形视图还是很有用的。对于可视化， EDMS提供了YAAA-Vis ，它使用由 YAAAC 生成的可点击的基于 Web 的架构可视化。YAAA-Vis 可视化由YAAA 代码生成器 (YAAAC) 支持。YAAAC 是一个命令行工具，它生成所有中间件相关的源代码和配置文件，这些源代码和配置文件是构建和部署由 YAAA 模型和功能用户代码描述的 YAAA 应用程序所必需的。生成的文件取决于所选的中间件类型/版本。YAAA-Vis 支持只是 YAAAC 的输出之一。其他包括，特别是对于 CARMA 中间件，各种代码工件：·建模活动、ECU 本地调度组件和 ECU 间通信网关的主要文件生成的源代码和功能用户代码随后针对选定的目标架构进行编译和链接。生成的可执行文件已准备好部署到目标硬件并在其上执行。如前所述，代码生成只是 YAAAC 的任务之一。它还用于使其他外部工具可以访问加载的 YAAA 模型的内部表示，方法是将模型导出为基于文本的表示，或者通过 Python API 提供对模型的动态访问。在任何一种情况下，外部工具都可以访问完整的模型内容，例如所描述的软件架构、硬件架构或部署信息。YAAA-VIS 只是此类外部工具的一个示例，正如我们所见，它用于生成软件和硬件架构的图形表示，可以是静态 SVG 图像，也可以是交互式 HTML 页面。EDMS中间件称为 CARMA，由支持 EDMS执行（包括调度、高带宽通信和访问 HWA）的客户端库和通信/运行时库组成。EDMS中间件旨在在实验室、测试车和生产中无缝部署。同样的中间件也可以部署到开发人员 PC/计算集群，以及在微处理器上测试运行后重新计算相同的应用程序，而无需修改应用程序代码。为此，我们需要 EDMS中的应用程序模型。EDMS应用程序包含活动——这些活动可以是任何任务，例如作为 AD/ADAS 应用程序的一部分执行的图像感知。活动由时间或数据触发，并且包含由 EDMS工具中定义的依赖项连接的可运行链，作为应用程序架构设计的一部分。ADAM（Awesome Decentralized Activation Management）的库，它负责以时间和数据驱动模式激活活动，以支持确定性和并发性。该库不直接由应用程序使用，而是提供一个 EDMS内部客户端 API，该 API 在 EDMS生成的代码中使用，以生成反映活动设计的活动可执行文件。ADAM 是一个去中心化的激活库，这意味着在并行运行的不同活动之间没有同步（按设计）。ADAM 支持数据驱动激活（连接注册的Iceoryx接收器以在数据到达时激活活动）和时间驱动激活（允许设置周期时间和偏移量）。
高效、高带宽的通信对于 AD/ADAS 至关重要。传统的汽车软件具有适度的通信需求——例如，引擎控制软件的消耗通常可能远低于 1MB/s——当我们考虑驾驶辅助或自动驾驶软件时，所需的带宽范围为 100MB/s-1GB/s 或更高。
EDMS通信使用Iceoryx 。Iceoryx 使用真正的零拷贝、共享内存方法，允许将数据从发布者传输到订阅者，而无需中间件中的任何副本。这确保了数据传输具有恒定的延迟，无论有效负载的大小如何。在 EDMS中使用具有恒定开销的真正零拷贝通信具有许多有趣且重要的属性。特别是，通信的扩展性非常好，随着消息大小的增加，带宽也会增加——这是因为唯一的成本是固定的开销，因此无论消息大小如何，成本都是一样的！EDMS中间件包括通信管理服务器。这为中间件处理了两个关键任务；首先作为连接发布者/订阅者的代理，其次，作为共享内存管理器控制器段分配以支持零拷贝。值得注意的是，VRTE 还将 ARA::COM 连接到 Iceoryx，因此 EDMS/VRTE 支持 EDMS应用程序和 AUTOSAR 自适应应用程序之间的快速高效通信。最后，EDMS还支持将 Iceoryx 绑定到 ROS，称为 ROS 网关。用户可以在定义 ROS 和 Iceoryx 之间的绑定的网关中定义对象（在任一方向，因此到或从 Iceoryx）。当 ROS 运行时处于活动状态时，根据网关对象的配置，传入的 ROS 消息将传入/传出 Iceoryx。
日志记录对于 AD/ADAS 开发非常重要——这同样适用于开发阶段和现场。
EDMS提供了一个数据记录库，它采用涵盖数据测量和记录的 “整体 “记录方法。为了启用取证分析，EDMS日志记录支持无干扰、确定性执行和可靠的数据传输。EDMS Logging 涵盖了多种信息，超越了传统的日志框架： ·基于文本的日志消息，附带消息参数和严重性（致命、错误、警告、信息……），·附加跟踪上下文（数据流、执行顺序……）的跟踪消息，·附加时间上下文（时间点，跨度标识符，...）的分析消息，·具有超高带宽（>1GB/秒）能力的标记有效负载消息（数据测量系统）“整体“日志记录方法要求所有这些类型的数据都可以在一个共同的逻辑时间轴中使用，以用于取证分析目的。这使开发人员能够使用特殊的回放和（图形）分析工具重现和跟踪系统行为。EDMS工具不仅仅是设计和部署， EDMS产品的很大一部分是重新计算和模拟支持——关闭 AD 开发周期的外观。TaPe （Trace Player）通过重新计算活动内一组可运行对象的历史执行来启用验证，并在试驾或实验室设置期间记录数据。可运行程序可以在开发人员机器或嵌入式目标上的重新计算中执行。支持使用调试器（例如gdb ）调试单个可运行对象的功能代码。TaPe允许通过快速验证加速 AD 开发周期——例如，当现场记录的执行可以带回实验室并逐步详细分析 SW 响应时，调试会变得更加高效。EDMS Open Loop ( DoL ) Player 允许通过将记录或模拟数据输入可运行、（多个）活动、ECU 或完整的 AD 系统来进行验证和验证。它可以在开发人员 PC、嵌入式目标或云端执行。EDMS DoLPlayer支持虚拟发布和新开发代码的轻松确定性执行，从可运行级别到完整的 AD 系统，用于调试和回归测试。EDMS DoLPlayer验证也可以集成到 CI/CD 系统中以提供快速验证。
除了数据记录，EDMS Flow Tracing库还可以记录系统中的所有可运行和活动执行——包括执行之间交换的消息的元信息。记录工具代码生成过程中的可运行对象和活动（因此由 EDMS工具支持）。 Flow Tracing 库为代码生成提供了必要的代码模板，并提供了一个库来处理执行期间记录数据的聚合和发布。Flow Tracing 数据用于 EDMS工具Robolyzer应用程序中的分析，以及用于TaPe中的重新计算和确定性开环 ( DoL ) 播放器。对于高效记录，数据采集是在没有转换为通用数据表示的开销的情况下完成的。这意味着直接捕获原始内存内容，在某些情况下甚至在嵌入式目标上使用零拷贝机制（例如通过使用 DMA）。通过这样做，数据布局正是目标上使用的内存布局，所有填充和数据大小都由目标 ABI 产生。由于只传输不透明的二进制数据块，因此目标上不会发生数据的成员序列化，也不需要复杂的传输协议。使用这种写入优化的方法，“序列化”负载完全转移到数据摄取过程（因此称为延迟延迟方法）。Serialize 库（即libserialize ）用于理解特定源 ABI 并将它们翻译（即反序列化）为 ABI 和处理系统的表示。之后，数据位于内存中的本地消费者布局中，并且可以进一步处理，就好像它是在消费机器上本地生成的一样。记录数据后，现在需要对其进行分析——为此，EDMS提供了Robolyzer。Robolyzer使开发人员和架构师能够分析自动驾驶应用程序的多 ECU 系统中的执行行为和数据流。该应用程序既可以在开发人员机器上使用来分析本地数据，也可以部署到数据存储和处理后端以连续 分析来自试驾的大数据集。基于 Web 的用户界面显示统计数据，例如执行时间和激活间隔，以提供完整系统行为的概览。为了评估软件组件的演变，可以随时间比较多个测量。Robolyzer提供甘特图可视化，提供对记录行为的详细调查到单个执行的级别和执行之间的数据流。正如我们之前在谈论工具时所看到的，EDMS支持通过TaPe播放器进行重新计算。回想一下， TaPe是一种轻量级重放解决方案，专注于取证重放，用于调试各个Runnable的功能行为，而不考虑 EDMS中间件以及初始化完整系统或时序模拟的需要。 Robolyzer和TaPe集成在一起，允许在开发人员机器或嵌入式目标上方便地选择和重新计算执行（ TaPe也可以通过交互式命令行界面单独使用）。EDMS（汽车操作系统）是一个 EDMS SDK，用于开发和运行 ADAS/AD 应用程序，包括基于 µP/POSIX 的平台和开发工具的运行时。它使软件工程师能够开发在安全性、性能、效率、可维护性和可用性方面具有最高标准的AD应用程序。这些目标将通过协调所谓的“AD 开发周期”来实现，该周期允许迭代和数据驱动的开发。EDMS SDK 为该 AD 周期中的不同开发步骤提供了贡献，完全或部分参见虚线。完整的 AD 周期可以通过其他博世产品进行补充：设计和开发：对于此步骤，EDMS提供了架构建模语言 (YAAA) 和图形架构可视化 YAAA-Vis。部署：代码生成 (YAAAC)，用于将 ADAS/AD 应用程序绑定到运行时。编译：使用 EDMS cmake 参考实现从所有自动生成和手动提供的源创建可执行文件。可以根据项目需要进行扩展。驱动：在此步骤中，EDMS提供 Carma 运行时以及在车辆或其他物理目标环境中执行的 ADAS/AD 应用程序。测量：提供对正在运行的软件的测量（和校准）访问。 该步骤可以由相应的数据采集系统补充。记录：保存在车辆或其他物理目标中运行软件时测量的数据，以便立即或稍后分析。数据链接：此步骤包含博世产品，用于存储数据以进行联合分析。验证、验证、重播、重新计算、模拟、分析：对于此步骤，EDMS提供了两个元素：用于取证的 TaPe。DoL 用于FreeCompute和Credible ReCompute。这可以通过其他博世产品进行扩展，以实现进一步的模拟用例，例如 HoL、SiL、SoL。
