工程师手把手教你看明白:AUTOSAR平台与应用软件开发_

诚挚感谢EEWorld提供的宝贵机会，让我有幸获得《Adaptive AUTOSAR平台与车用高性能控制器开发》的阅读和分享资格。以下是该专业书籍的第一次分享：

第一章　汽车电控系统的发展与Adaptive AUTOSAR平台

1.1 汽车电控系统简介

汽车电控系统由传感器、电子控制器（ECU）、驱动器和控制软件等组成，通过电缆或无线传输与汽车机械系统配合。早年的汽油机需要火焰点火，最初的电控通过点火线圈和蓄电池组成点火装置通过火花塞点火，而后增设了照明，以及取代手摇的发动机起动机，汽车电控由此而生。

扫码发送暗号：1217，加入汽车技术交流群

1.1.1 汽车电控系统的历史

起源阶段（20 世纪 30-50 年代）：电子管收音机、晶体管逐步应用，功能集中在照明、低压电源、收音机、空调等基础功能，1948 年晶体管和 1958 年集成电路的出现奠定了技术基础。

初步发展阶段（20 世纪 60 年代）：聚焦发动机周边零部件电子化，1967 年集成电路首次应用，克莱斯勒推出电子点火装置，博世开发电子燃油喷射装置，功能涵盖交流发电机控制、电子点火控制等。

快速发展阶段（20 世纪 70 年代）：以集成电路和 16 位及以下微处理器应用为标志，电子汽油喷射（EFI）和制动防抱死（ABS）技术成熟，博世推出多个燃油喷射系统（如 D-Jetronic、L-Jetronic 等），同时自动门锁、自动巡航等众多控制系统开始研发。

成熟阶段（20 世纪 80 年代后）：微电脑应用成熟，向智能化发展，出现电子转向助力（EPS）、车身控制系统（空调、仪表等）、自动巡航系统、胎压监测（TPMS）等，功能更丰富且可靠。

革新阶段（20 世纪 90 年代 - 21 世纪初）：1995 年博世推出车身电子稳定系统（ESP），1986 年博世推出控制器局域网（CAN）总线，电子电气架构从独立系统变为网络控制系统，后续 TTCAN 协议扩展了 CAN 的应用。

1.1.2 汽车电控系统发展前沿

21 世纪 “新四化” 推动电子电气架构从分布式向集中式演进：

分布式架构问题：ECU 数量多（上百个）、线束长，存在空间占用大、成本高、开发难、OTA 升级困难等 10 大问题。

集中式架构案例：特斯拉 Model 3 采用区域划分的集中式架构（中央计算模块 + 左右车身控制模块）；安波福推出智能汽车架构（SVA），含数据动力中心（PDC）和开放式服务器平台。

互联架构趋势：车联网与云计算推动架构延伸至云端，实现车与车、车与设施等互联，功能与云端交互增多，安全（如防火墙）更重要。

博世架构规划：分模块化、功能集成、中央域控制器、跨域融合、车载中央计算机和区域控制器、车载云计算 6 个阶段，软件向服务导向发展

1.1.3 

域控制器发展

演进阶段：电子电气架构从分布式→域集中式→中央计算式，当前处于分布式向域集中式过渡。

组成与核心思想：由域主控处理器、操作系统、应用软件及算法组成，核心是平台化、高集成度、高性能、兼容性，可集成多 ECU 功能，降低成本。

域划分方式：博世分为自动驾驶、底盘、动力、座舱、车身 5 域；部分厂商融合为三域（车控域、智能驾驶域、智能座舱域），如理想 L9 采用三域架构。

开发挑战：软件代码量激增（未来自动驾驶或达 3-5 亿行）、故障率高（2022 年上半年因软件问题召回超 123 万辆）、网络安全威胁大，需统一开发规范，AUTOSAR 应运而生。

1.2 AUTOSAR 的起源及发展

AUTOSAR（汽车开放系统架构）是全球汽车产业链共同参与的开放软件架构，旨在统一开发规范。

1.2.1 诞生与目标

诞生背景：汽车电子软件复杂，不同厂商标准不一，复用性低，需解决安全、更新、集成等问题。

核心目标：满足未来车辆需求（安全性、可升级性等）；提高功能集成的灵活性与复用性；提升软硬件商用现货渗透率；标准化接口提高软件复用率；缩短开发周期、降低成本、控制风险。

1.2.2 发展历程

准备阶段（2002-2003 年）：2002 年开启研讨会并成立团队，2003 年起草经典平台（Classic Platform）架构，核心成员制定初始开发协议。

发展阶段（2003 年至今）：2003 年正式宣布架构，后续福特、丰田等加入核心伙伴，经典平台版本持续更新（1.0-4.3.0），成员数量不断增加（2016 年达 191 家）。

成熟阶段：2017 年 3 月自适应平台（Adaptive Platform）“示范性软件” 开发完成并发布 2017-03 版本。

在硬件、算力、软件架构、设计原则、开发过程、通信方式、调度方式、状态管理等方面，两者的差异如下：

与CP相比，基于AP开发的ECU具有更加智能、更大的计算力(基于SOA架构使得AP能够支持多核并行处理)，更好的安全性，更好的兼容性，更灵活敏捷的开发，更易实现物联(基于以太网的SOA 通信，更易实现无线远程、云连接以及部署 V2X 应用 )。浏览完整内容请移步原文链接：https://www.eeworld.com.cn/a4K8u54

一、Adaptive AUTOSAR（AP）架构总览

书籍第二章内容主要为AP 架构总览、运行环境与操作系统、标准功能集群三个层级，分别涉及逻辑与物理架构全景图，OS 需求、POSIX、调度、内存、设备等，以及13 个核心模块的具体内容，本贴对其内容进行概括后整理了层级关系，以展示Adaptive AUTOSAR（AP）的架构及其核心组成。 

二、核心内容总结

2.1 AP 架构总览

AP（Adaptive AUTOSAR）架构分为逻辑架构和物理架构，前者定义功能交互逻辑，后者明确硬件与软件的物理部署。

2.1.1 逻辑架构

AP（Adaptive AUTOSAR）的逻辑架构分为四层，分别是“顶层”的业务层AA、“中间层”ARA、“系统服务层”FC、以及“资源测层”即硬件和操作系统，

2.1.2 物理架构

AP（Adaptive AUTOSAR）的物理架构设计进程、交互方式以及清单等主要内容，具体的层级关系如小表所示：

2.2 AP 的运行环境及操作系统

AP 依赖操作系统实现资源管理，不指定新 OS，而是定义接口规范。

2.3 AP 标准规范功能集群

功能集群（FC）是 AP 的核心功能模块，共 13 类，涵盖从基础管理到安全防护的全场景。

三、总结

Adaptive AUTOSAR（AP）以 “灵活部署、服务化通信、安全可靠” 为核心，通过逻辑架构明确功能交互，物理架构规范部署，再结合 13 类功能集群覆盖从应用运行到安全防护的全流程。其设计兼顾汽车电子的实时性、安全性需求，同时支持 OTA 等动态更新场景，是智能汽车软件架构的重要基础。浏览完整内容请移步原文链接：https://www.eeworld.com.cn/a0uXj5O

下面要和大家分享的是关于第三章 智能驾驶域控制器安全规范的内容。安全是智能驾驶汽车的核心，这份规范从功能安全到信息安全，覆盖了研发、生产、运行等全流程，内容扎实且极具参考价值，一起来看看吧！

3.1 安全 —— 智能驾驶汽车的重要目标之一

驾驶中，因技术设备缺陷、操作错误等，致人员受伤、设备受损、财务损失，或影响正常行驶、威胁行车安全，这些情况均视为行车事故。安全关乎生命，对智能驾驶汽车而言，安全是优先考虑事项，也是开发控制器软硬件时首要设计要求。接下来，将主要围绕“功能安全”和“信息安全”两核心主题详细阐述。 

3.2 功能安全

汽车研发中，安全是关键。新功能用于辅助驾驶等安全相关领域，其研发与集成强化了安全系统研发需求，需为实现安全目标提供证据。

为达成功能安全目标，功能安全概念明确基础安全机制和措施，合理分配安全要求到系统架构各元素，主要有故障检测和失效缓解等措施、安全状态转换等机制。

基于这些机制，结合项目定义等因素，可将功能安全要求分配到子系统并确定 ASIL。ISO 26262 标准（含导则）为应对系统和随机硬件失效风险提供要求和流程，覆盖汽车全生命周期，提供风险等级评估方法（ASILs），但主要适用于最大毛重不超 3.5t 的乘用车 EE 系统，不涵盖特殊用途车辆及非 EE 系统故障导致的危险。 

3.2.1 功能安全管理

ISO 26262 是道路车辆 EE 系统功能安全标准，适用于安全相关的电力、电子、软件元素组成的系统全生命周期。它通过 10 个部分规范功能安全管理、设计、研发、生产操作等流程，形成 “安全管理生命周期” 框架，确保产品各环节满足安全要求。项目阶段与要求包括项目界定、安全生命周期、风险分析与评估、功能安全、系统层面的产品、硬件层面的产品、软件层面的产品、生产和操作、产品、产品操作、维护与拆解、可控性、外部措施、其他技术等全生命周期要求和措施，才能研发、生产出满足功能安全的产品。 

.2.2 系统级产品研发

确定功能安全概念后，系统级研发依据 ISO 26262-4，基于技术安全要求的 “V 模型” 推进，左分支聚焦系统设计与测试，右分支聚焦集成、验证、确认及功能安全评估。系统开发核心流程为：启动产品开发明确技术安全需求后进入系统设计阶段；搭建系统体系结构并分配技术安全要求；细化硬件、软件接口等需求，导出子系统需求；完成硬件和软件集成测试后进行装车测试；达标后执行安全确认，提供满足安全目标的证据。

此外，系统级研发还需关注：遵循系统设计规范和技术安全概念，分配技术安全要求，设计考虑可验证性；遵循系统架构设计约束，满足对应 ASIL 等级要求，定义安全相关接口；采取系统失效避免措施，分析故障原因和影响，采用可靠技术；做好硬件和软件配置，细化技术安全要求；明确硬件和软件接口规范，规定交互规则和诊断功能；明确运行、维护和关闭要求，涵盖安装说明等；进行系统设计验证，采用特定方法验证设计是否符合安全概念，更新风险评估报告。 

3.2.3 硬件级产品开发

硬件级研发目标是规划并执行硬件开发的功能安全活动，需与系统和软件研发协调，核心内容如下：

硬件架构设计：实现硬件安全要求，各硬件单元满足最高ASIL等级需求，架构具模块化、适当粒度、简易性等特征，考虑环境因素对安全相关组件的影响。

硬件详细设计：遵循组织安全文化，避免设计缺陷，考虑非功能性因素致安全相关部件失效问题，确保操作条件符合环境和操作限制，采用稳健设计原则。

安全分析：依据因果分析和预测分析的硬件设计安全分析方法和ISO 26262 - 9识别故障原因和影响用于设计规范和验证，针对ASIL B/C/D等级分析安全故障、单点故障、多点故障（重点双点故障）。单点故障指未被安全机制覆盖、直接违反安全目标的硬件故障（适用于ASIL B/C/D），需提供安全机制和残余故障诊断覆盖率评估证据；潜在故障指在多点故障检测间隔内，无法被安全机制或驾驶人识别的多点故障（适用于ASIL B/C/D），需提供故障检测并通知驾驶人的能力证明及诊断覆盖率评估。

硬件设计验证：依据ISO 26262 - 8验证硬件设计是否符合安全要求，可采用检查实施完整性、故障注入测试等方法，若实施不可行，启动变更管理流程。

生产、运行、服务和关闭：若安全分析表明某些特性与安全相关，明确其核查措施、验收标准等。 

3.2.4 软件级产品开发

软件级研发目标是规划并启动软件开发的功能安全活动，核心流程如下：

软件安全需求规范拟定：基于技术安全概念和系统设计规范拟定需求，细化软硬件接口要求并验证其与安全概念的一致性，需求要覆盖可能违反安全要求的功能故障。

软件体系设计：设计满足安全需求的架构并校验，架构要有模块化等特征，同时考虑可验证性等，采用适当抽象水平的符号。

软件单元设计和实现：依据体系设计制定详细方案并实现为模型或源代码，实现前进行静态验证，需同时满足安全和非安全相关需求。

软件单元测试：验证单元是否符合设计规范，测试要覆盖功能等方面，按ISO 26262 - 8规划执行。

软件集成和测试：按依赖关系集成软件单元直至完成嵌入式软件集成，测试要验证架构设计等，测试用例通过等价类等方法设计。

软件安全需求验证：在目标硬件上测试，验证嵌入式软件是否满足安全需求，评估测试结果，确认覆盖范围等。

3.3 信息安全

随着汽车互联化和智能化，车辆不再是孤立个体，逐渐成为网络攻击目标，网络安全已成为汽车安全的基础。行业通过探索形成了一系列规范，以下是核心内容。

3.3.1 汽车信息安全规范介绍

SAE J3061：提供车辆网络安全流程框架，覆盖全生命周期，含指导原则、工具和方法论，企业可按需裁剪使用。

ISO 21434：基于 SAE J3061，参考 V 模型开发流程，涵盖术语定义、信息安全管理等多方面；从风险评估、产品开发等四个维度保障安全，目标是使产品具备防护能力。

SHE（Security Hardware Extension）：即安全硬件扩展，是广泛认可的硬件网络安全规范。

Evita：欧盟项目，聚焦 V2X 场景网络安全，定义硬件安全模块（HSM）功能，将 HSM 分为 High、Medium、Light 三级（Light 级功能接近 SHE）。 

3.3.2 其他标准、规范

NIST FIPS 140（美国联邦信息处理标准）虽不直接针对汽车行业，但影响力大，适用于软硬件模块，将网络安全分为 4 级（从低到高）：等级 1 满足基础安全要求（如用批准的加密算法），不考虑物理攻击；等级 2 在等级 1 基础上增加防物理攻击措施（如防拆封涂层）；等级 3 强化物理防护，检测到攻击时可擦除密钥，降低密钥泄露风险；等级 4 为最高等级，可检测各类物理攻击并擦除密钥，且不受环境（温度、电压）影响。 

3.3.3 安全硬件

安全硬件是系统 “信任锚”，核心作用是提供密钥存储安全区域与安全运行环境，主要包括：受保护存储器，仅允许安全 CPU 或安全逻辑访问，阻止外部非法访问；随机数生成器，需提供高熵值随机数据（如密钥），通常采用 CSRNG，需符合 NIST SP800 - 90A 等标准；安全运行环境，隔离硬件组件，防止主处理器代码访问，保障密码运算和密钥操作安全；HSM 集成在 ECU 的 MCU 中，含专用安全 CPU、加密算法加速器等，提供核心安全支持。此外，规范还介绍用于优化 ECU 硬件设计的 PCB 硬件强化措施。 

3.3.4 安全启动

安全启动用于确保ECU固件真实完整、按OEM意图运行，核心是启动前通过身份验证（如校验固件签名）检测篡改。其启动模式分两种：串行启动，依次验证各代码段，全部通过后顺序启动；并行启动，验证一个模块后立即执行，同时触发下一个模块的验证（如先验证BL，执行时触发BM验证）。注意：需保护硬件调试接口，防攻击者绕过安全启动；安全启动不保护RAM中的应用数据。 

3.3.5 数据安全存储

敏感数据（如用户隐私、车辆数据、密钥）应存储在安全区域（如 MCU 内部存储器、HSM）或经密码学算法保护的外部存储器（如 EEPROM），以防泄露和篡改。车辆敏感数据分三类：隐私相关数据（如姓名、住址等）需加密保护；车辆数据（如 VIN、配置数据等）要保障完整性，防止篡改致车辆异常；密钥数据（如对称密钥、非对称私钥）需绝对保密，是安全方案核心。数据安全通过加密（如对称加密）保障机密性，通过哈希、签名等保障完整性和真实性，HSM 等模块可加速加密运算并保护密钥。 

3.3.6 车内安全通信

车内ECU间通信通过SecOC保障完整性和真实性。不同远程控制场景（如远程控温、车门控制）建议用专用SecOC密钥，降低密钥泄露风险。

SecOC密钥注入流程：诊断仪向ECU发ECU ID请求，ECU返回ID，诊断仪将其转发给供应商服务器；服务器用KDF函数（基于主密钥和ECU ID）生成传输密钥发给诊断仪，诊断仪再转发给ECU；ECU将传输密钥存入HSM等安全存储，服务器擦除传输密钥防泄露。 

3.3.7 安全刷写

安全刷写用于验证写入闪存的更新数据，基于非对称加密（数字签名和公钥），核心是“两级签名”机制：初级签名验证软件签发者真实性并获取其公钥以验证二级签名；二级签名含升级包摘要和签名，验证升级包真实性和完整性。设备需在首次更新软件前完成验证，两级签名提升了密钥更换灵活性。

3.3.8 安全诊断

通过改进外部诊断仪与中央网关认证机制保障诊断安全，核心方案如下：
中央网关转发除 session control 外的诊断消息，未认证时阻断 session control 服务；高权限服务仅在非默认会话支持，需认证外部设备；网关检查诊断仪身份以确认真实性；保留原有 ECU 安全访问机制以减少工程变更。浏览完整内容请移步原文链接：https://www.eeworld.com.cn/a1un500

4.1 RTA-VRTE —— ETAS 官方 Adaptive AUTOSAR 

1. CASE趋势驱动

•  汽车电子架构受互联（Connectivity）、自动驾驶（Autonomy）、共享（Shared Ownership）、电气化（Electrification）推动，需支持高性能计算（HPC）、动态通信（如SOME/IP）、OTA更新。

• 传统 Classic AUTOSAR 已无法满足“CASE”（Connectivity, Autonomy, Shared-ownership, Electrification）需求：高带宽以太网、高性能计算（HPC）、OTA、跨域融合。
• Adaptive AUTOSAR = “软实时 + 高资源 + POSIX OS + 动态服务发现”，填补 Classic 与信息娱乐系统之间的空白。

• 博世子公司 ETAS 推出的商用级 Adaptive AUTOSAR 开发套件。
• 提供“开箱即用”虚拟机（VirtualBox）环境：主机 VM + 多目标 ECU VM（QNX/Linux，x86/ARM）。
• 核心组件：Adaptive Studio（图形化建模/代码生成）、RTA-VRTE SDK、构建&部署脚本、示例工程。

4.1.1 RTA-VRTE SK（Starter Kit）

• 主机虚拟机：预装 Debian + Xfce，含 Adaptive Studio、交叉工具链、SDK。
• 目标 ECU 虚拟机：每个 ECU 一个独立实例，支持 QNX 7.0 & Linux x86-64/ARMv8。
• 网络：静态子网 192.168.56.xx，支持 SOME/IP、NFS 共享，可桥接真实硬件。
• 一键脚本：
• rvbuild（构建+部署）
• rvdeploy（仅部署）
• rvrun / rvkill / rvwin（启停/SSH）
• 资源需求：≥8 GB RAM、35 GB 磁盘、双核 CPU（推荐重配以获得最佳性能）。

4.1.2 软件安装与使用

1. 安装 VirtualBox → 导入 rta-vrte-sk-v*.vdi → 启动。
2. 首次登录：developer / dev12345。
3. 运行置信测试：

bash
cd ~/<user>/vrte
confidence-test

1. 键盘布局：setxkbmap gb（示例）。
2. 关闭 VM：正常关机即可保持快照。

5.1 虚拟机准备（VirtualBox）

1. 磁盘映像类型与格式

• GUI：媒体管理器 → 复制 → 选格式/分配方式。
• CLI：VBoxManage clonemedium disk <in> <out> --format VHD --variant Fixed|Standard。

• 静态：固定大小→最佳性能；
• 动态：按需增长→最小包，易碎片化，性能稍差。

• 支持格式：VDI（默认/最小包）、VMDK、VHD、HDD（Parallels）。
• 静态 vs 动态分配
• 复制/克隆

• 客户机单用户模式 zerofree /dev/sda1 → 宿主机 VBoxManage modifymedium --compact *.vdi。

1. 静态化：克隆原始动态映像 → 指定“Fixed size”。
2. 共享文件夹：映射宿主机 C/D → VM 里 $HOME/c、$HOME/d 符号链接，项目文件夹可直接放宿主机。
3. 加盘：新建固定 VDI → 分区 fdisk → 格式化 mkfs.ext4 → 挂载到 /home/developer/vrte/project。
4. 压缩：

• GUI 滑动条增容 → 客户机单用户模式：

fdisk /dev/sda   # 删、重建分区
resize2fs /dev/sda1

完成后再压缩镜像。

5.2 代理服务器配置（企业/实验室网络必备）

1. VirtualBox 代理
   File → Preferences → Proxy → 填入 HTTP/HTTPS。

1. 客户机（Debian）全局代理

• ~/.bashrc 追加

export http_proxy=http://user:pass@proxy:port
export https_proxy=$http_proxy

6.1 虚拟机桌面与虚拟机设置

工欲善其事，必先利其器。开发Adaptive AUTOSAR应用，首先要搭建稳定、高效的开发环境。因AP平台基于POSIX兼容的操作系统（如Linux），而工程师开发主机多为Windows，所以使用虚拟机（VM）是主流方案。

虚拟机镜像与资源分配：AP开发常用特定Linux发行版，如Ubuntu 20.04/22.04 LTS或Yocto Project定制系统，很多工具链供应商（如ETAS）会提供预配置好的虚拟机镜像或部署脚本（书籍以含RTA - VRTE的Debain系统VirtualBox虚拟机为例，默认用户名devloper，密码dev12345）。

• 以部署典型AP开发环境（如ETAS RTA - VRTE Starter Kit）为例，推荐的虚拟机资源配置如下：操作系统为64位Linux（如Ubuntu 22.04 LTS）；CPU至少分配2个逻辑核心，建议4核及以上；内存推荐分配8GB，大型项目或同时运行多个仿真场景建议16GB及以上；硬盘空间100GB以上；网络适配器必须设为“桥接模式”，它能让虚拟机获独立IP地址，是实现与外部设备网络通信的关键。    

6.1.1 键盘设置

虚拟机的键盘配置需确保与宿主系统无冲突，通常建议启用 “自动捕获键盘” 功能，以便在虚拟机窗口激活时，键盘输入直接映射至虚拟机。同时，可通过虚拟机设置中的 “键盘映射” 功能，自定义快捷键（如 Ctrl+Alt 用于快速切换宿主与虚拟机），避免与开发工具快捷键冲突。对于多语言开发场景，需在虚拟机操作系统中配置默认输入法为英文，防止代码输入时出现字符编码问题。

6.1.2 屏幕设置

为提升开发体验，建议将虚拟机屏幕分辨率设置为与宿主显示器匹配的高清模式（如 1920×1080），并启用 “无缝窗口” 或 “全屏模式”。通过虚拟机的 “显示设置” 可分配足够的显存（推荐 2GB 以上），确保 Adaptive Studio 等工具的界面渲染流畅。此外，多显示器用户可配置 “扩展显示”，将代码编辑区与调试视图分屏显示，提高开发效率。

6.2 平台初识

本节的“Adaptive Studio”在业界并非一个标准化的官方名称，它通常指代特定供应商提供的集成开发环境（IDE），例如ETAS的ISOLAR-VRTE或Vector的DaVinci Developer Adaptive。书籍以ETAS公司RTE-VRTE的AP平台为例，介绍RTA-VRTE基本结构及启动、虚拟机和宿主机之间的文件传输、Adaptive Studio中创建AUTOSAR项目及AUTOSAR AP应用程序等。

6.2.1 入门指南

Adaptive AUTOSAR 平台入门需掌握三大核心概念：服务导向架构（SOA），定义标准化服务接口实现软件组件松散耦合；动态部署，支持应用程序运行时按需加载和更新，无需重启系统；高性能通信，基于 SOME/IP 协议实现跨 ECU 实时数据传输。

RTA - VRTE 由运行在主机上 VirtualBox 内的虚拟机主机组成，宿主虚拟机含构建 AP 的系统和开发工具，构成 ETAS 自适应 AUTOSAR 开发环境。其构建系统在虚拟机主机执行，可创建 AUTOSAR 自适应应用程序并部署到一个或多个目标 ECU 虚拟机。每个目标 ECU 虚拟机在虚拟机主机执行，提供单独的 AUTOSAR 自适应平台实例（Machine），包含执行管理和通信管理等 AUTOSAR Adaptive 功能集群。不同目标 ECU 虚拟机可支持不同目标操作系统，如 QNX 或 Linux。此外，RTA - VRTE 虚拟机主机有目标以太网网络，所有目标 ECU 都连接到该网络。  

6.2.2 Adaptive Studio 中的代码实现

在IDE中，代码实现核心是编写符合ara::com API标准的C++代码。开发者通常要实现两部分：服务提供方 (Skeleton) 实现服务接口中方法和事件的具体逻辑；服务使用方 (Proxy) 通过代理调用服务接口访问远程服务。现代IDE（如Simulink）支持从模型直接生成符合AP标准的C++代码框架和ARXML描述文件，开发者只需在指定位置填充业务逻辑。 

书籍中使用 rvproject 脚本创建 Eclipse CDT项目，以便在 Adaptive Studio 中实现代码。由rvproject脚本创建的CDT项目通常会与AUTOSAR配置冲突，从而导致下拉框中出现重复条目等。因此，要创建CDT项目，通过执行以下命令:

rvproject Exereise1

这将创建一个名为build_exercise1的文件夹，用于存储Eclipse 项目，导入自适应平台。

6.2.3 Adaptive Studio

如前所述，Adaptive Studio是一个集成工具环境，其主要功能有：ARXML建模，以图形化或表单方式定义软件组件（SWC）、服务接口、数据类型等；代码生成，基于ARXML模型自动生成Skeleton/Proxy类、CMake构建脚本和清单文件框架；配置编辑，通过专门编辑器（如执行管理编辑器、通信管理编辑器）配置平台行为；交叉编译集成，集成交叉编译工具链，一键编译生成目标平台可执行文件。 

书籍通过构建一个非常简单的应用程序，并部署到目标 ECU为例，展示 RTA-VRTE Adaptive Studio AUTOSAR 编辑器中创建一个新项目的整个过程。

6.2.4 编译和部署项目

编译过程通常由IDE集成的CMake和交叉编译器（如aarch64-linux-gnu-gcc）完成，产物包括可执行文件及JSON或XML格式清单文件。部署在AP中是核心概念，指将可执行文件和清单文件打包，通过更新与配置管理（UCM）模块安装到目标硬件，可在车辆全生命周期动态增减或更新软件功能。RTA - VRTE构建脚本自动化该过程，在/home/developer/vrte/project项目终端输入“rvbuild -d Exercise1 20”，可实现：1) 构建项目；2) 部署到ID为20的目标ECU（虚拟机）；3) 从Linux(或QNX)SDK部署标准库文件、可执行文件和脚本；4) 运行虚拟机（默认）。 

6.2.5 执行

构建和部署的应用程序未与自适应平台集成，不会在目标ECU启动时自动启动，需手动启动。要启动一个命令窗口与新启动的虚拟机对话，如rvwin 20，手动启动应用程序时在命令窗口输入：/opt/vrte/usr/bin/Exercise1。应用在目标机上的执行由执行管理（EM）功能集群负责，EM会解析执行清单，依据其中定义的状态、依赖关系和资源限制，按正确顺序启动和停止应用程序进程。 

6.3 执行管理的集成

执行管理（EM）是AP平台“指挥官”，负责管理机器状态、应用进程生命周期与资源分配，确保系统确定性和可靠性。书籍通过案例展示为执行管理创建必要配置，添加应用程序生命周期管理配置文件。涵盖内容包括：1) 自适应平台控制下自动执行自适应应用的方法；2) 启动执行管理编辑器及了解其总体布局的方式；3) 使用执行管理编辑器定义可执行文件和进程元素的操作；4) RTA - VRTE内执行管理的ECU（基于数据）配置的工作原理；5) 自适应应用程序履行对执行管理责任的途径。

6.3.1 AUTOSAR 项目

在AUTOSAR项目中，EM配置是系统设计关键。开发者需在IDE中定义：可执行文件，指定程序名称、路径、启动参数等；进程，将一个或多个可执行文件映射到进程实例，配置用户/组、调度策略、资源限制等；状态机，定义系统级状态及状态转换时需启动或停止的进程；依赖关系，定义进程间启动和关闭顺序。在VRTE Adaptive Studio中，只需在Artop视图下，通过File菜单的“New - AUTOSAR Project”创建新项目。

6.3.2 执行管理编辑器

执行管理编辑器用于配置执行管理相关参数，可定义进程优先级、调度策略等，如设高优先级确保关键功能实时性，还能设置进程同步机制防数据冲突，确保系统稳定。RTA - VRTE 的执行管理用处理后的清单配置，早期依赖源文件 ExMConfg.cpp 预编译配置，后期支持 ECUCFG（基于数据）配置，其在 ECUCFG 文件中定义配置，由守护进程运行时加载，执行清单信息处理成 ECU 配置存于节点数据文件。需注意，执行管理只能启动注册的自适应应用程序，配置不当会致应用无法启动。Adaptive Studio 有自定义编辑器，可简化配置并自动生成 ECUCFG 文件。

配置执行管理步骤如下：

1. 定义 Machines 和 Machine Designs

Machines 是支持自适应平台的实例，配置平台实例相关信息，如状态、进程映射及启停进程状态；Machine Designs 可配置服务访问控制等，二者应关联。

2. 关联机器和功能组

需创建从 Machine 到 ModeDeclarationGroup 的引用，将已定义的函数组与 Machine 关联，使同一功能组可在多台机器复用。 

6.3.3 执行编辑器

执行编辑器专注于对单个可执行文件内任务的配置。在执行编辑器中，可以设置任务的执行周期、执行时间限制等。例如，对于一个周期性采集传感器数据的任务，可以设置其每 10 毫秒执行一次，确保数据采集的实时性和准确性。通过合理设置任务参数，能够优化系统性能，提高资源利用率。

VRTE Adaptive Studio的执行编辑器，用于定义应用程序进程、可执行文件等，支持从AUTOSAR ARXML配置生成预编译源代码或基于数据的ECUCFG配置

6.3.4 ECUCFG 的生成

ECUCFG（ECU Configuration）是AP中一种基于数据的配置机制 。与传统的代码生成不同，ECUCFG允许在运行时加载配置，增加了灵活性。在EM的上下文中，执行编辑器可以将定义好的进程、状态机等配置信息，生成为一个ECUCFG文件（通常是二进制或优化的数据格式） 。这个文件随后会被部署到目标机，由EM守护进程在启动时解析和应用 。这种方式特别适用于需要频繁调整启动行为而不想重新编译整个平台的场景。

6.3.5 软件生命周期

EM管理贯穿软件全生命周期，涵盖安装、启动、运行、关闭和卸载。它与UCM和PHM等模块协作，确保软件更新的原子性与安全性，故障时执行恢复策略。

在VRTE Adaptive Studio中，自适应应用程序需用AUTOSAR进程生命周期界面方法报告生命周期状态变化，涉及两个关键转变：一是从初始化到ara::exec::ExecutionState::kRunning，应用程序完成初始化并准备服务时报告；二是从ara::exec::ExecutionState::kRunning到ara::exec::ExecutionState::kTermination，应用程序即将终止时报告。

自适应平台有应用程序接口，用于报告应用程序生命周期状态到执行管理的转换，该接口作为类执行客户端的成员函数实现。创建类ExecutionClient实例（通常全局范围）后，应用程序可用ReportExecutionState API报告状态转换。

简单应用程序需在主源文件添加四项内容：一是包含头文件ara/exec/execution_client.h以访问应用程序生命周期界面；二是实例化类ara::exec::ExecutionClient；三是进入main后通知执行管理应用程序正在运行；四是退出main时通知执行管理应用程序正在终止。 

6.4 服务接口配置

服务接口是 Adaptive AUTOSAR 中应用程序通信的基础，定义了数据格式和交互方式。

6.4.1 AUTOSAR 项目

1. 启动 VRTE Adaptive Studio，切换至 Artop 视图；
2. 通过 “File> New > AUTOSAR Project” 创建项目，名称为 “Exercise3”，路径为/home/developer/vrte/project/Exercise3；
3. 取消勾选 “Use default location”，确认文件夹已存在后点击 “FINISH”。

6.4.2 创建新的文件

服务接口通过.hadl 文件定义（基于领域特定语言 DSL）：

1. 右键项目选择 “New> File”，命名为 “Interface.hadl”（必须使用.hadl 扩展名）；
2. 或通过 “File> Application Design file (hadl)” 直接创建，自动关联项目。

7.1 自适应巡航控制(ACC)简介

自适应巡航控制(Adaptive Cruise Control，ACC)系统是一种智能化的自动控制系统，它是在传统巡航控制技术基础上发展而来的。ACC系统将汽车自动巡航控制系统(Cruise Control System，CCS)和车辆前向撞击报警系统(Forward Collision Warning System，FCWS)有机结合，实现了预碰撞功能。

ACC系统工作原理：

1. 通过前部车距传感器(雷达)持续扫描前方道路
2. 轮速传感器采集车速信号
3. 当与前车距离过小时，系统协调制动防抱死系统和发动机控制系统
4. 通过适当制动和降低发动机功率保持安全距离
5. 需要更大减速度时会通知驾驶员主动制动

系统组成：

• 传感器：雷达、车速、节气门位置、制动踏板等
• 控制单元：微处理器为核心
• 执行单元：节气门执行器、制动执行器
• 人机交互界面：高清显示屏或仪表盘
• 通信总线：车载以太网承载 SOME/IP 服务

7.2 模型搭建

7.2.1 建立AUTOSAR项目

使用VRTE Adaptive Studio创建AUTOSAR项目步骤：

1. 启动VRTE Adaptive Studio，选择Artop透视图
2. 通过File > New > AUTOSAR Project创建新项目
3. 设置项目名称为"ACC Demo"
4. 设置项目位置为/home/developer/vrte/project/ACC_Demo

7.2.2 执行管理配置

执行管理(EM)配置步骤：

1. 创建机器设计(Machine Design)

• MachineDesign A：线控底盘域控制器
• MachineDesign B：自动驾驶域控制器

• DLT：日志追踪
• RouDi：进程间通信服务发现和守护
• Comd：程序间通信
• SM：状态管理

关键配置点：

• 为每台机器添加可执行文件
• 配置软件地址
• 确保服务正确关联

7.2.3 通信管理配置

通信管理配置流程：

1. 使用Application Design Editor创建服务接口
2. 定义数据类型：

• 浮点类型：传递距离、速度信息
• uint8：传递状态信息

• 服务实例ID设置为19
• UDP端口设置为5000

7.3 在RTA-VRTE上的配置应用软件

7.3.1 SM配置

dummysm.cpp 仅向执行管理报告 kRunning，其余空循环，满足 EM 对“存在状态管理进程”的强制要求。浏览完整内容请移步原文链接：https://www.eeworld.com.cn/aOyLK4C

在智能驾驶系统开发中，域控制器的工程集成与调试是确保功能落地的关键环节。本次分享聚焦智能驾驶域控制器的两大核心任务 —— 参数标定（基于 XCP 协议）与诊断管理（基于 VRTE 诊断框架），结合实操流程与技术细节，帮助大家掌握从环境配置到功能验证的全流程要点。

8.1 参数标定——使用 XCP

XCP（扩展校准协议）是汽车领域常用的测量与校准协议，可结合 INCA 等工具与 RTA-VRTE SK，实现对自适应应用的变量读取（测量）与更新（校准）。核心流程围绕目标网络配置、桥接适配器搭建、XCP 协议实现、示例验证四步展开。

8.1.1 目标网络

• 核心配置
  ：RTA-VRTE SK 主机虚拟机需配置 “Host-Only Ethernet Adapter”（仅主机以太网适配器），确保：
• 主机虚拟机可识别所有虚拟目标 ECU，虚拟 ECU 能直接装载主机提供的 NFS 共享；
• 192.168.56.x 网段仅主机可见（需外部访问时需配置 “bridge” 桥接适配器）。
• 检查步骤：打开 Oracle VM VirtualBox Manager，选中 RTA-VRTE SK 虚拟机→点击 “Settings”→“Network”→确认 “适配器 2” 连接 “仅限主机的适配器”，记录适配器名称（后续需使用）。

8.1.2 桥接适配器

桥接适配器相当于 “软件电缆”，连接虚拟机仿真网络与实际硬件网络，步骤如下：

1. 打开主机 “网络连接”，选中需桥接的两个适配器（如 “VirtualBox 仅主机适配器” 与物理网卡）；
2. 右键选择 “桥接”，生成新以太网设备；
3. 配置新设备属性：

• 取消勾选 “Client for Microsoft Networks” 和 “File and Printer Sharing”；
• 选中 “Internet Protocol Version 4 (TCP/IPv4)”，设置 IP 为 192.168.56.1，子网掩码 255.255.0.0。

8.1.3 XCP on POSIX

Classic AUTOSAR 通过固定内存地址实现校准，但自适应 AUTOSAR（AP）中每个应用有独立虚拟地址空间，因此 XCP 引入数据注册表机制，用 “虚拟地址” 替代物理地址。

欢迎关注EEWorld旗下订阅号：“汽车开发圈”