NGTP纲要(compendium)续三

4 基础模式：NGTP组件/构造块

       NGTP基础模式包含几个组件/构造块，组件间接口以及详尽的操作。每个组件代表责任和义务的一个归属，它不是一个组织单元。然而一个组织单元可以负责几个组件。

       组件包含其义务的业务逻辑，不考虑任何其他方面。所有的组件都通过定义好的接口和接口的操作来通信。这一章节给出了组件及其相连接口的概览。在第5章节列出了推荐接口及其NGTP操作的详细描述。

 

4.1 TU

4.1.1 简述/概述

TU是一个控制设备，通常安装在车辆里，也可能是导航设备或移动电话的一部分。TU是NGTP后端以外的唯一组件。TU负责建立移动设备和专用调度者(Dispatcher)之间（安全）通信，并与其他移动设备组件交互。用于通信的技术承载器不由NGTP决定。一个TU可以同时和若干承载通信。有时也把TU叫做TCU(telematics control unit)。

 

Figure 6

4.1.2 设计原则

TU的设计原则不多，但设计和开发TU需考虑几个重要因素，TU能够：

l  和Dispatcher建立通信

l  Dispatcher能接受（由TU）建立起的通信

l  向Dispatcher发送信息（数据/声音）

l  从dispatcher接收信息（）

l  处理连接的侦听

l  处理NGTP消息格式

 

4.1.3 相关接口

TU通过接口1(TY <-> DSPT)，可使用任何承载器实现通信。使用承载器的定义不属于NGTP职责。

 

4.2调度者(DSPT)

4.2.1 简述/概述

 调度者是基于NGTP模式的平台内第一个后端设备。它建立了与移动设备的TU直接的通信，并负责通信的稳定性。如果一个通信中断了，调度者(或TU)必须尝试重连到TU（或调度者）。需要规定由哪个组件（TU还是DSPT）负责尝试重连。通常是由通信的发起者负责重连的。

调度者若从TU接收到数据（NGTP消息格式的），它只负责“调度者数据”的编码，并存入服务的有效载荷作为一个NGTP事件。所有此消息相关的后续行为需引用同一事件ID。NGTP消息的结构在5.1.4章节描述。

       针对不同消息类型，调度者能提供不同的通信通道（承载器）。调度者通过接口3从供应数据提供者PDP处获取需要的供应信息。调度者不需要考虑消息的内容，这些是其他组件需要关注的。消息包含的事件信息只能“推给”服务提供者(SH)，如果收到来自接口2的请求。

Figure 7

4.2.2 设计原则

调度者的设计原则如下：

l  调度者只读取和解析消息头以便建立正确的连接。它不关心“服务数据”(见5.1.4章节)。

l  取决于用户用例和其相关消息（编码入消息头的），调度者必须路由这些信息（更精确说：即用于新建或更新事件的触发器）。正确路由的目的地取自PDP。

l  调度者必须能处理声音消息，数据消息和两者的混合体。

l  调度者必须能发送一个事件的触发器到一个及以上的组件。

l  调度者对其他后端组件隐藏了物理通信层。

l  调度者应该能在某事件处理期间改变通信通道（承载器）。

 

4.2.3 相关接口

       调度者通过一些接口与相连接的组件通信

连接组件	接口
Telematics单元(TU)	接口1(TU DSPT)
服务处理器(SH)	接口2(DSPT SH)

 

4.2.4 事件

调度者使用触发器来给诸如服务集成器(SI)或PSAP之类的组件提供新的数据信息。仅NGTP组件有这种能力。NGTP定义了两种触发器：

l  新事件触发器       EventReceived(事件ID)

l  事件更新触发器    EventUpdated(事件ID)

 

新事件触发器通知某一个组件一次全新的事件，事件更新触发器通知所有事件订阅者组件接收到一个已经存在和开放的事件的新信息。

触发器只包含事件ID.需要获取关于事件的更多信息，触发器的接收者必须使用相连接口的操作集合来请求需要的信息。

 

调度者可鞥初始化的触发器如下图所示：

Figure 8

 

举例：

l  如果意外发生了，TU建立一个紧急呼叫eCall，调度者发送一个EventReceived触发器到相关PSAP或呼叫中心（例如包含事件ID的声音）。

l  在已完成初始化的对CC的呼叫过程中，车辆向调度者发送了额外信息。调度者使用EventUpdated触发器以通知呼叫中心已存在事件有新的信息更新。

 

触发器可能经由服务集成器组件，目的是保持与PSAP或CC组件间有清晰的接口。

 

4.3服务处理器(SH)

4.3.1 简述/概述

服务处理器通过操作接收来自调度者的NGTP消息.调度者只是关心进入消息的路由，而服务处理器需考虑进入消息的内容。它对“NGTP服务数据”(见5.1.4)进行解码，并在需要时加入额外的客户或车辆信息。大多数情况下，是由服务集成器SI来处理消息数据，尤其是当用户用例需要若干合作商的集成时。对于传出的消息（传到TU），SH负责把服务数据编码，并推送给调度者..

 

Figure 9

4.3.2 设计原则

服务处理器与客户/车辆数据分离。这种设计使得客户数据的拥有者能在自己的系统内管理数据并能向外为SH提供功能服务。

 

4.3.3 相关接口

服务处理器通过以下接口与相连组件通信：

相连组件	接口
调度者(DSPT)	接口2(DSPT SH)
客户数据提供商(CDP)	接口4(CDP SH
服务集成器(SI)	接口6(SH SI)

 

4.4 服务集成器(SI)

4.4.1 简述/概述

服务集成器作为一个组件，把向客户提供特定服务的所有的合作商集合到一起。服务集成器通过相应接口使合作商– 呼叫中心，内容提供商，等等– 可在一次服务发布内操作而不必开发与相关合作商之间的接口部件。换言之，SI扮演着数据集线器的角色。

例如，服务集成器把来自多个内容提供商的内容信息发送到SH或呼叫中心代理(CCA)。

与调度者和服务处理器一起，服务集成器构建起了NGTP后端的核心。

Figure 10

4.4.2 设计原则

服务集成器不知道TU和DSPT间的通信，也不知道TU专有的参数编码或格式。SI应该使用最先进的IT技术来执行这些接口（例如，不用专有协议，后端设备间不基于语音频带通信）。

 

4.4.3 相关接口

服务集成器通过以下接口与相连组件通信：

连接组件	接口
公共安全应答点(PSAP)	接口5(SI  PSAP)
服务处理器（SI）	接口6(SH  SI)
内容提供商（CP）	接口7(CP  SI)
呼叫中心（CC）	接口8(SI  OS)
其他服务（OS）	专有接口( SI  OS)

 

4.5公共安全应答点PSAP

4.5.1 简述/概述

PSAP代表呼叫中心处理紧急呼叫（eCalls）的专有职责的活动。由于PSAP只负责专有领域，NGTP-PSAP之间可能存在一类调度者，它连接管理TU或PSAP的当前位置的PSAP，在下图中，对任何可能的PSAPs来说，只是一个占位符号。

Figure 11

 

4.5.2设计原则

设计PSAP集成的一个重要方面是考虑完全覆盖的区域需求。在欧洲，从后端到PSAPs的连接需要满足欧洲第三方紧急呼叫支撑服务的需求。如果由TU与PSAP通过in-band技术来直连的需求，这些服务就需要集成到TU组件而不是到后端组件。该实现方式对NGTP没有影响。

实现PSAP集成时，要考虑PSAP需要数据连接来提供附加信息（最小数据集MSD）例如车辆当前信息。若驾驶员已失去意识，ECall由车辆内“意外事件传感器”自动创建，此时建立数据连接是非常重要的。因为这是唯一获取车辆当前位置及行驶方向的途径。

 

4.5.3相关接口

PSAP组件通过以下接口与相接组件通信：

连接组件	接口
服务集成器（SI）	接口5(SI  PSAP)

 

4.6 呼叫中心（CC）

4.6.1 简述/概述

与PSAP类似，呼叫中心需建立声音连接和数据连接。声音连接需要通过CCA对用户提供声讯服务，例如提供附近的药店(POI)信息。数据连接能让CC接受信息，例如用户当前位置，CC也能发送可重用信息到TU，如POI或电话号码。

Figure 12

 

4.6.2 设计原则

除了必须能够使用声音连接和数据连接之外, CC并没用特别的设计原则。有时会有潜在风险，声音连接需要直连DSPT和CC。对接口8来说，NGTP没用给出操作，因为大多数CC具有自己非标准化的，用于提供相关服务的应用。正基于此，无法提供通用的接口和API。然而NGTP提供了接口例子，一个推荐设计，自动映射声音和数据到特定的呼叫（使用事件ID）。

4.6.3 相关接口

呼叫中心通过以下接口和相连组件通信：

连接组件	接口
服务集成器（SI）	接口8（SI  CC）

 

 

4.7 其他服务(OS)

4.7.1 简述/概述

该组件对其他来自任何服务提供商的服务来说只是个占位符，这些提供商可能已与NGTP核心后端相连了。例如，一个旅店通信录服务通过NGTP后端向车辆发送选中旅店的地址POI。

Figure 13

 

4.7.2 设计原则

由于组件/构建块只是个占位符，NGTP没给出任何特别设计原则。

 

4.7.3 相关接口

其他服务提供商OSP组件通过以下接口与相连组件通信：

相连组件	接口
服务集成器(SI)	专有接口 ( SI  OS)

 4.8 供应商数据提供商(PDP)

4.8.1 简述/概述

为保持调度者灵活性和服务独立性，对TU的信息传输规则，或推向NGTP后端的消息，均不是在调度者内部编码的。该信息被动态地保留到PDP，可能依赖于各类参数，比如请求服务类型，TU当前位置，首选的语音等。PDP根据这些参数查找正确的供应商数据并传递给调度者。

Figure 14

 

4.8.2 设计原则

供应商信息取决于几个方面：

       服务类型

       TU当前位置（国界）

       客户使用的语言

       可能（可用）的承载者

在设计PDP接口时需要考虑以上方面。

 

4.8.3相关接口

PDP组件通过以下接口与其他组件通信：

相连组件	接口
调度者（DSPT）	接口3（PDP  DSPT）

 

4.9 客户数据供应商（CDP）

4.9.1 简述/概述

客户数据供应商组件存储所有客户及车辆相关数据，这些数据可鞥与服务有关。通过SH与CDP相分离，OEM可以给外部合作伙伴奉陪SH角色，并始终保持车辆和用户信息对外部不可见。

 

Figure 15

4.9.2 设计原则

有关客户或车辆数据的一个重要方面，服务使用信息与存储信息可能是相互独立的。出于安全的考虑，NGTP只提供发布车辆或客户信息的专有数据的操作，而不是可用数据的完全列表。

NGTP不指定这个数据存储的维护过程。在什么时候，一条新的记录如何被创建的问题，由平台或OEM内部处理。因此CDP没有提供有关插入或更新记录的NGTP操作。

 

4.9.3 相关接口

CDP组件通过以下接口与相连组件通信：

连接组件	接口
服务处理器	接口4（CDP  SH）

 

4.10 内容提供商(CP)

4.10.1 简述/概述

内容提供商为TU或其它服务提供商发布信息咨询。比如，内容可以是专用的POI，天气预报或者所在国家特别的交通规则。

 

Figure 16

CP不仅仅是一个数据库；它也是一个内容调度器。依赖于被请求的内容，CP裁决哪个数据源被用于请求需要的信息。例如，用作天气预报服务的数据源依赖于该区域是否提供天气预报。在欧洲天气预报内容提供商需要请求另外的内容提供商才能获得咨询，而在美国只需要一个提供商即可。

 

Figure 17

4.10.2 设计原则

发布的内容需要按标准化格式提供。

 

4.10.3 相关接口

CP通过以下接口与相连组件通信：

连接组件	接口
服务集成器（SI）	接口7（CP  SI）