AUTOSAR R24-11更新重点简介 (R24-11新标准发布)

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

Classic AUTOSAR R22-11规范中新增了哪些概念。

本文介绍了Classic AUTOSAR与Adaptive AUTOSAR规范版本之间的关系。

R24-11是 Classic Platform 的最新小版本发布，虽然不是大版本，但这次的新增特性和规范变动，足以让工程师们重新审视通信、充电、以及底层驱动模块配置的方式。TSN（Time-Sensitive Networking）用于确保以太网通信的实时性，在高级驾驶辅助系统（ADAS）、域控制器之间通信中越来越重要。工具链（如DaVinci Configurator、ISOLAR）升级支持 R24-11 后，可探索 I2C、TSN 配置的新能力。

文章主要探讨了AUTOSAR Classic Platform R24-11版本发布后，不同岗位的工程师应如何根据自身职责关注新版本的变化和更新。文章按工程师类型分类，详细列出了BSW配置工程师、SWC开发工程师、系统架构师、测试与虚拟验证工程师以及集成与平台工程师在新版本中需要重点关注的内容和必须更新的配置。

在AUTOSAR R24版本中，经典平台针对多个规范进行更新，提升功能并增强与自适应平台的集成能力。通信协议增强IPSec协议支持：引入基于IETF标准的IPSec协议，可在ECU之间实现身份验证或加密通信，于IP网络层透明运行，无需修改应用程序，相比R23显著提升网络安全性。信号服务转换（Signal Service Translation）：增强经典平台与自适应平台的通信能力，支持信号到服务的双向转换，在支持端到端安全性方面表现更优，扩展了多种E2E配置的兼容性（对比R23）。多核支持。

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

2023年和2024年的修改体现了对API一致性和用户友好性的关注，同时也加强了系统的安全性和可靠性。通过具体示例可以看出，这些变化确实带来了实际的好处，包括但不限于提升代码质量、简化错误处理以及增强安全性。这些修订反映了Crypto Interface规范随着时间和需求的变化而不断演进的过程。每一次更新都旨在解决特定问题或引入新特性，从而确保该规范能够更好地满足汽车行业对于安全性、可靠性和性能的要求。

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

AUTOSAR中国日，针对R24-11版AUTOSAR协议的核心功能变更和优化

AUTOSAR AP 中的 EM-PHM 集成构建了**先进的汽车软件健康管理框架**，在满足复杂功能需求的同时保障系统安全性与可靠性。它成功融合了进程管理、健康监控与自动恢复机制，适用于 ADAS、高级自动驾驶与车联网服务等高阶汽车应用。

Specification of Log and Trace AUTOSAR AP R24-11》是 AUTOSAR 自适应平台中Log and Trace（日志与追踪）功能集群的核心规范，定义了自适应应用向控制台、文件系统、网络（如 DLT 协议）等目标输出日志的接口与逻辑，支持非建模消息（Non-modeled Messages）和建模消息（Modeled Messages）两种日志类型，通过ara::log命名空间提供LoggerLogStream等核心类及LogLogDebug。

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

主持人：今天我们跟着文档，把自适应平台的背景、架构、核心功能都过了一遍。最后再总结一下，这份文档的核心价值是什么？对车载软件行业有什么影响？嘉宾：这份文档的核心价值，是为自适应平台提供了一套 “标准化的设计规范”。以前，不同车企、不同供应商的车载软件架构五花八门，兼容性差，开发成本高；而 AUTOSAR 通过这份文档，定义了统一的架构、功能集群、接口 —— 这样一来，供应商开发的软件可以适配不同车企的平台，车企也不用重复造轮子，能快速整合各种功能。嘉宾：对行业来说，这会加速智能汽车的发展。

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

本文详细解析了AUTOSAR Adaptive Platform操作系统接口需求规范（R24-11版本），重点介绍了操作系统接口在标准化访问、资源管理、进程隔离和平台协作方面的核心作用。文档通过架构图展示了系统层次结构和需求分类体系，包括POSIX PSE51合规性、C++支持、进程响应机制等关键功能需求，以及资源预算配置、进程绑定等操作系统级需求。规范还强调了非功能性需求如调度观察机制，并提供了需求追溯关系和实现示例，为开发符合AUTOSAR标准的车载系统提供指导。

传输协议管理器负责在两个方向上调度UDS消息：从诊断客户端接收到的UDS请求被转发到相应的诊断服务器实例，由诊断服务器实例创建的UDS响应被调度到负责处理与诊断客户端连接的传输协议处理程序（UdsTransportProtocolHandler类）。每个诊断服务器都有自己的诊断地址（如0x8E1/0x8E7）和诊断服务，因此不同的诊断服务器可以使用相同的DID（诊断标识符），但代表不同的含义，从而避免冲突。作为功能集群，诊断管理包括一个与自适应应用程序链接的库和一个实现诊断管理活动方面的守护进程。

Specification of Crypto Interface AUTOSAR CP R24-11》文档旨在规定AUTOSAR经典平台（Classic Platform）中Crypto Interface (CRYIF)模块的功能、API以及配置。提供统一接口：为不同的加密硬件（HSM, SHE）和软件解决方案（SW-based CDD）提供一个统一的接口，使得上层服务层（如Crypto Service Manager [CSM]）可以基于映射方案访问多个底层内部和外部的加密硬件或软件。

主持人：在聊网关之前，我们得先明确 Automotive API 到底是什么。根据文档，它可不是一个简单的 “接口”，而是一套标准化的 “数据交互体系”。文档里提到，智能网联汽车的生命周期，依赖于远程诊断车辆、更新软件来保证行驶安全，同时车企还得给服务提供商、监管机构开放车辆数据，用户也希望像用手机 APP 控制家电一样操控车辆 —— 但之前 AUTOSAR 标准有个短板，就是没法安全地把 AUTOSAR 应用的数据和功能，开放给非 AUTOSAR 客户端，不管是车里面的安卓车机，还是车外面的云端服务器。