AP AUTOSAR
分享
扫一扫
文章平均质量分 87
我是一个基于 AP AUTOSAR 的博客专栏的作者，想与您分享一些关于这个平台的知识和经验。如果您对汽车软件开发感兴趣，或者想了解 AP AUTOSAR 的特点和优势，那么这个专栏是为您准备的。我将为您介绍 AP AUTOSAR 的历史、需求、架构、功能、方法和工具，以及一些实际的案例和技巧。
超级会员免费看
aFakeProgramer
Adaptive AUTOSAR技术专家，2024 AUTOSAR中国官方TOP培训讲师。深耕汽车电子软件领域，精通Adaptive AUTOSAR架构及RTA-VRTE工具链，实战经验丰富。深入掌握SOME/IP、IPC、DDS、DoIP、UDS、TSN等通信协议，熟悉SOA设计、V2X与车载网络安全。熟练使用C++和Python进行系统开发与集成，具备MQTT、加密机制等智能网联技术应用能力。致力于将复杂技术通俗化，推动汽车软件架构向服务化、智能化发展。持续分享Adaptive AUTOSAR、DDS、TSN及车载以太网等前沿技术实践，助力工程师快速掌握下一代汽车电子开发核心技能。
展开
专栏收录文章
- 默认排序
- 最新发布
- 最早发布
- 最多阅读
- 最少阅读
-
AUTOSAR AP R25-11 机器配置参数规范 （AUTOSAR_AP_MOD_MachineConfigurationParameters.arxml）
文件本质是 AUTOSAR AP R25-11 对「车载自适应平台机器级配置参数」的元模型定义，回答了自适应平台的持久化、软件更新功能该如何标准化配置这一核心问题，是车载 ECU / 整车级自适应软件配置的官方规范模板，所有参数、容器、引用关系均遵循 AUTOSAR R25-11 的元模型规则（如AR-PACKAGE等标签）。这份文件是 AUTOSAR AP R25-11 版本对「数据持久化 + 软件更新管理」两大核心能力的配置元模型规范。原创 2025-12-11 09:42:57 · 31 阅读 · 0 评论 -
Adaptive AUTOSAR 工程中Machine、SoftwareCluster等元素之间的关系理解
本质：Adaptive AUTOSAR 中 “最高级别的逻辑功能容器”，是一组 “语义相关” 的 SWC 的集合，用于模块化管理功能域（比如 “智能驾驶软件集群”“座舱娱乐软件集群”）。工程作用隔离不同功能域（比如智能驾驶和座舱的 SWC 不会混在一个 SoftwareCluster 里），便于团队分工、版本管理（比如单独升级座舱集群，不影响驾驶集群）；是逻辑层与物理层 “映射的桥梁”—— 整个 SoftwareCluster 会被映射到某个 Machine 上（不会单个 SWC 直接映射硬件）。原创 2025-12-10 13:27:19 · 27 阅读 · 0 评论 -
rvbuild 脚本说明
【代码】rvbuild 脚本说明。原创 2025-12-08 16:36:22 · 32 阅读 · 0 评论 -
rvkill 脚本解释
【代码】rvkill 脚本解释。原创 2025-12-08 16:29:37 · 24 阅读 · 0 评论 -
如何在让QNX QEMU在VRTE start kit 上运行
选择刚刚拷贝出来的哪个文件，然后安装，安装出错，就把出错的哪个包去掉，不安装即可。把这个文件拷贝到windows PC的一个目录中。然后Next ->Finish。对OpenSSH进行更新。原创 2025-12-08 11:48:09 · 31 阅读 · 0 评论 -
adaptive AUTOSAR 在SoftwareCluster中配置category为PLATFORM_CORE或者PLATFORM 这是什么有什么差异？
是 Adaptive 系统的 “心脏”，承载核心平台服务，不可替代、不可停止，故障会导致系统崩溃；PLATFORM是 “心脏的辅助器官”，承载扩展平台服务，可灵活启停，故障仅影响局部功能。在实际配置中，需先定义确保系统核心运行，再通过PLATFORM扩展平台层能力，最终支撑应用层业务逻辑的运行。原创 2025-12-04 11:41:24 · 28 阅读 · 0 评论 -
Adaptive AUTOSAR中EM STM和PHM这3个守护进程需要配置各自的Function Cluster Affiliation，这是为什么？
核心目标具体体现架构归位让 EM/STM/PHM 对应到 Adaptive AUTOSAR 的顶层功能域，确保设计与实现一致故障隔离限制故障扩散，满足 ISO 26262 的故障域最小化要求资源可控基于 FC 分配 QoS 资源，保障核心进程的实时性权限可控基于 FC 做访问控制，符合 ISO/SAE 21434 的信息安全要求运维可控按 FC 部署 / 升级 / 排查，提升工程化效率合规可控实现全链路可追溯，满足车载安全法规要求。原创 2025-12-03 17:32:22 · 131 阅读 · 0 评论 -
security boot 和IDSM入侵检测有什么区别？
维度Security Boot（安全启动）IDSM（入侵检测与安全监控）核心定义启动阶段的固件 / 系统完整性与合法性验证机制，确保设备仅运行经授权的、未被篡改的软件镜像。运行时的入侵行为检测与安全状态监控机制，实时识别未授权访问、恶意攻击、异常行为等安全威胁。核心目标「防篡改、防植入」：阻止恶意固件 / 代码在设备启动时运行（如篡改 ECU 固件、植入恶意程序）。「早发现、早告警」：在系统运行过程中检测入侵行为（如 CAN 总线攻击、V2X 恶意通信、ECU 异常行为），并触发告警或响应。原创 2025-12-03 17:25:50 · 26 阅读 · 0 评论 -
Adaptive AUTOSAR watchdog 与 PHM 守护进程的关系
watchdog和PHM 守护进程watchdog提供底层、硬件级的运行连续性保障，是防止系统完全瘫痪的最后一道防线PHM 守护进程提供上层、应用级的健康状态监控，实现细粒度故障检测和恢复二者关系的精髓PHM 守护进程是系统的 "健康分析师"，而 watchdog 是 PHM 手中的 "终极急救工具"。它们共同构成了 Adaptive AUTOSAR 从 "监控 - 分析 - 响应 - 恢复" 的完整安全闭环，确保车载系统在复杂环境中持续可靠运行。原创 2025-12-03 17:24:00 · 28 阅读 · 0 评论 -
RTA-VRTE V3.10 Starter Kit rvbuild 命令使用说明
rvbuild是 RTA-VRTE Starter Kit 提供的项目构建与部署脚本，支持对指定项目进行编译构建、IP 配置补丁、目标设备部署等操作，适配 QEMU 仿真环境与多种外部硬件（如 R-CAR H3、Raspberry Pi4），兼容 Linux、QNX 操作系统及 x86_64、aarch64 硬件架构。项目编译构建与构建产物清理；跨系统（Linux/QNX）、跨架构（x86_64/aarch64）适配；目标设备 IP 地址补丁配置；原创 2025-11-20 16:41:43 · 44 阅读 · 0 评论 -
State Management 详细介绍（问答形式）
State Management 是 AUTOSAR Adaptive Platform 中负责管控系统整体运行状态的功能簇，核心职责包括处理外部事件、优先级排序请求、维护内部状态机，并通过与其他功能簇（如 Execution Management、Platform Health Management）交互，实现功能组状态切换、网络激活 / 停用、机器重启 / 关机及软件更新协调等关键操作，且其逻辑多为项目定制化，最终由系统集成商实现。原创 2025-11-18 10:23:36 · 38 阅读 · 0 评论 -
入侵检测系统管理器（IDSM）
在创建IdsM实例后，用户可在IDSM配置页面添加新的子元素，如IdsM速率限制引用条件和IdsM流量限制引用条件，以便更精确地配置IdsM过滤器引用。AUTOSAR定义了一种新的文件格式用于描述IDS属性，即Security Extract（SECXT）它是一个配置文件，用于指定由入侵检测系统管理器（IdsM）实例处理的安全事件（SEv）及其相关配置参数。IDSM（IdsM）的配置与集成涉及多个关键步骤和组件，包括安全提取的配置、报告模式的设置、IdsM模块实例化和过滤链的配置等。原创 2025-11-12 16:38:46 · 50 阅读 · 0 评论 -
一文读懂AUTOSAR E2E保护：车载通信的 “安全锁”，守护每一次数据传输
举个例子：如果接收端连续收到 3 个数据，计数器是 1→2→4（跳过了3），状态机就会从 “kInit” 变成 “kInvalid”，告诉应用 “这组数据有问题，别用”。为此，AUTOSAR 提供了7 种预设的 E2E Profile（配置文件），每种都有固定的 “保护头结构” 和 “验证规则”，无需重复开发。E2E 保护的核心价值的就是弥补这一短板：发送端给数据附加 “保护头”（含 CRC 校验值、计数器、Data ID 等关键信息），接收端通过验证 “保护头” 自主判断数据是否被篡改、丢失或重复。原创 2025-11-10 10:45:19 · 225 阅读 · 0 评论 -
一文搞懂 AUTOSAR 安全三剑客 ——TLS/DTLS、E2E 与 SecOC
其模块集成于 AUTOSAR BSW 层的 PduR（Protocol Data Unit Router，协议数据单元路由器），通过对称加密算法生成消息认证码（MAC），并附加新鲜度值（Freshness Value），确保报文的真实性与完整性。TLS/DTLS、SecOC 与 E2E 保护在车载通信安全中形成了 “通道 - 报文 - 应用” 的三层防护体系：TLS/DTLS 守护 IP 网络的传输机密与身份认证，SecOC 保障传统总线的报文真实性，E2E 保护聚焦应用数据的全程一致性。原创 2025-11-10 10:40:01 · 102 阅读 · 0 评论 -
PHM（AUTOSAR AP Platform Health Management）配置全步骤
PHM 通过定义被监控实体的检查点（Checkpoint），需明确检查点的唯一名称与 ID（数值型），是后续监控的核心依据。操作工具：ISOLAR-VRTE（HADL DSL 编辑器）或 ARXML 手动编写；核心约束检查点名称（）需全局唯一（字符串类型）；检查点 ID（）需非负且唯一（uint32_t 类型），与应用执行流中的关键节点对应（如 “任务开始”“任务结束”“周期心跳”）；示例配置// 定义PHM监督接口，含2个检查点（适用于Deadline监控：开始→结束）原创 2025-11-07 14:18:23 · 70 阅读 · 0 评论 -
AUTOSAR Adaptive Platform ——Platform Health Management (PHM)
PHM是 AUTOSAR Adaptive Platform 的，核心作用：监控Adaptive Application Instance（应用实例）的执行状态，推导Local Supervision Status（本地监控状态），并基于所有应用状态汇总出Global Platform Health Status（全局平台健康状态）。组成形式：库：提供ara::phm命名空间的 C++ API，支持应用上报 Checkpoint、获取监控状态；rb-phmd。原创 2025-11-07 14:13:56 · 175 阅读 · 0 评论 -
车载安全小茶馆：聊聊 AUTOSAR 里的 “安全管家” IDSM
主持人：今天听下来，IDSM 其实就是车载安全的 “中间枢纽”—— 收事件、处理、转发，还能自己报警。最后再给听众划个重点呗？afakeProgramer：三个核心重点：第一，IDSM 是 AUTOSAR Adaptive 的 “功能集群”，核心管 SEv 的全流程；第二，配置时重点关注 TMin 和 API 调用时机，不然容易出问题；第三，它依赖两个 “外部帮手”——SEM 存事件，STM（状态管理器）拿系统状态，配置时别漏了这些依赖。主持人：太实用了！原创 2025-11-07 13:36:38 · 148 阅读 · 0 评论 -
Intrusion Detection System Manager (IdsM)
是 AUTOSAR Adaptive Platform 的，核心作用是处理（由安全传感器上报的安全事件）。组成形式：包含提供 C++ API（ara::idsm命名空间）的库（供应用上报 SEv），以及支持 SEv 接收 / 存储 / 过滤 / 传输的运行时守护进程（daemon）。原创 2025-11-07 13:32:11 · 53 阅读 · 0 评论 -
网络管理（NM）
定位：AUTOSAR 自适应平台服务中的功能集群，专注于协调底层网络（物理 / 部分网络）在 “正常运行” 与 “总线睡眠” 模式间切换。核心特性基于去中心化 UdpNm 算法，每个节点独立根据 UdpNm 消息执行操作，无需中心节点；独立于通信网络绑定，支持以太网等多种网络类型；不直接面向普通自适应应用，仅接收来自状态管理（STM）的网络请求。原创 2025-11-06 16:51:26 · 99 阅读 · 0 评论 -
状态管理配置与 STM 功能组状态切换机制
需配置两类状态机，通过。原创 2025-11-06 16:24:05 · 44 阅读 · 0 评论 -
状态管理（State Management）
在 Machine（如 FlexibleSafety）下新建General：配置插件加载参数（如 loadDiagMonitorIf=true）、超时参数（actionListTimeout 默认 300 秒）；：定义 2 个 StateMachineDefinition（SM_CORE 为 Controller，SM_1 为 Agent）；：为每个状态机状态绑定 ActionItemList，定义功能组变更动作；：映射 TriggerOut_StateMachine 接口与状态机。原创 2025-11-06 16:19:53 · 109 阅读 · 0 评论 -
AUTOSAR——Tsync
归属：AUTOSAR自适应平台基础（Adaptive Platform Foundation）中的功能集群（Functional Cluster）。接口形式：通过 C++ API 提供服务，需链接 RTA-VRTE Starter Kit 中的librb-tsync.so 库，应用程序需与该库关联以调用同步功能。文档状态：当前版本文档不完整 / 可能存在错误，后续版本将补充完善。原创 2025-11-06 15:37:36 · 472 阅读 · 0 评论 -
ara::Core——Core Types 功能集群的优势与劣势分析
Core Types 的优势集中体现了车载嵌入式场景对安全性、可维护性、资源可控性符合 AUTOSAR AP 标准的域控制器、车载计算机等中高端硬件；功能安全等级较高的场景（如自动驾驶、动力系统）；多团队协作开发的大型项目（统一类型与错误处理规范）。资源极度受限的低端 MCU（如 8 位 / 16 位处理器）；无操作系统的极简嵌入式环境；追求极致开发效率的非安全场景（如座舱娱乐轻量应用）。原创 2025-11-06 14:34:31 · 45 阅读 · 0 评论 -
ara::core——Adaptive AUTOSAR
定义：Core Types 是 AUTOSAR Release AP18-10 引入的自适应平台基础功能集群，位于ara::core命名空间，提供自适应平台应用开发所需的基础数据类型、错误处理机制及资源管理工具。核心目标确保类型安全：基于 C++ 类型扩展，部分类型（如 ErrorCode）为 AUTOSAR 专属定义；统一错误处理：支持异常式（通过 ValueOrThrow () 转异常）与非异常式（通过 HasValue () 判断）两种流程；原创 2025-11-06 14:29:49 · 154 阅读 · 0 评论 -
对称加密与非对称加密
就像是权威机构（CA）给“公钥”贴上的防伪标签，而你只要用这个机构的公开方法（CA公钥）验证一下标签真假，就能判断这个公钥是不是真的属于那个人。这样，即使中间人想冒充小红，他也拿不到 CA 的“私钥”去伪造签名，所以他的假公钥就会被识破。的公钥对数字签名进行解密得到发送方的数字摘要，然后用相同的哈希函数对原文进行哈希计算，得到一个新的消息摘要，最后将消息摘要与收到的消息摘要做比较来辨别对方身份的真伪。：和对称加密算法相比，非对称加密算法所需的算力较大，如果通信的信息量较大，会给处理芯片带来较大的负担。原创 2025-11-04 10:26:39 · 56 阅读 · 0 评论 -
SOME/IP的TLV 序列化机制详细介绍
SOME/IP（Scalable service-Oriented MiddlewarE over IP）中的 TLV（Type-Length-Value）序列化机制是实现跨 ECU 数据交换的关键。原创 2025-10-27 10:31:33 · 72 阅读 · 0 评论 -
AUTOSAR 中 Trusted Platform（可信平台）详解
支持从设备启动到应用运行的连续信任链，确保所有执行的代码均经过身份认证（确认来源合法）和完整性验证（确认未被篡改）的执行平台”。防篡改：阻止被修改的可执行文件、配置文件（如 Manifest）或共享对象运行，避免恶意攻击或硬件故障导致的代码异常；防未授权：仅允许经过认证的可信软件启动，拒绝未授权或来源不明的程序，保障车载系统（如域控制器、智能驾驶 ECU）的运行安全。原创 2025-10-21 14:09:14 · 159 阅读 · 0 评论 -
AUTOSAR E2E 保护中状态机的工作原理详解
AUTOSAR E2E 保护的状态机，本质是 “接收端的数据可信度管理系统”—— 通过 “多状态定义 + 动态切换规则 + 与单样本验证协同”，实现对数据从 “初始观察” 到 “稳定可用” 再到 “异常拦截” 的全生命周期判断。避免 “单次验证失误” 导致的误判（如偶尔 1 次 CRC 错不直接禁用数据），同时防止 “持续异常数据” 被误用（如连续错误超阈值则强制拦截），为车载安全相关数据（如控制信号、传感器数据）提供精准、可靠的信任判断依据。原创 2025-10-21 10:28:22 · 124 阅读 · 0 评论 -
Platform Health Management 与 EXM/STM 的集成实现方式
可执行文件命名：EXM 的元素名称必须为exm，不可自定义，确保 PHM 能识别目标监督进程。进程配置：需创建<Process>元素，名称固定为rb_exmd，且属性必须设为 “Execution Management”，同时将该进程添加到类别的 SoftwareCluster 中。关键参数：通过 Admin Data 配置（默认 0.4 秒），表示 EXM 周期性处理的最大间隔，也是 PHM 判断 EXM “存活” 的参考基准。SWC 原型与端口：STM 的需引用 SWC 类型，该 SWC 需配置。原创 2025-10-20 17:41:42 · 132 阅读 · 0 评论 -
AUTOSAR 自适应平台 如何保证时间同步的可靠性？出现故障怎么办？
TBR 的同步状态通过：初始状态，未完成首次同步，此时时间不可靠。kTimeOut：超过（配置超时时间）未接收主节点消息，同步中断（SWS_TS_00030、SWS_TS_00032）。：已与主节点成功同步，时间可用。：通过时间网关同步（非直接连接主节点），需关注网关可靠性。SWS_TimeSynchronization.pdf 通过 “校正保障精度、监控保障感知、安全保障真实、容错保障鲁棒、标准保障兼容” 的五层机制，构建了汽车分布式系统中时间同步的可靠性体系。原创 2025-09-26 17:39:40 · 275 阅读 · 0 评论 -
自适应平台（Adaptive Platform）标准——Specification of Time Synchronization
角色数量限制核心职责关键行为1 个 / 时间域作为全局时间源，向从节点分发时间- 网络就绪（链路 Up）后发送 Sync/Follow-Up 消息- 周期将时间戳持久化至 Persistency（配置 cyclicBackupInterval）- 支持通过 SetTime/UpdateTime 接口手动设置时间Time Slave多个 / 时间域接收主节点时间，校正本地时间。原创 2025-09-26 17:36:26 · 239 阅读 · 0 评论 -
AUTOSAR 状态管理（SWS_StateManagement.pdf）核心概念解析
主持人：各位听众朋友们好，欢迎来到本期技术播客！今天我们聚焦 AUTOSAR 自适应平台里的关键规范 ——《Specification of State Management》（文档 ID：908，版本 R24-11），也就是大家常说的 SWS_StateManagement.pdf。这篇文档里藏着汽车电子中 “状态控制” 的核心逻辑，不管是自动驾驶的功能启停，还是软件更新的稳定保障，都离不开它定义的规则。原创 2025-09-26 17:31:21 · 326 阅读 · 0 评论 -
自适应平台（Adaptive Platform）——Specification of State Management
状态机（StateMachine）** 机制确定内部状态、协调。原创 2025-09-26 17:28:26 · 119 阅读 · 0 评论 -
自适应平台（Adaptive Platform）标准 ——Specification of Sensor Interfaces
摄像头传感器（Camera Sensors）：提供图像相关数据，支持特征级、检测级、目标级接口激光雷达传感器（Lidar Sensors）：提供点云等数据，支持检测级、目标级接口雷达传感器（Radar Sensors）：提供距离、速度等数据，支持检测级、目标级接口超声波传感器（Ultrasonic Sensors）：提供近距离检测数据，支持特征级、检测级、目标级接口类型名称用途关键属性标识可选信号的存在类型：VECTOR<bool>；每个服务对应唯一能力向量表（见第 10 章）表示服务版本。原创 2025-09-26 17:23:26 · 146 阅读 · 0 评论 -
TSN（时间敏感网络，Time-Sensitive Networking）——可靠性保障类标准协议
TSN 的可靠性保障不是 “单一协议”，而是“链路层冗余（FRER）+ 传输层确认（URB）+ 网络层路径保护（SRP）” 的多层级协同体系 ，其核心价值是：在 “低延迟” 的基础上，通过 “并行发送、按需重传、路径预留” 三大机制，实现工业、车规等场景对 “数据 100% 可达” 的刚性需求，是以太网从 “办公互联” 走向 “工业 / 车规互联” 的关键技术支柱。原创 2025-09-22 10:03:28 · 459 阅读 · 0 评论 -
Adaptive AUTOSAR中TSN技术的深度解析
这些底层TSN协议（数据链路层）与Adaptive AUTOSAR通信栈（网络层以上）的结合，形成了强大的通信基础设施，支持从时间同步、确定性调度、高可靠传输到基础流量管控的全方位能力，为复杂应用提供高性能、高可靠的通信支持。其核心机制是报文复制与报文丢弃，即在发送端发送两份一样的报文，若在接收端同时收到，则丢弃一份，接收一份。通过将TSN（时间敏感网络）技术与Adaptive AUTOSAR通信栈相结合，可以实现从时间同步、确定性调度到高可靠传输的全面支持，为复杂的应用场景提供高性能和高可靠的通信保障。原创 2025-09-22 09:38:35 · 92 阅读 · 0 评论 -
VRTE编译命令-----rvbuild说明 (V3.10)
该命令实现了对项目的“清洁 + 静默 + 自动化 IP 配置 + 部署”一体化操作，专为在的 QEMU Linux 环境中快速部署发布者角色的应用而设计rvbuild [选项] < 项目 > [< 机器索引 >]原创 2025-09-08 16:37:12 · 148 阅读 · 0 评论 -
诊断服务器（Diagnostic Server）
实例化规则：按 “每 1 个 DiagnosticContributionSet 对应 1 个诊断服务器实例” 创建，1 个 SoftwareCluster 可关联 1 个或多个 DiagnosticContributionSet（但通常 1 对 1），多个实例共享 UDS/SOVD 传输层（如 DoIP 端口、SOVD HTTPS 端口），但资源完全隔离（SWS_DM_00420）；核心定位。原创 2025-09-03 17:15:21 · 356 阅读 · 0 评论 -
诊断通信管理DCM
合法性保障：通过多维度校验过滤无效请求，避免系统资源浪费；安全性防护：通过安全等级、认证、权限控制，防止未授权访问；有序性管控：通过会话机制、优先级调度，确保多客户端并发通信有序；兼容性支撑：生成标准化 UDS/SOVD 响应，确保不同客户端（诊断仪、车载 ECU）可解析。所有作用均需遵循 SWS_DM 系列要求（如 SWS_DM_00286 请求校验、SWS_DM_00390 请求分发、SWS_DM_01123 认证处理），确保 AUTOSAR 自适应平台诊断功能的兼容性与一致性。原创 2025-09-03 16:59:32 · 172 阅读 · 0 评论 -
聚焦诊断管理（DM）的传输层设计、诊断服务器实现、事件与通信管理、生命周期与报告五大核心模块
双传输层并行：UDS（DoIP / 自定义 TP）面向传统诊断，SOVD（HTTP/REST）面向服务化诊断，覆盖不同诊断场景；资源隔离：诊断服务器按 SoftwareCluster 实例化，会话、DTC、安全状态独立，避免跨实例干扰；规范性强：所有功能均绑定 SWS_DM 系列要求（如 SWS_DM_00329 生命周期、SWS_DM_01369 SOVD 服务器），确保兼容性；安全性高：DoIP/SOVD 均支持 TLS 加密，UDS/SOVD 共享安全状态，严格的权限校验与认证机制；可扩展性。原创 2025-09-03 16:56:32 · 156 阅读 · 0 评论