usstmiracle的博客

AUTOSAR R24-11版本较R21-11实现了全面升级，重点包括：架构方面强化AP平台稳定性（线程安全/错误回滚机制），优化机器配置（M1/M2分层设计），深化CP+AP一体化；功能模块增强通信协议栈（支持IPv6/TSN/VDP）、诊断（远程SOVD）及安全机制（防火墙/后量子加密）；开发方法改进API稳定性与工具链支持（RHVIOS平台）。该版本标志着AP平台进入量产稳定阶段，为集中式电子架构和智能驾驶提供了更完善的底层支撑，特别是通过时间敏感网络和跨域协同能力满足高安全、高实时需求场景。升级需关

保密性（Confidentiality）：两个人发送的消息没有被第三者窃听。完整性（Intergrity）：两个人之间发送的消息没有被第三者篡改。身份认证（Authentication）：你接到了一个电话，对方说他是警察，他真的是警察吗？

可以把汽车的软件系统想象成搭积木，而清单（Manifest）就是不同阶段的说明书用什么积木（软件组件）怎么拼装（配置规则）积木之间如何沟通（通信方式）需要什么底座（运行环境）每种清单负责不同环节，避免“一把抓”的混乱，确保软件从设计到运行都清晰可控。清单（Manifest）就是汽车软件的“分工说明书”，不同阶段用不同的清单，确保从设计到运行的每一步都有人管、不出错。

这些协议和特性的支持使得 Adaptive Platform 能够满足高性能、高灵活性和高安全性的需求，为未来的智能汽车和自动驾驶系统奠定了坚实的基础。这一变化允许相同的需求在自适应平台和经典平台之间重复使用，从而提升了系统的灵活性和可维护性，最终实现了更高的模块化结构。稳定的API不仅能提高互操作性，还能在不同AUTOSAR版本及供应商之间实现更高的兼容性，这对OEM、一级供应商和工具供应商尤为重要，因为它们需要在可预测的环境中进行工作，从而优化开发周期。

AUTOSAR 通过其标准解决了汽车软件开发中的广泛用例。这些用例有不同的需求，并导致不同的技术解决方案。AUTOSAR 标准是一组一致的 AUTOSAR 交付物，它们在同一时间发布。AUTOSAR 交付物可以包括但不限于以下类型：- 文本解释- 文本规范- 测试规范- 源代码- 其他正式或半正式的文本格式（如 ARXML、UML 模型、XML 模式）AUTOSAR 提供以下标准：| 标准 | 缩写 |

它支持定义默认值和灵活的多重性，满足复杂场景需求。稳定的API不仅能提高互操作性，还能在不同AUTOSAR版本及供应商之间实现更高的兼容性，这对OEM、一级供应商和工具供应商尤为重要，因为它们需要在可预测的环境中进行工作，从而优化开发周期。在开发AUTOSAR元模型以生成XML模式时，应遵循一系列规则，这不仅促进元模型与模型之间的转化，还确保生成的XML模式具备高度的可用性和可靠性。新引入的协议和扩展不仅优化了DDS的应用架构，还为未来可能的新平台提供了良好的基础，确保了在多种环境下的可靠性与功能完整性。

自适应平台提供了卓越的连接性，能够与车内的经典平台无缝交互。在每次发布时，AUTOSAR的合作伙伴都会引入新的概念或扩展现有的概念，以不断增强和完善框架的功能与应用。通过这些新增和扩展的概念，AUTOSAR框架不仅为汽车行业提供了强有力的规范支持，还推动了技术的持续进步与创新，为未来智能汽车的发展奠定了坚实基础。经典平台和自适应平台：为这两种平台制定了详细的规范，确保它们在开发和实现方面的兼容性和互操作性。AUTOSAR框架交付的内容涵盖了多个重要方面，旨在为经典平台和自适应平台提供规范和基础部分的指导。

它通过提供加密、身份验证和数据完整性等功能，确保在IP网络中的数据包传输安全。IPsec可在网络层操作，适用于多种类型的网络架构，并广泛应用于虚拟私人网络（VPN）、安全通信、电子邮件加密等场景。1. 数据加密：IPsec使用加密算法（如AES、3DES等）对传输的数据进行加密，从而防止未经授权的访问和数据泄露。保护数据中心通信：在数据中心之间、安全的云连接、企业网络间的通信等场景，IPsec提供了一种安全的传输方法。：负责建立和管理安全关联（SA），即为IPsec连接的安全参数。

该规范的“所有功能集群的一般要求”章节应被视为入侵检测系统管理器实施的附加和必要规范。预计应用程序在ara::core::Initialize之前或ara::core::Deinitialize之后不会调用任何IdsM的API。在配置的时间间隔内发生的所有给定类型的SEv将被聚合为一个SEv，并附加一个额外的计数器信息，指示事件在时间间隔内发生的次数。90022]定义了ara::core::Initialize和ara::core::Deinitialize的一般行为。表5.2提供了所需接口的完整列表。

对于雷达、激光雷达或摄像头等每种传感器类型，ISO标准除了规定的信号外，还将包含大量可选的传感器数据或信号，例如，对象的分类可能是可选的。为了降低开发成本，特别是在功能安全方面，需要在设计时固定可选项，因此得到的逻辑传感器接口需要在设计期间固定，即指定的传感器信号在系统运行时不能突然从传感器的接口中消失，以便数据融合系统可以依赖这些指定信号的存在。语义接口的标准化正在进行中，如ISO 23150[1]所述，即ISO定义了哪些传感器数据或信号是必需或可选的，以及它们是如何定义的，例如，在坐标系和单位方面。

AUTOSAR NM基于分布式网络管理策略，这意味着每个网络节点都根据在通信系统内接收和/或传输的NM消息独立执行活动。AUTOSAR NM算法基于周期性的NM消息，这些消息通过多播消息被集群中的所有节点接收。接收到NM消息表明发送节点希望保持NM集群的唤醒状态。如果任何节点准备进入睡眠模式，它会停止发送NM消息，但只要接收到其他节点的NM消息，它就会推迟进入睡眠模式。最后，如果由于不再接收到NM消息而导致专用计时器过期，每个节点都会进入睡眠模式。

传统的ECU主要实现替代或增强电机系统的功能。这些深度嵌入式ECU的软件根据输入信号和连接到车辆网络的其他ECU的信息控制电输出信号。大部分控制软件是为目标车辆设计和实现的，并且在车辆寿命期间不会显著改变。新的车辆功能，如高度自动驾驶，将引入高度复杂和计算资源需求的软件到车辆中，并必须满足严格的完整性和安全要求。这样的软件实现了诸如环境感知和行为规划等功能，并将车辆集成到外部后端和基础设施系统中。由于外部系统的演变或功能的改进，车辆中的软件需要在车辆的生命周期中进行更新。AUTOSAR。

这种设计既满足了车内系统高实时、高可靠的需求，又通过标准化接口打通了车辆与数字生态的连接，为智能汽车向「软件定义」转型提供了基础设施级支撑。（通过 DDS 聚合数据） → VISS over WebSocket（实时上传至云端） → 云端 AI 模型决策 → 控制指令通过 VISS 下发 →。Adaptive AUTOSAR 平台中的通信管理中枢，负责协调车内不同软件组件（ECU、传感器、执行器等）之间的数据交换。维护的标准化协议，用于车辆与外部应用（如云端服务、移动端 App）的数据交互。

汽车API是一个标准化的接口，旨在实现跨车辆类型和制造商的统一数据访问，推动连接车辆生态系统的创新和发展。汽车API旨在创建一个标准化的接口，允许从车载和车外应用程序读取和写入车辆数据，同时保持数据和服务在车辆内部网络中的项目和OEM特定定义。汽车API是一个接口，它允许与车辆进行数据驱动的通信，并通过标准化接口安全地访问特定车辆数据，实现跨车辆类型和制造商的统一性。选择车辆信号规范（VSS）作为共同的车辆数据模型，以结构化方式描述个别信号，并提供标准化信号目录，作为汽车API的共同基础。

由于SOVD是一个相对较新的标准，本节旨在简要总结引入新标准的动机以及标准的简短技术概述。本节将以通用协议级别进行讨论，因此不专注于AUTOSAR的具体实现。

汽车API是一个接口，允许与车辆进行数据驱动的通信。它定义了其他系统如何通过标准化接口安全地访问特定车辆数据，而不依赖于车载表示，从而实现跨车辆类型和制造商的统一性。使这种通信成为可能的功能集群是汽车API网关（Automotive API Gateway）。它代表了自适应平台所需的所有功能，将作为新的功能集群引入自适应平台中的车辆服务功能集群组。下文的词汇表包括与汽车API解释相关的缩略语和缩写。提供汽车API的功能集群，可以将VISS客户端连接到车辆内部数据。：参见[6]中的第4.3.1条款。

本文件包含了关于AUTOSAR 自适应平台上的清单（Manifest）的规范说明。第1.1节建模方法描述了总体的建模方法。第1.2节服务的定义中对服务这一术语进行了解释。在本规范中，清单一词指的是配置内容的正式规范。详细描述请见第2节清单定义的总体图景。请注意，本文件的内容不仅限于名称，还扩展到了开发AUTOSAR自适应平台软件所需的设计元素。设计相关的建模主要关注在AUTOSAR自适应平台上开发应用软件以及应用与诊断之间的连接，详见第3节应用设计和第4节诊断设计。第5节。

在自适应AUTOSAR（Adaptive AUTOSAR）的更新和配置管理（UCM）模块中，是一个更高层次的抽象，代表了一组相关的功能和组件，而。这些元素共同定义了软件的功能、行为和更新过程。是这些功能和组件的具体实现。而Software Package。的更新和配置是通过对其中的。至于它们各自包含的元素，

工具链：Rust 提供了一套完善的工具链，如 rustup、cargo、rustdoc、rustfmt 等，可以方便地安装、编译、测试、文档、格式化 Rust 代码，而 C++ 的工具链较为分散，需要依赖不同的编译器、构建系统、文档工具等。(8) 学习心得：rust 就是 c 语言的升华版_rust是用什么写的_许野平的博客-优快云博客. https://blog.youkuaiyun.com/quicmous/article/details/113930050.后续有没有可能缩小?Rust 语言的优势在哪里？

本章必须定义在本地范围内的缩写和缩略语，这些缩写和缩略语不包含在 AUTOSAR 词汇表1中。在本文档中，并行处理技术的含义是宽泛定义的。这是有意为之，希望提供并行和相关处理（参见分布式、并发和并行）的设计原则。因此，本文档中的“并行处理技术”一词，涵盖了硬件和软件。在硬件方面，多核、众核、DFP（数据流处理器）、GPU（图形处理单元）、FPGA（现场可编程门阵列）或类似的；

我们有300多个模块库，涉及到各个领域的，扭矩的，燃烧的，通用模块库等，那些通用模块库基本上都适用于各个模块的开发。IO抽象模块这块代码和接口也是实现了自动化生成，包括.c文件，因为对于有些项目来说，这个接口有几百个，我们现在正在开发的中央控制系统确实它的接口就有几百个，如果人为做这项工作的话，你要花很长的时间，而且不能保证人工出错的概率，这块我们也是通过自动化脚本来做的。我们在真正做项目开发的时候看它的代码，再同步去看标准，再去看代码看配置背后所蕴含的含义，从工程中去了解标准的含义。

本规范描述了适用于 AUTOSAR 自适应平台的功能群 RAW 数据流的功能、API 和配置。在某些情况下，应用软件需要能够处理通过通信通道发送的原始二进制数据流。在原始二进制数据流中，数据没有类型，并且被处理为连续的字节序列。因此，不需要对数据进行序列化。该功能群规定了一种接口，以支持原始二进制数据流的处理。该接口是静态定义的，独立于底层网络协议。然而，目前原始数据流接口的建模仅支持 TCP/IP 套接字作为传输层。应支持单播和多播套接字连接。套接字可以使用 TCP 或 UDP 作为传输协议。

AUTOSAR有助于节省成本，供应商公司可以专注于一条解决方案路径，因为他们不必遵循不同的方向，OEM可以在平台之间交换软件解决方案，由于共享开发而降低成本，中间件和接口标准化，由于供应商的高度竞争而降低可负担的堆栈成本和工具链，以及更容易的认证。我们对新合作伙伴的开放，对第三方合作的开放，以及我们在形成强大的工业SDV生态系统方面的合作努力，将确保AUTOSAR作为智能移动的标准化软件框架和开放式E/E系统架构的作用。只有在这些问题的事实基础上，您才有机会在没有AUTOSAR的情况下构建您的软件框架。

本规范描述了 AUTOSAR 自适应诊断管理 (DM) 的功能、API 和配置。DM 是一个符合 ISO 14229-1[1] 的 UDS 诊断实现，也是一个符合 ASAM SOVD v1.0.0 [2] 的 SOVD 实现，用于 Autosar 自适应平台。自 R19-03 版本起，引入了一个 C++ 接口，作为诊断的接口，用于替代之前基于 ara::com 的服务接口。AUTOSAR 诊断提取模板 (DEXT) [3] 是 DM 的配置输入。AUTOSAR 自适应平台可以通过添加新的软件包来进行扩展，而

主要有两方面，一者，AUTOSAR原文规范，都是纯英文描述，每部分内容动辄几十页，一不小心几百页，要快速筛选我们关注的信息，看懂个中奥秘，没有一定的英语阅读功底，相信我们的学习会束手束脚，久而久之，你可能就放弃学习了。要知道单片机，外设芯片，供电芯片，计时芯片，IO驱动，PWM驱动，复杂驱动，CAN通讯芯片，寄存器，MSC通讯，SPI通讯，DMA，看门狗，操作系统。所以，持续学习的习惯要养成，还要保持。是的，我们是汽车行业的“我辈中人”，我们要迎难而上，“躬身入局”，承担起这份担当，擎起名族复兴的大旗。

自适应AUTOSAR服务是一种将应用程序分解为不同的功能单元（叫做服务）的组件模型。这些服务通过明确的接口和契约相互连接，实现协作和通信。接口是以中立的方式定义的，不依赖于服务实现的硬件平台、操作系统和编程语言。这使得在各种系统上构建的服务可以以一种统一和通用的方式互动。

状态管理负责运行状态管理的所有方面，包括处理传入事件、确定这些事件/请求的优先级以及设置相应的内部状态。状态管理的内部逻辑可以转换“软重置”，以请求建模过程（在与请求的诊断地址相关的功能组内）执行内部功能，而无需终止和重新启动它们。状态管理可以根据功能组状态影响这些字段，反之亦然，可以根据网络管理的NetworkHandle字段的值将功能组设置为定义的状态。在收到状态更改请求后，执行管理终止不再需要的建模流程，然后在向状态管理确认状态更改之前，在新的功能组状态下启动活动的建模流程。

AP AUTOSAR是AUTOSAR（汽车开放系统架构）的最新版本之一，它是一种面向服务的软件平台，旨在满足未来汽车电子系统的需求，特别是高性能计算、高带宽通信、软件无线更新（OTA）等方面。12提高软件的可重用性、可扩展性、可维护性和可移植性，降低软件开发和集成的成本和复杂度。支持多种硬件平台和通信协议，适应不同的计算需求和场景，例如自动驾驶、车联网、智能出行等。支持运行时的软件配置和更新，使汽车能够适应外部环境和用户需求的变化，提高汽车的智能化和个性化水平。

如果你不知道从哪份文档开始阅读，建议可以从这份开始 AUTOSAR_EXP_PlatformDesign.pdf。目前很多关于 Adaptive AUTOSAR 的文章都是官方文档的简化翻译，不如直接看官方文档更全面深入。软件规范， 详细、深入，一开始可以先跳过，Adaptive AUTOSAR 的实现方/供应商的重要参考资料。文档下载列表中带有 GENERAL 的为 High-level 的一般性文档，应该优先阅读。示例代码的设计文档，帮助更好地理解 FC 模块。解释说明性的文档，优先阅读。

Methodology方法论Adaptive AUTOSAR Methodology自适应AUTOSAR方法描述了构建自适应AUTOSAR系统所需的主要活动用例、任务、工作成果/活动与工作成果之间的关系不是什么？不允许其他步骤，具体描述不是一个规定性的顺序描述了一个一般的顺序，但允许迭代和旁侧步骤。首先定义SWC，就是一个功能集合，一个功能可能需要多个SWC来实现。所以需要为某一个功能分配多个SWC其实SWC是什么？其实就是可执行程序，你的代码文件...

本文图片来源 博世ETAS AP AUTOSAR ，如有侵权，请留言联系作者删除，谢谢。

1 AUTOSAR到底是什么？AUTOSAR也是一个中间件：操作系统，中间件，应用软件-各司其职分工不同。中间件的在于统一标准、分散实现、集中配置。：标准上合作，实现上竞争。

本章主要讲述了自适应AUTOSAR体系结构，提到AP我们常常会有这些的疑问，什么是“面向服务的体系结构”？ 构成自适应平台的“模块”是什么？ 自适应应用程序如何与平台交互的？我们看到了新的AUTOSAR平台对高性能计算（HPC High Power Computing）、高带宽通信、大数据、异构ECU。好的应用程序设计有两个公认的原则：松耦合、强内聚。为什么这些“好”的设计原则？把不必要的细节中抽象出来并隐藏起来、提高思考设计的能力、把问题分成几个可管理的单元。经典平台采用基于组...

Adaptive AUTOSAR是一种新的汽车软件框架，旨在满足现代汽车行业中不断增长的技术需求。随着汽车变得越来越智能，对处理器的性能要求也在不断增长。Adaptive AUTOSAR旨在通过提供高性能计算和通信机制以及灵活的软件配置来满足这些需求，为车联网和远程诊断、自动驾驶汽车铺平道路。Adaptive AUTOSAR为新应用程序（如高度自动驾驶、V2X、OTA软件更新或车辆作为物联网的一部分）提供了支持，这些应用程序对下一代ECU的软件平台提出了全新的要求。

需要创建一个新的模式声明组（Mode Declaration Group），并将它和功能组集（Function Group Set）关联。功能组集和软件集群（Software Cluster）关联。·在MachineFG中添加Machine的四种状态：Off、Startup、Restart、shutdown，并将MachineFG设置初始状态为OFF。下表展示了功能组和状态的关系：功能组是一种逻辑分组，用于将具有相同或相似功能的进程聚合在一起。

Adaptive AUTOSAR 简介 Adaptive平台: 一种新的 AUTOSAR 在过去的30-40年中，在汽车环境中使用软件——无论是以功能的数量还是复杂性来衡量——已经从简单的发动机管理系统发展到在车辆平台中普及。AUTOSAR Classic 平台是为了应对汽车软件日益复杂的需求而开发的。该平台的特点是支持硬实时性、高安全性、低资源拥有属性 ECUs，因此非常适合于传统的汽车用例。Classic 平台仍然是功能性汽车 ECUs 的明显选择，这些 ECUs 直接连接到传感器和执.

本系列学习笔记基于 AUTOSAR Adaptive Platform 官方文档 R20-11 版本。本文从AUTOSAR_EXP_PlatformDesign.pdf开始，一边学习，一边顺带着翻译一下。尽力而为，不保证精确。你若愿意，也可以当作 AUTOSAR Adaptive Platform （AP）中文版来阅读 ????1 介绍1.1 内容本规范（AUTOSAR_EXP_PlatformDesign.pdf）描述 AP 设计。目的在于提供概述，但不涉及所有的设计细节。为AP 用户和AP

(6) Adaptive Autosar 整体架构理解_AgingMoon的博客-优快云博客. https://blog.youkuaiyun.com/AgingMoon/article/details/102813280.(7) Adaptive Autosar 整体架构理解 - 优快云博客. https://blog.youkuaiyun.com/usstmiracle/article/details/108639362.基础包括了操作系统接口、执行管理、网络管理、识别访问管理、加密、更新和配置管理等功能¹。

这些接口的提供是为了通过澄清功能集群之间的交互来促进AP规范的开发，并且它们还可以为AP规范的用户提供更好的架构视图。一般来说，功能集群（Functional Clusters）可以通过AP实现特定的方式相互交互，因为它们不受ARA接口的约束，例如PSE51，它限制了IPC的使用。功能集群之间的一种典型交互模型是使用功能集群的受保护接口，以提供实现功能集群特殊功能所需的特权访问。IFC的目的是通过澄清功能集群之间的交互来促进AP规范的开发，并为AP规范的用户提供更好的架构视图。

在AUTOSAR自适应平台的诊断部署中，特定的诊断配置，尤其是诊断地址，只能分配给清单中的根软件集群。：清单代表创建的AUTOSAR模型描述的一部分，用于支持AUTOSAR自适应平台产品的配置，并可能与包含适用于清单的可执行代码的其他工件（如二进制文件）结合上传到AUTOSAR自适应平台产品。需要生成一个头文件，该文件定义了一个具有唯一名称的类，该类实现了相应的插件（例如，生成的类的类名和命名空间是从清单中插件的短名称路径派生的）。相应的可执行文件包含了运行在AUTOSAR自适应平台上的机器的可执行代码。