1. 文档范围
本文档规定了对AUTOSAR Adaptive平台的通信管理的需求。
2. 使用的约定
AUTOSAR文档中要求的表示形式遵循[TPS_STDT_00078]中指定的表，请参见标准化模板，可追溯性支持一章。
[TPS_STDT_00053]中指定的用于表达义务的口头形式应用于表明需求，请参阅标准化模板的可追溯性支持[1]一章。
3. 缩略词
以下词汇表包含与AUTOSAR词汇表[2]中未包含的AP_RS_CommunicationManagement相关的术语，首字母缩写词和缩写。
Terms: Fully qualified service ID
Description: 一个服务完全合格的名称，用作系统范围内唯一标识符，比如，’com.someOEM.adas.collisionwarner’.
Terms:Data ID
Description: 传输的数据实例的唯一标识符。 如果是事件，这映射到事件的特定实例。
4.需求规范
本章介绍驱动定义通信管理工作的所有需求。
4.1 功能概述
AUTOSAR Adaptive平台通信管理为应用程序之间的网络和协议独立通信提供服务。这份文档包含的需求有：
* 应用程序之间的通信
-通信API的签名
-通信API的行为
-用于classic和adaptive平台上ECU之间和机器之间数据通信的在线协议
* 服务发现
-范围
-服务注册
-ECU之间和机器之间服务发现的在线协议
* 用于通信方面的中间件配置（注册服务）
4.2 功能需求
4.2.1 一般需求
[RS_CM_00001]通信管理应为每个服务提供标准化的头文件结构。
【类型: 草稿
描述: 通信管理应为每个服务提供标准化的头文件结构。该应用程序使用标准化的头文件，而这些头文件与基础的实际的通信管理实现无关。
原理: 应用程序代码对不同的AUTOSAR Adaptive平台实现可重复使用。
依赖: –
用例: 应用程序开发人员根据标准化的头文件实现其代码。
支持材料: –】
[RS_CM_00002] 服务头文件应为对应的服务定义命名空间。
【类型：草稿
描述：服务头文件应为相应服务定义名称空间，以唯一地标识每个服务实例。
原理：该应用程序代码应可用于不同的AUTOSAR Adaptive平台实现和不同的车辆线路。
依赖：–
用例：为了避免和其他的应用程序和其他服务冲突，每个服务应有子集的命名空间。
支持材料：–】
[RS_CM_00003]通信管理应定义如何从建模数据类型派生特定语言的数据类型。
【类型：草稿
描述：通信管理应定义特定语言的数据类型，例如 C ++数据类型，是从建模数据类型派生的。
原理：通信管理应支持不同的语言绑定。
依赖：–
用例：通信管理支持C++语言绑定，因此不得不在c++中定义建模数据类型。
支持材料：–】
4.2.2 面向服务通信
4.2.2.1 应用程序之间的通信
[RS_CM_00200]通信管理应将全合格的服务ID转换成通信协议特定的服务ID
【类型：草稿
描述：通信管理应将全合格的服务ID转换成通信协议特定的服务ID。开发人员在应用程序代码中使用了完全合格的服务ID，需要对其进行定义以启用不同供应商的服务之间的协作。通信协议的特定的服务ID可以在网络上的消息中使用，如果通信协议服务ID空间不是为完全合格的服务ID设计的，则可能需要特定的通信协议服务ID。
原理：应用程序的二进制文件应不知道通信协议特定的服务ID。
依赖：–
用例：多个汽车生产线使用一个平台，但是对于两个汽车生产线，Service ID对平台来说是不一样。通信绑定也是用全合格的服务ID。通信管理将全合格的ID转换成SOME/IP服务ID。
支持材料：见Adaptive平台场景。】
[RS_CM_00204]通信管理应将协议独立的面向服务的通信映射到已配置的协议绑定，并应相应执行协议。
【类型：草稿
描述：通信管理应将协议独立的面向服务的通信映射到已配置的协议绑定，并应相应执行协议。应用程序代码应独立于实际配置的协议使用面向服务的通信。通信管理的责任是实现特定的协议。
原理：应用程序的二进制文件应不知道通信协议特定的服务ID。
依赖：–
用例：多个汽车生产线使用一个应用程序但是在两个汽车生产线上使用的通信协议是不同的。比如：在一个例子中使用SOME/IP，在另一个例子中使用本地IPC。
支持材料：–】
[RS_CM_00315] 通信管理应支持已配置的协议绑定的改变而不需要Adaptive应用程序重新编译。
【类型：草稿
描述：由于特定网络协议绑定的选择是集成商驱动的部署决策，因此特定网络协议绑定选择的任何更改或特定网络协议绑定的各种属性和参数的更改都应是可能的，而无需重新编译涉及的Adaptive应用程序。对所涉及的Adaptive应用程序的要求更改应限于所涉及的Adaptive应用程序的重新链接（静态或动态）。
原理：应用程序的二进制文件不知道具体的配置的协议绑定。具体协议绑定应在应用程序二进制文件的部署时间内可配置/更改。
依赖：–
用例：应用程序的二进制文件应可在各种不同的部署方案中使用。比如在一个部署场景中使用SOME/IP协议绑定，在一些其他的部署场景中使用本地IPC协议。
支持材料：见Adaptive平台场景。】
[RS_CM_00205]通信管理应实现SOME/IP服务发现协议，SOME/IP协议和E2E对AUTOSAR Adaptive平台的通信管理的需求。
2. 使用的约定
AUTOSAR文档中要求的表示形式遵循[TPS_STDT_00078]中指定的表，请参见标准化模板，可追溯性支持一章。
[TPS_STDT_00053]中指定的用于表达义务的口头形式应用于表明需求，请参阅标准化模板的可追溯性支持[1]一章。
3. 缩略词
以下词汇表包含与AUTOSAR词汇表[2]中未包含的AP_RS_CommunicationManagement相关的术语，首字母缩写词和缩写。
Terms: Fully qualified service ID
Description: 一个服务完全合格的名称，用作系统范围内唯一标识符，比如，’com.someOEM.adas.collisionwarner’.
Terms:Data ID
Description: 传输的数据实例的唯一标识符。 如果是事件，这映射到事件的特定实例。
4.需求规范
本章介绍驱动定义通信管理工作的所有需求。
4.1 功能概述
AUTOSAR Adaptive平台通信管理为应用程序之间的网络和协议独立通信提供服务。这份文档包含的需求有：
* 应用程序之间的通信
-通信API的签名
-通信API的行为
-用于classic和adaptive平台上ECU之间和机器之间数据通信的在线协议
* 服务发现
-范围
-服务注册
-ECU之间和机器之间服务发现的在线协议
* 用于通信方面的中间件配置（注册服务）
4.2 功能需求
4.2.1 一般需求
[RS_CM_00001]通信管理应为每个服务提供标准化的头文件结构。
【类型: 草稿
描述: 通信管理应为每个服务提供标准化的头文件结构。该应用程序使用标准化的头文件，而这些头文件与基础的实际的通信管理实现无关。
原理: 应用程序代码对不同的AUTOSAR Adaptive平台实现可重复使用。
依赖: –
用例: 应用程序开发人员根据标准化的头文件实现其代码。
支持材料: –】
[RS_CM_00002] 服务头文件应为对应的服务定义命名空间。
【类型：草稿
描述：服务头文件应为相应服务定义名称空间，以唯一地标识每个服务实例。
原理：该应用程序代码应可用于不同的AUTOSAR Adaptive平台实现和不同的车辆线路。
依赖：–
用例：为了避免和其他的应用程序和其他服务冲突，每个服务应有子集的命名空间。
支持材料：–】
[RS_CM_00003]通信管理应定义如何从建模数据类型派生特定语言的数据类型。
【类型：草稿
描述：通信管理应定义特定语言的数据类型，例如 C ++数据类型，是从建模数据类型派生的。
原理：通信管理应支持不同的语言绑定。
依赖：–
用例：通信管理支持C++语言绑定，因此不得不在c++中定义建模数据类型。
支持材料：–】
