上次我们介绍了AUTOSAR Adaptive概述、服务及服务接口设计以及Adaptive软件设计，很多小伙伴私信直呼不过瘾，这不，就来给大家填坑了~
硬件层设计
AUTOSAR Adaptive主要应用于HPC（High Performance Computer，高性能计算机），PREEvision 9.5版本的硬件层已支持HPC的设计，如下图所示：
1）硬件拓扑的定义：
在该示例中，创建了三个HPC，HPC之间通过以太网进行通信。
2）Machine设计：
在AUTOSAR Adaptive方法论中，AUTOSAR Adaptive软件将运行在Machine上。如前所述，Machine实际上代表的是一种计算资源，在PREEvision中，Machine有三种表现形式：Process Unit，Virtual Machine以及Execution unit。
在该示例中，每个HPC包含一个Machine，其表现形式为Process unit；同时MPU中的多个Core(核)全部分配给了该Machine。
Machine的设计还包括其运行状态的设计，在PREEvision中可通过在Machine下创建状态机进行设计。
软件和硬件的映射
前面初步完成了软件及硬件层的设计，接下来将进行软件和硬件的映射。如前所述，AP软件是运行在Machine上的，所以软/硬件的映射，实际上是将软件层的Adaptive Application SWC与硬件层HPC中的Machine进行映射。
另外，在Adaptive AUTOSAR架构下，程序是动态运行的，Adaptive Application在其部署的Machine上运行时，都是操作系统（比如Linux）中的一个个Process（进程）。在进行软/硬件映射的设计时，可以定义每个process应该运行在的哪些core（核）上以及不能运行在哪些core上。
Machine Deployment
Machine Deployment包含两部分设计内容：Machine Mode以及Service Discovery Configuration
1）Machine Modes设计
Adaptive application在machine上运行时是操作系统中的一个个process（进程），而这些process的启动依赖于Machine的状态（其实就是前面设计machine状态机时的各种simple state，只是这些simple state并不是AUTOSAR中的类，但可以指导后续的Machine Mode设计）。在Adaptive AUTOSAR方法论中，Machine state表示Machine的状态，在最新版规范（R19.11）中，Machine state被Function Group States所取代。Function Group（功能组）表示一组关系紧密的Processes，这些Processes的启动或停止依赖于相同的Function Group State。本示例中，Machine Mode设计如下图所示：
2）Service Discovery Configuration
此处主要是设计服务发现报文的端口号，传输协议及IP地址。在AP里，Machine可以作为一个网络通信节点。
Aplication Deployment
Application Deployment主要是设计Process与Machine状态（前面Machine Deployment已完成Function Group State设计)的Startup dependency(启动依赖关系)，也可以设计Processes之间的Startup dependency。另外，还需为操作系统配置这些process的启动相关参数，如进程调度策略及调度优先级等；
该示例中，各个process配置如下图所示：
Service Instance设计
从软件架构的角度， AUTOSAR Adaptive是一种面向服务的架构（SOA）；从通信角度，AUTOSAR Adaptive系统采用面向服务的通信。Service Instance（服务实例）是服务角色在通信层面的一种实现，分为Provided Service Instance和Consumed Service Instance。在本示例中，采用SOME/IP作为应用层协议，实现面向服务的通信。此处Service Instance的设计，其实主要内容就是进行基于SOME/IP的通信配置。
1）首先需要创建Service Instance（一般借助于PREEvision的信号路由功能，前提是已完成软/硬件的映射设计）。路由之后生成的Service Instances分为两类：Consumed SOME/IP Service Instance和Provided SOME/IP Service Instance。接下来就是完成Service Instance的Service ID及版本等参数的设计。
2）完成网络层及传输层的配置。
3）SOME/IP SD参数配置。分为服务端和客户端。实际上Service Instance的设计与CP的设计类似，此处不再赘述。
综上，在目前的PREEvision 9.5版本中，支持的Adaptive AUTOSAR的设计内容及基本设计流程已介绍完了。
下表显示了目前PREEvision中支持的Adaptive设计内容以及暂不支持的内容。
最后再简单介绍下PREEvision中AUTOSAR Adaptive设计内容的导出。在PREEvision中完成了AUTOSAR Adaptive设计后，可以导出如下文件：
1）Service Interface Description
Service Interface Description可以包含一个或多个服务接口的详细信息，如Method/Event/Property以及对应的数据类型等内容。该文件可以将服务接口信息准确的传递给其他工具，如DaVinci Adaptive IDE，用于生成服务接口的头文件。
2）Execution Manifest
Execution Manifest包含了Adaptive Application部署到目标AUTOSAR Adaptive平台上所需的信息，比如进程启动配置，进程与Machine的映射等内容。
3）Machine Manifest
Machine Manifest包含Machine部署相关的信息，比如网络配置信息，计算资源等。
4）Service Instance Manifest
Service Instance Manifest包含基于服务的通信相关信息，如应用层及相应的传输层、网络层通信参数信息。
当前PREEvision支持AUTOSAR Adaptive导入/导出的版本为R19.03。
以上就是本期介绍的全部内容了。Adaptive AUTOSAR引入了许多新的概念，对目前汽车设计人员的知识面提出了更高的要求。当然，AP的设计肯定需要不同人员及团队的分工协作。在AP的方法论中也提出了OEM、Tier1及Tier2的职责范围，不过在实际项目实施过程中，不一定需要完全按照规范进行分工。
本文只是从PREEvision工具应用的角度，介绍了AP的基本设计流程，有很多细节内容也没有展开，事实上AP中涉及的很多概念都可以作为一个专题进行详细介绍。大家若想了解AP的更多内容，请持续关注我们，期待与大家一起探讨，共同进步。