国标《道路交通信息服务浮动车数据编码》的研究与制定

2012-07-25王西点王琪琳常玲

中国质量与标准导报 2012年10期

王西点王琪琳常玲

1 任务来源

由于我国国民经济高速发展和人民生活水平与消费水平的不断提高，城市中的车辆保有量也随之呈几何倍数的增长，尤其是北京、上海、深圳等一线大城市，道路堵塞已经无法避免，再加上某些交通配套设施没能跟上车辆增长的速度，从而造成了交通拥堵的现状。因此智能交通系统（Intelligent Transportation System，简写为ITS）应运而生，智能交通系统就是以缓和道路堵塞和减少交通事故，提高出行者的方便、舒适为目的，利用交通信息系统、通信网络、定位系统和智能化分析与选线的交通系统的总称。

ITS所需的关键数据是交通信息，其可通过多种技术手段采集，其中，浮动车是目前国际ITS领域中一种先进的道路交通信息采集技术，具有应用方便、经济，覆盖范围广的特点。在国内的一些城市也已经有了相关的应用。目前还没有全国的浮动车方面的标准体系，本标准制定的目的是为了将浮动车数据的采集、传输进行规范化，统一各种不同的浮动车系统，更好地服务于智能交通的需要。

推荐性国家标准《道路交通信息服务浮动车数据编码》（以下简称本标准，报批号：GB 20100492-T-469）是质检公益性行业科研专项“交通信息服务系列标准研究”项目中的一个子项目。为保证本标准能作为国家标准正式发布，交通部公路科学研究院于2008年上报国家标准计划，并获国家标准化管理委员会批准。

2 编制过程

任务下达后，编制组依据相关的文件及规定，经过大量的调研，起草了标准征求意见稿及编制说明。

征求意见稿完成后，发21个单位和专家征求意见；收到《征求意见稿》后，回函单位数：16个，并有13家回函单位提出修改建议；没有回函的单位数：5个。在汇总整理专家意见的基础上，完成送审稿。

2011年3月23日召开本标准审定会，与会专家一致通过了对该标准的审查，同时对本标准送审稿提出意见。按照送审稿评审会的要求将标准名称改为《道路交通信息服务浮动车数据编码》。修改后经ITS标委会专家组审查，形成了标准报批稿。

3 编制依据

编制组在编写过程中，充分考虑了和现有标准的协调。对于已有的标准内容，尽量引用。根据标准的性质及类别，主要参考了以下文献资料：

GB／T 1.1—2000《标准化工作导则第1部分：标准的结构和编写规则》；

GB／T 16831—1997《地理点位置的纬度、经度和高度的标准表示法》；

GB／T 20606—2006《智能运输系统数据字典要求》；

GB／T 19056—2003《车载行驶记录仪》。

4 主要技术内容

4.1 标准覆盖范围

浮动车通常是指具有定位和无线通信装置的车辆，浮动车所采集的数据一般包括时间戳、位置坐标、瞬时速度、行驶方向、运行状态及其他内容。浮动车交通信息处理与应用系统在对浮动车运行数据进行分析处理的基础上，实现了实时旅行时间估计和拥堵状态判断、实时交通状况地图展现和查询、实时旅行时间查询、可变情报板旅行时间发布模拟、历史交通信息统计分析和查询等功能。

对于浮动车的概念、数据、应用等方面，业界有不同的理解，本标准的制定需要综合考虑各方面的因素，尽可能符合中国的现状，同时也要考虑未来的发展需要。本标准对于浮动车的界定是具有定位和无线通信装置的“车辆”，对于那些非安装在车辆上的同样具有定位和通信功能的终端不在本标准的考虑范围之内。

4.2 参考模型

4.2.1 浮动车系统的参考模型

浮动车系统的参考模型从概念上给出了各个系统过程及其关系。详见图1。

图1 浮动车系统参考模型

参考模型中各个过程描述如下：

a）车载数据源采集（onboard data source collect）：采集浮动车系统的原始数据。

b）浮动车数据元素生成（probe data element generation）：根据原始数据生成浮动车数据元素。包括以下几种：

——不处理（浮动车数据元素与原始数据是一样的）；

——将原始数据格式化（浮动车数据元素是对原始数据进行计算、转化而得到的结果）；

——对原始数据处理后产生新的数据（对多条原始数据进行处理，可能需要经过一段时间，产生浮动车数据元素，如“检测到交通拥塞”）。

c）浮动车消息生成（probe message generation）：根据浮动车数据元素产生浮动车消息并将其格式化后传输给浮动车数据采集器。这里的“传输”是一个应用层的概念而不是通信层面的。浮动车消息负责在应用层定时发送消息，实际的车辆外的消息传输是由通信层进行的。

d）地面处理中心处理：对浮动车数据包中的数据进行处理，包括接收浮动车数据包并从中解析出相应的浮动车数据、对收集到的数据进行处理（例如：分析、整合等），对浮动车数据处理后的信息进行应用等。

图1中传递的数据描述如下：

a）浮动车数据元素：由原始数据生成的数据条目。

b）浮动车消息：将浮动车数据元素进行封装得到的数据结构。

c）浮动车数据包：通过车载的通信设备传送给地面处理中心的数据块集合。包含：浮动车数据包头和浮动车消息。浮动车数据包由浮动车消息组成，浮动车消息由浮动车数据元素组成。

4.2.2 浮动车数据的参考模型（信息模型）

浮动车数据的参考模型用以描述浮动车数据的初始类别，同时还包含了数据的信息模型。

浮动车数据的参考模型包括多个数据包。图2是浮动车数据参考模型的整体结构。

图2 浮动车数据参考模型

4.3 浮动车数据要求

4.3.1 浮动车数据元素

对于浮动车数据元素的要求如下：

a）每一个浮动车数据元素是通过一组数据描述的，包括所属类别和具体的数值；

b）每一个浮动车数据元素应包含下面的属性：名称、描述、数据类型、格式、单位及精度、有效值。

4.3.2 浮动车消息

对于浮动车消息的要求为：

a）每一条浮动车消息应能够将一系列的浮动车数据元素从浮动车传给地面处理中心；

b）每一条浮动车消息应包含核心数据元素；

4.4 浮动车数据包格式

4.4.1 概述

由浮动车数据元素封装成浮动车消息并组成浮动车数据包的过程如图3所示：

图3 浮动车数据包形成示意图

4.4.2 核心数据元素组格式

核心数据元素是在所有浮动车消息中都必须包含的浮动车数据元素。

其元素组格式如图4所示，各核心数据元素在核心数据元素组中依次传输，数据元素之间以“，”隔开。

图4 核心数据元素组格式

4.4.3 扩展数据元素组格式

扩展数据元素是浮动车消息中，在核心数据元素的基础上，增加的可选浮动车数据元素。

其数据元素组格式如图5所示，各个数据元素之间用“，”隔开，并预留扩展空间。当浮动车与地面处理中心之间协商成功，并在浮动车数据包头中以特定的标识表示，各数据元素的顺序便可根据具体情况定义。整个数据元素组的格式不能改变。

图5 扩展数据元素组格式

4.4.4 数据采集点包格式

数据采集点包将核心数据元素组和扩展数据元素组进行封装，其格式如图6所示，数据采集点包结束标识为“$”，核心数据元素组、扩展数据元素组、数据采集点包结束标识依次排列，中间以“，”隔开。

图6 数据采集点包格式

4.4.5 浮动车消息格式

浮动车消息将多个数据采集点的信息进行封装，通过一条消息进行传输，其格式如图7所示，中间以“，”隔开。

图7 浮动车消息格式

4.4.6 用于通信的浮动车数据包格式

4.4.6.1 浮动车数据包格式总体说明

从通信的角度来看，浮动车数据包的格式见图8。

图8 浮动车数据包格式

4.4.6.2 开始符

开始符（同步字）1个字节，用0X7E表示。

4.4.6.3 包头

4.4.6.3.1 包长度

包长度采用两个字节表示，理论上包长度最大可以是65535个字节。

4.4.6.3.2 版本号

高四位表示版本号，低四位表示分版本号。当前版本号为1.0，用0X10表示。

4.4.6.3.3 应用类型

最高位为1时表示包头中存在目的地址（目的地址表示不同的地面处理中心），否则表示不同的应用分类，浮动车与地面处理中心间应用类型为0X01。

4.4.6.3.4 消息类型

消息类型是预留的字段，其含义可以由厂家进行扩展，当厂家对于扩展数据元素包中的元素顺序或者元素内容进行修改时，可在消息类型中予以标识。

4.4.6.3.5 头部CRC

头部CRC计算包括开始符号、包长度、版本号、应用类型、消息类型、流水号和源地址共11个字节。采用异或运算进行CRC的计算。计算过程如下：通过查找16进制的开始符（0X7E），对头部CRC进行计算和检查，如果不相符合，则认为开始符查找错误，迅速丢弃，重新开始查找0X7E，头部CRC提供快速错误检测功能。若找到开始符（0X7E），根据包长度取到结束符位置判断是否为结束符（0X7F），如果不是则同样迅速丢弃，重新开始查找开始符（0X7E）。

4.4.6.4 包体

包体由一个浮动车消息组成，包括核心数据元素包和扩展数据元素包，由于扩展数据元素包是不确定的，故该部分的长度是可变的。

4.4.6.5 结束符

结束符采用一个字节，用0X7F表示。