3. Adaptive应用程序模型与ARXML
在Classic Platform中，我们习惯用SWC、Runnable、Port和Connector来描述一个ECU内部的软件结构；而到了Adaptive Platform，这套模型被彻底重构。Adaptive AUTOSAR不再以“ECU”为部署边界，而是以Machine（机器）和Process（进程）为运行载体，以Adaptive Application（自适应应用）为可执行单元，以Service（服务）为跨进程、跨机器的能力提供与消费方式。理解这三者之间的关系，是读懂ARXML描述和DaVinci工程组织的前提。
一、Adaptive Application：可执行单元与它的组成
一个Adaptive Application在工程上通常对应一个可执行文件（Executable），它由若干Adaptive Application Software Component组成。与Classic SWC不同，Adaptive应用组件不再通过RTE生成静态连接，而是通过ara::com在运行时查找并绑定服务。每个应用组件内部可以包含多个Executable，每个Executable又由若干Runnable构成，但这里的Runnable不再是周期触发的C函数，而是由执行管理（Execution Management, EM）按Manifest中声明的调度策略启动的线程或进程入口。
因此，一个Adaptive Application的ARXML描述至少需要回答四个问题：它叫什么、由哪些可执行实体组成、它需要哪些服务、它向谁暴露能力。这四个问题分别对应Application Manifest中的Application、Executable、Required Service、Provided Service等元素。
二、Service：面向服务的通信契约
Adaptive Platform的核心是SOA。Service不是某个具体进程，而是一份服务接口契约，由Service Interface定义，包含Method、Event、Field三类元素。Method是请求-响应式调用，Event是单向通知，Field则同时具备Getter/Setter和变更通知能力。服务接口本身与部署无关，真正决定“谁提供、谁消费、在哪个网络端点通信”的，是Service Instance和Service Instance Manifest。
在DaVinci中，服务接口通常来自ARXML服务模型文件，可以手工建模，也可以从服务清单（Service Manifest）导入。一个典型的服务实例描述会包含：Service Interface引用、Instance Identifier、提供者进程、消费者进程、以及底层通信绑定（如SOME/IP或DDS的Service ID、Instance ID、端口号、传输协议）。这些参数一旦确定，就决定了运行时ara::com能否成功完成服务发现。
三、Manifest：Adaptive工程的配置中枢
Adaptive AUTOSAR用Manifest来替代Classic的ECU Extract和配置参数集。常见的Manifest包括：
- Application Manifest：描述应用自身的可执行实体、启动参数、所需服务、提供的服务、以及进程级资源约束。
- Service Instance Manifest：描述服务实例的通信绑定、服务发现参数、网络端点、安全策略。
- Machine Manifest：描述一台Machine上的操作系统、网络接口、功能组（Function Group）、进程到功能组的映射、以及EM的调度配置。
- Execution Manifest：描述进程/线程的启动顺序、调度策略、资源组、以及依赖关系。
在DaVinci中，这些Manifest并不是孤立文件，而是通过ARXML引用关系组织成一个工程。一个Application Manifest会引用Service Instance Manifest中的服务实例，Machine Manifest会引用Application Manifest中的进程，Execution Manifest则把进程映射到具体的Function Group和启动状态。理解这些引用链，才能在DaVinci的工程视图中快速定位一个服务为什么找不到、一个进程为什么起不来。
四、DaVinci中的工程组织方式
在DaVinci Configurator或DaVinci Developer中，Adaptive工程通常按项目（Project）→ 包（Package）→ ARXML文件的层级组织。一个典型工程会包含以下ARXML文件：
| ARXML文件 | 主要内容 | 典型引用关系 |
|---|---|---|
| ServiceInterface.arxml | 服务接口、Method、Event、Field定义 | 被Service Instance Manifest引用 |
| ServiceInstance.arxml | 服务实例、通信绑定、SOME/IP参数 | 引用ServiceInterface，被Application Manifest引用 |
| Application.arxml | Adaptive Application、Executable、Runnable | 引用ServiceInstance，被Machine Manifest引用 |
| Machine.arxml | Machine、网络接口、Function Group | 引用Application，被Execution Manifest引用 |
| Execution.arxml | 进程调度、启动顺序、资源组 | 引用Machine和Application |
这些文件之间的引用通过ARXML的REFERENCE元素实现，路径通常形如/PackageName/ElementName。在DaVinci中，如果引用路径写错或目标元素不存在，工具会在校验阶段报出 unresolved reference错误。因此，工程组织的第一原则是：先定义被引用者，再定义引用者。例如，先建ServiceInterface，再建ServiceInstance，最后建Application和Machine。
五、一个可操作的最小示例
假设我们要实现一个“车速服务”：一个进程提供车速Event，另一个进程消费它。在DaVinci中可按以下顺序操作：
- 在ServiceInterface.arxml中新建ServiceInterface，命名为
VehicleSpeedInterface，添加一个Event，命名为SpeedEvent，数据类型为uint16，单位km/h。 - 在ServiceInstance.arxml中新建ServiceInstance，引用
VehicleSpeedInterface，设置Service ID为0x1234，Instance ID为0x0001，传输协议选择SOME/IP，端口设为30501。 - 在Application.arxml中新建两个Adaptive Application：
SpeedProvider和SpeedConsumer。前者Provided Service引用该ServiceInstance，后者Required Service引用同一实例。 - 在Machine.arxml中新建Machine，把两个Application的进程映射到同一个Function Group，例如
Driving。 - 在Execution.arxml中设置
SpeedProvider先启动，SpeedConsumer后启动，调度策略为SCHED_FIFO，优先级分别为20和15。
完成上述配置后，DaVinci会生成对应的ARXML描述文件。运行时，EM根据Execution Manifest启动两个进程，ara::com根据Service Instance Manifest中的Service ID和Instance ID完成服务发现，Provider调用OfferService()，Consumer调用FindService()并绑定Proxy，随后即可通过Event接收车速数据。
总结来看，Adaptive应用程序模型的核心不是“画多少SWC”，而是“定义清楚服务契约、部署参数和启动关系”。ARXML在DaVinci中承担的是结构化描述与引用组织的职责，Manifest则是这些描述在具体Machine和Process上的落地配置。掌握这三层关系，后续学习ara::com、EM、UCM等模块时，才能准确知道每个配置项到底在影响运行时的哪个环节。