随着“软件定义汽车”浪潮席卷行业，汽车电子电气（EE）架构正从分布式向集中式、域控制器架构演进，AUTOSAR Classic（CP）与AUTOSAR Adaptive（AP）的混合部署已成为主流趋势——CP承载传统实时控制类功能，AP支撑高算力、高灵活性的服务化功能，而如何实现两者的高效协同建模，成为车企及Tier1突破开发瓶颈的关键。Vector公司的 PREEvision工具凭借全流程建模能力，完美实现 CP&AP 混合建模的功能，为汽车智能化、网联化开发提供了一体化解决方案。今天我们就完整地梳理一下基于PREEvision混合建模的开发流程。
一、为什么要打通CP与AP通信链路？
在聊建模之前，我们先明确一个核心问题：为什么现在越来越多的EE架构，需要同时用到CP和AP？简单来说，两者的定位互补，缺一不可，适配汽车不同类型的功能需求：
- AUTOSAR Classic（CP）：主打“实时性、可靠性”，适用于发动机控制、底盘控制、车身控制等传统实时控制类ECU，核心优势是轻量化、低延迟，能够稳定支撑车辆基础行驶功能，是汽车EE架构的“基础骨架”。
- AUTOSAR Adaptive（AP）：主打“高算力、高灵活性、服务化”，适用于智能座舱、自动驾驶、OTA升级等需要大量数据处理和灵活部署的场景，基于SOA（面向服务架构）设计，支持动态部署、插件化开发，是汽车智能化的“核心大脑”。
而混合建模的核心需求，就是打破CP与AP之间的“数据壁垒”，实现两者的无缝协同，让CP的实时控制功能与AP的服务化功能高效交互，同时保证模型的一致性、可追溯性，避免重复建模、接口不兼容等问题，最终缩短开发周期、降低开发成本。PREEvision恰好完美适配这一需求，它不仅支持AUTOSAR Classic和AUTOSAR Adaptive的单独建模，更能通过统一的建模环境、数据链路，实现两者的深度融合，让混合架构设计更高效、更规范。
二、打通CP与AP通信链路的方法
结合实际开发场景，我们将混合建模流程拆解为四个核心步骤，如下：
第一步：软件层的搭建
对于AP侧需要创建：
- 创建UML Package，用来存放Service和Service Interface。Service Interface需要赋予给软件层Atomic SW Component的Port上。
- 创建Namespace Package，用来存放Namespace。
- 创建SWC Types，内部创建Software Type Package，用来存放Adaptive Application SW Component Type。
- 创建SW Package，用来存放Adaptive Application SW Component Type实例化生成的Atomic SW Component以及相关Atomic SW Component的连接线。
- 创建另外的SW Package，用来存放Adaptive Application和Executable。
- 创建Software Deployment，用来存放部署的Service Interface、Process及Process的Startup Configuration和序列化生成的Service Interface Element Transformation。
AP软件层结构
对于CP侧需要创建：
- 创建UML Package，用来存放Service和Service Interface。
- 创建SW Package，用来存放Application SW Component Type实例化生成的Atomic SW Component以及相关Atomic SW Component的连接线。
- 创建Software Deployment，用来存放部署的Service Interface。
CP软件层结构
在软件层Root Composition下创建Software Architecture Diagram，将CP与AP的SWC与Port Adapter拖拽到图上。将Service Interface赋予到Port Adapter上，各Service Interface对应的端口会自动显示出来，然后将CP与AP的SWC与Port Adapter连接起来。即实现了CP与AP的SWC的关联，后续可进行信号路由的操作，以实现CP的Atomic SW Component与AP的Atomic SW Component之间通信。
AP&CP软件架构示例
第二步：Library的搭建
对于AP侧需要搭建：
- 创建Software Types，用来存放Machine的State。
- 创建Data Type Package，用于存放数据类型，包括Implementation Data Type、Computation Method、Constants。数据类型关联到Service Interface上。
- 创建Library Package，用于存放硬件层构件的Connector Type和Connection Type。
AP Library结构
对于CP侧需要搭建：
- 创建Software Types，用于存放Application SW Component Type和Sender Receiver Interface/Data element或Client/Server Interface/Operation。然后将Sender Receiver Interface/Data element或Client/Server Interface/Operation赋予给软件层SWC Port上。
- 创建Data Type Package，用于存放数据类型。包括Application Data Type、Implementation Data Type、Computation Method、Base Type、Constants。数据类型关联到Service Interface上。
- 创建Library Package，用于存放硬件层构件的Connector Type和Connection Type。
CP Library结构
第三步：硬件层的搭建
对于AP侧需要创建：
- 创建Component Deployment Package，用于存放Machine Deployment。
- 创建Component Package，用于存放Computer，Process Unit以及Microprocessor。并对硬件及硬件接口赋予相应的Type。
对于CP侧需要创建：
- 创建Component Package，用于存放ECU，Process Unit。并对硬件及硬件接口赋予相应的Type。
硬件层创建完成，形成整车拓扑之后，将软件层的SWC映射到硬件上，即完成软硬件的关联。
硬件架构示例
第四步：信号路由
软硬件Mapping完成之后进行信号路由，生成通信层相关构件，此时，AP端SWC与CP端SWC已经有信号交互。
通讯模型结构
三、打通CP与AP通信链路的优势
基于以上的建模步骤可以看出，基于PREEvision的CP与AP混合建模可解决如下痛点：
- 开发割裂，数据孤岛；
PV→CP与AP模型在同一平台搭建，数据实时同步，避免多工具切换导致的错误；
- 接口不兼容，集成难度大；
PV→内置AUTOSAR标准兼容机制，支持接口自动校验与适配，降低CP与AP集成的难度，减少人工调试成本；
- 需求追溯困难，维护复杂；
PV→解决方案：全流程需求追溯，模型与需求、测试用例深度关联，后期迭代维护时，可快速定位影响范围，提升维护效率；
- 无法协同工作，效率低下；
PV→支持多人在线协同开发，不同角色（硬件工程师、软件工程师、测试工程师）可同时操作同一模型，版本管理清晰，提升团队协同效率；
在汽车向智能化、网联化发展的背景下，PREEvision作为汽车 EE 架构设计的核心工具，凭借跨平台统一建模、单源数据管理、接口映射和多工具链协同能力，成为实现 AUTOSAR CP&AP 混合建模的最佳载体。基于 PREEvision的CP&AP混合建模将成为汽车电子开发的标准模式。
扫一扫
312
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
