NGTP纲要(compendium)续四

接续三部分

5 基础模式：NGTP接口

该章节不从技术方面，而从功能方面描述NGTP接口。NGTP工作方式：

l  单向的并且

l  技术无关的

这意味着NGTP不需要使用特别的编程语音，并且与后端使用的具体消息格式无关。除了接口1和接口8意外，所有NGTP接口均是单向的。这样做的原因和好处在3.3小节已经描述了。

在命名惯例上同样如此。操作的名称以提供服务的组件缩略语结尾，例如，所有在接口6里面的操作，在SH和SI中取后缀SH，这是由于是服务处理器SH为服务集尘器SI提供服务。命名规范对NGTP组件同样有效。除了编号以外，接口名还包括相关的NGTP组件，以提供服务的组件开头，到另一个组件。例如，接口6的后缀为“（SHSI）”。

大多数操作需要参数集来传递正确的信息。在操作的描述中，强制参数带下划线。下面列举了所有参数及描述。

参数名

描述

Country

车辆（当前）所在国家；格式：ISO 3166-1(e.g.,”DE”)

EventID

调度器创建的事件唯一标识

Local

语言(按ISO-639编码，e.g. “de”)和可选国家代码扩展(e.g. “de_DE”)

NewServiceType

如果事件的服务类型改变了就新建服务类型（见参数” serviceType”），e.g. ECall转换为Information-Call服务类型

Notification

事件日志文本，任何人均可写日志，例如CC代理商

POI

数据结构，包含POI的经度，纬度，名称等信息

RemoteServiceData

远程服务调用的附加参数

RemoteServiceID

远程服务类型的唯一标识

serviceType

客户需要的服务类型，例如”ECALL”,”ICALL”

svcData

服务数据（NGTP消息的一部分）

UserID

来自CDP的客户唯一标识

VIN(Node ID)

车辆的Vehicle Identification Number(或DriveID)或其他车辆的Node ID。ID唯一标识TU

 

5.1 接口 1（TU DSPT）

5.1.1 简述/概述

接口1能够在NGTP后端与移动的TU间进行无线电？？通信。出于这个目的，接口1使用/提供需要的技术上的承载器。该接口是唯一的双向通信接口。所有调度者和TU之间的消息使用NGTP标准消息格式（见5.1.4小节）。

Figure 18

NGTP推荐消息使用某种数据加密格式，因为接口与所有的网关相连，以实现车辆和后端数据交换。

5.1.2 连接的（组件）块

接口1位于移动设备的TU组件和调度者之间。

5.1.3 操作

由于接口1依赖于使用的网关技术和相关承载器（NGTP是承载独立的），该接口仅有两个高层次的操作。

操作名

操作任务

参数

sendDataDSPT

使用定义好的技术，把消息发往指定TU

EventID

MessageData

receiveDataDSPT

从TU接收数据

EventID

 

5.1.4 NGTP消息格式

NGTP提供预定义消息格式，用作标准化移动设备的TU组件和NGTP后端（接口1）间的通信。这种格式被提出主要是为了移动的连接，而不是局限于NGTP后端之内。NGTP事件在接口6以后不推荐使用这种格式，因为NGTP消息格式被设计用作移动的数据通信。在传统IT后端系统之间，考虑使用其他的消息格式（例如，使用XML）可能更合适。与后端内部安全机制相关，使用被编码信息也可能减慢系统运行速度，而不会带来其他的附加价值。

一个NGTP消息由以下几个部分组成：

1.        NGTP消息头（无编码）【绿色】：

2.        NGTP调度者数据（有编码）【黄色】：

3.        以上部分的签名【橙色】。

4.        NGTP服务数据（有编码）【蓝色】：可选服务类型专有数据

5.        完整消息的签名【橙色】

图20显示了NGTP消息的总体结构，图中同时按列展示了5个消息特点：

l  各个部分的划分所属(Msg Part)

l  属性名

l  属性字节大小（由于数据编码，尺寸可能有出入））

l  定义的属性标识，表征是强制性的（M）还是可选的（O）

l  属性的简述或可能的值

 

 

5.5 接口5 (SI PSAP)

5.5.1 简述/概述

接口5连接PSAP到NGTP后端。要使得体系结构能建立由PSAP处理的ECall，该接口是必须的。当Ecall需要呼叫中心最先处理是，相关PSAP可能被那些有PSAP接口的呼叫中心通知。NGTP不需要PSAP一定与后端直连。而推荐的体系结构能在替换掉呼叫中心的同时，不用改动与PSAPs相关的部分。

 

5.5.2连接的（组件）块

5.5.3 操作

NGTP体系结构推荐被倡导的欧洲ECall标准“第三方紧急呼叫支撑服务 – 操作需求”(EN090316)来实现接口5。服务集成器把所有同事件相关的信息推向最可靠的PSAP，这些信息包括MSD标准专有信息（EN 15722 – 智能传输系统 – 紧急安全 – ‘eCall’最小数据集）。SI也提供PSAP与驾乘人员间的声音通信，至少建立一个电话会议，若任何相关部门需要并被PSAP允许。

另一种可能，欧洲ECall标准建议，与相关PSAP直接建立连接。NGTP系统能识别两种允许的选项。附加的举例描述了符合PAN 欧洲ECall标准的一种ECall方案实施。Pan欧洲ECall是非官方的。以下为针对一些非标准部分的推荐操作：

 

操作名

操作任务

参数

loginSI

参与者认证

Username

Password

tpspLoginInfo ??

SessionID

logoutSI

结束会话

SessionID

pushEmergencyDataSI

初始化：用作表示有发往PSAP的新的/用于更新的数据

SessionID

EventID

requestEmergencyDataSI

向SI请求紧急事件的数据用于PSAP

MSD

cleardownSI

指出PSAP处理完了一个特定事件ID的紧急呼叫

SessionID

EventID

pingSI

检测通信可用性

无

 

5.6接口 6（SH SI）

5.6.1 简述/概述

SH提供一个面向业务的接口，目的是

l  获取事件的数据(比如，接收到NGTP消息的服务数据)

l  完成服务行为，例如终止某个事件

l  访问业务需要的客户和车辆有关数据， 例如，获取车辆外观相关信息，以帮助寻求合适的汽车救援服务。

 

5.6.2 相连的（组件）块

5.6.3 操作

操作名

操作任务

参数

getEventDataSH

取得特定事件的数据

EventID

writeEventLogSH

未事件日志写注释，e.g.出于认证目的。再如，来自呼叫中心代理商CCA的说明，描述ECall被终止的原因。

EventID

Notification

retransmitDataSH

请求车辆重新传输事件数据，比如在数据看起来不太完整或有冲突的情况下。一个可能的原因是连接断开了。

EventID

executeRemoteServiceSH

为车辆触发一个远程服务消息，消息包含着需要车辆完成的功能，比如，关车门。

EventID

VIN

RemoteServiceData

sendPOISH

向某个车辆发送一次POI

EventID

POI

rerouteEventSH

更改事件类型，并根据新的事件类型重新路由到声音服务（另一个CC）。若触发了一个ECall事件，但客户只资讯一些信息，这种情况下，该操作是需要的。

EventID

NewServiceType

terminateEventSH

终止一个活动的事件。该操作同时终止了与事件关联的一次活动的声音呼叫。

EventID

prepareForTerminateSH

有些地方通信双方都必须提交终止行为，需要该操作支持两个阶段的终止过程。该操作提交来自后端的通信终止行为。

EventID

terminateVoiceCallSH

仅终止声音呼叫而不用终止相关的事件，例如，正在进行中的同一事件的数据交换。

EventID

getUserDataSH

通过客户的ID获取完整客户信息

UserID

getVehicleDataSH

获取车辆的附加信息，举例，用于PSAP的车辆颜色和车辆类型。

VIN

getVehiclesOfUserSH

获取用户的车辆信息？？列表。该功能是必须的，比如只知道用户，但PSAP需要获取用户车辆相关信息。

UserID

getDealerDataSH

过去给定车辆经销商信息。

VIN

 

5.7 接口7（CP SI）

5.7.1 简述/概述

接口7使得SI能获取不同类型的内容

l  用于SI发往TU（通过SH和DSPT组件）或

l  推送给另一个服务提供商（OS）

5.7.2 相连的（组件）块

接口7连接SI和CP。SI从CP请求内容，SI不需要知道内容的来源。例如，SI请求某地域的天气预报，而CP决定提供哪个内容数据源给所求的信息。所求内容可能线上或离线获取。通常来说，离线内容存于数据库，必须由额外的系统来管理。典型的离线内容是POIs。大多数情况下在线内容比离线内容更具动态（即时）特性。在线内容有特定的内容提供商实时提供。

Figure 26

5.7.3 操作

由于NGTP不定义给内容提供商提供的内容，没有内容专属的操作。NGTP仅预定义了灵活的操作.

操作名

操作任务

参数

callOperationCP

该操作向CP请求任意的内容，而不用知道内容的源。参数定义了内容类型和一些标准。

productServiceName

version

operationName

parameters

 

参数实例：

productServiceName      定义被请求的服务类型

version                         服务的版本号

operationName              包含被调用的服务功能名称

parameters                    包含被调用的服务功能的复合数据类型

serviceContext                     指定服务上下文环境

 

5.8 接口8（SI CC）

5.8.1 简述/概述

由于该接口依赖于相连接的CC及其提供的服务，可能NGTP操作不得不通过许多私有操作支撑。正如提到的NGTP通信概念的介绍，该接口可能实现为双向接口。原因是，CC与SI间需要大流量的数据交换。由于CC服务在SI内部执行，该接口被看作连各类服务的技术实现接口，这些服务，通过呼叫中心的呼叫管理软件，由SI来提供。因此确定的是，SI不包含呼叫管理软件功能（比如，排队，呼叫平衡等）。

 

5.8.2 相连的（组件）块

接口8连接SI和CC

5.8.3 操作

由于连接的CC组件及其功能没有标准化，NGTP仅为该组件提供一些预定义操作。

操作名

操作任务

参数

informRoutingResultSI

通知SI哪个代理商在处理事件

AgentID

serviceStatusNotificationCC

提供CC服务状态改变信息

notification

getPOICategoryListSI

请求有效POI种类列表（例如：旅店，餐厅或医院）

Language

Country

getPOIListSI

请求POIs信息列表（来自内容提供商CP）

种类

经度/纬度

getPOIAttributeListSI

请求特定POI的附加属性（例如：通讯地址，URL，开业时间或详细描述）

POI-ID

 

5.9 专有接口（SI OS）

5.9.1 简述/概述

由于该接口依赖于相连的服务提供商或提供商提供的某个服务，NGTP没对该接口提供预定义操作。

5.9.2 相连的（组件）块

专有接口在这里仅是一个占位符，用来连接其他服务提供商OS与服务集成器SI。

Figure 28

5.9.3 操作

作为任意可能专有接口的占位符，不可能对其功能进行描述，也无法确定那个操作有用。因此，NGTP不提供任何专有接口操作。在这里能提供唯一有意义的操作是“writeEventLog”调用。

 

6 通用方面

NGTP期望所有符合标准的组件都遵循现代软件工程软件发布系统的规则。包括以下机制

l  避免系统和数据无法重用

l  支持错误跟踪和快速判断出错源头

l  满足整个系统可靠操作

 

在各种环境下，需遵守系统所在的国家地方性法规。

 

6.1 安全性

由于技术独立性，推荐任何，对所有相关系统而言，强制性的安全机制，均不是NGTP的本意。由此，若不同的合作商运行某个组件，他们需要负责双边商定安全容器间的安全通信。

 

NGTP推荐使用“最先进”的技术（如IPsec，SSL，等）来实现安全通信。特别地，以下为相关合作商（组件拥有者）需要执行的不完全条款：

       非授权用户不得获取相关数据（用户及车辆）

       APIs需要对无授权者禁用

       从后端到车辆和相反方向上能发送的消息，必须是已授权的

       消息交换与承载无关

       通过使用在消息格式里使用数字签名保证车辆与后端安全地交换数据。

       防止非法地远程初始化（启动）车辆

下图表明，应在沿3维度“到车辆的，到后端的，以及外部访问组件”考虑安全性因素。

Figure 29 The three security aspects ofNGTP

 

NGTP不会指定或推荐任何的方案必须符合以下方面：

l  消息编码算法

l  授予每个组件或用户各自的信息获取权限

l  后端数据编码算法

l  DSPT与TU的数据交换协议

 

使用应用平台必须遵守所属国家的当地法规。

 

6.2 日志

出于登录和验证的考虑，NGTP只提供推荐而不是指导。然而，NGTP希望看到一个集成的组件的日志和认证功能，能够遵循现代的能容错的软件系统设计原则。

至少希望对以下属性做日志：

       时间戳

       时间ID

在任何情况下，涉密的国家义务也必须遵守（比如,ECall）。

为了对整个系统提供日志功能，NGTP提供了一种方法writeEventLog()，用做所有接口的专用操作。该操作允许为某个事件添加自由文本格式的信息。由相关合作商来制定这种机制如何使用。另外，同样的方法（writeEventLog）也被用作用户验证。若每个组件的所有者负责对自己的数据做日志并在独自的系统中管理这些日志，就需提供方案用于用户验证用例，以为单个事件合并所有数据。

Figure 30 Distributed managed loggingmechanism

一种可能的选择是，所有相关组件一起使用一个共享的日志文件。然而，该方法需要相关合作商来指定，因为目前并无NGTP条款。

Figure 31 Centrally managed logging mechanism

考虑到日志机制，你总需要斟酌：

       是集中日志以便所有组件公用还是使用本地日志？

       事件的验证如何与本地日志一起工作？

       你如何能确保组件间时间戳是一致的？所有组件是使用一个时区的时间吗？

       哪些信息需要日志？

       日志需要存储多长时间？

       只记录数据还是也要记录声音（=> 受制于当地法规）？

 

日志存储的时长由当地法规决定。

 

6.3 监测

通过节约侦测和定位错误的时间，监测系统能显著提高设备利用率。

NGTP希望所有的功能由最先进的分布式系统来完成。特别地，这与以下相关：

l  错误提示探测，

l  适度地监测，

l  诊断深度延伸到能相互交换的单元或能调整的部分。

l  在各种条件下，操作范围划分，包括一些不可预知的操作。

在监测和错误追踪时，NGTP2.0可以，通过设置一个特殊值（参考5.1.4），可以把NGTP消息标记为监控消息。

 

与日志类似，希望所有的NGTP组件都得到监控。一些因素有利于一个更通用，全覆盖的监控。

NGTP希望所有的组件都包含可靠的异常处理机制，即，是异常安全的，并能为关联组件提供所有必要的异常信息。

 

7 开始

主要问题之一：如何开始实施一个基于NGTP的telematics环境。这没有标准答案，因为这依赖于需求及当前的系统。本章推荐一种绿色的实施过程。

1阶段：做计划

。。。

2阶段：构建系统

。。。

3阶段：运营

。。。

8 扩展阅读

本章给出扩展阅读相关资料的列表.

 

阅读参考

描述

URL

Pan European eCall

提供欧洲eCall处理程序的信息

http://www.esafetysupport.org/en/ecall_toolbox/

NGTP 主页

NGTP主页提供所有相关的文档

http://www.ngtp.org

NGTP release process

描述NGTP的发布及变更的过程（管理）

http://www.ngtp.org/...

NGTP 2.0 in a nutshell

NGTP 2.0 概略

http://www.ngtp.org/...

NGTP 2.0示例

示例eCall和下发POI

http://www.ngtp.org/...

 

初稿并没有太多时间来自己审查和勘误，仅供参考；

以后会不定期完善，也欢迎多提意见，交流学习；

[e-mail]