DB3311/T 32-2019 视频监控卡口数据传输技术规范

ICS13.310

A91

DB3311

浙江省丽水市地方标准

DB3311/T32—2019

代替DB3311/T32—2014

视频监控卡口数据传输技术规范

2019-12-26发布2020-01-26实施

丽水市市场监督管理局发布

DB3311/T32—2019

目次

前言............................................................................II

1范围.............................................................................1

2规范性引用文件.....................................................................1

3基本要求...........................................................................1

4通信方式...........................................................................1

5消息组成...........................................................................2

5.1消息结构.......................................................................2

5.2消息头.........................................................................2

6协议流程...........................................................................2

7接口协议...........................................................................3

7.1前端认证（平台→设备）.........................................................3

7.2前端认证V2（设备→平台）.......................................................4

7.3心跳保活信号（设备→平台）.....................................................5

7.4发送卡口记录（设备→平台）.....................................................5

7.5发送卡口记录V2（设备→平台）...................................................6

附录A（规范性附录）代码表规范......................................................10

I

DB3311/T32—2019

前言

本标准按照GB/T1.1—2009给出的规则起草。

本标准与DB3311/T32—2014相比主要技术变化如下：

——修改标准名称《治安视频监控卡口数据传输技术规范》为《视频监控卡口数据传输技术规范》；

——“7.5发送卡口记录(设备→平台)”增加发送电警卡口记录接口相关内容；

——“4通信方式”、“5.2消息类型”、“6协议流程”、“7.2前端认证V2(设备→平台)”增

加前端主动注册接口相关内容。

本标准由丽水市公安局提出并归口。

本标准起草单位：丽水市公安局科技信息化局。

本标准起草人：赵日新、诸葛智翔、魏剑新、林智龙、徐经纬、孔维生、吕泓涛。

本标准所代替标准的历次版本发布情况为DB3311/T32—2014《治安视频监控卡口数据传输技术规

范》，本次修订为第一次修订。

II

DB3311/T32—2019

视频监控卡口数据传输技术规范

1范围

本标准规定了视频卡口前端与平台之间的通信方式、消息组成、协议流程和接口协议等技术要求。

本标准适用于视频监控卡口系统的方案设计、系统检测、验收以及与之相关的程序研发。

2规范性引用文件

下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文

件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。

UTF-8信息交换用UTF8编码字符集

3基本要求

3.1数据编号

文档中所用的数据编号（在设备上的数据编号采用8字节UINT64），表示每个前端从1开始计数一直

累加。前端保存的数据编号应不会因为停电或重启后产生重复。

3.2传输规则

协议应使用网络字节序传输数据。字符串数据应使用UTF-8格式编码，传输中的字符串存储格式为C

语言格式，以“\0”结尾。传输中的图片数据应使用JPEG格式。传输中的视频数据应使用MP4格式。设

备应支持数据重传机制。

3.3数据类型

协议中使用的数据类型见表1。

表1数据类型

数据类型描述及要求

8字节，表示从1970年1月1日0时到指定时间所经历的秒数（格林威治时间）。如

time_t

无特殊说明，文档中所用的时间都是time_t类型。

UINT32无符号整型，4字节。

UINT64无符号整型，8字节。

Float浮点型，4字节。

String字符串

4通信方式

1

DB3311/T32—2019

前端与平台间的通讯应采用TCP协议。当前端作为TCPServer时，默认侦听端口为41022。当平台作

为TCPServer时，应支持注册重定向，默认侦听端口为42022，主要适用于前端无固定IP应用场景。前

端与平台连接成功之后，卡口记录、心跳保活等数据应由前端主动发送平台。前端发送短视频数据应与

卡口记录关联匹配。

5消息组成

5.1消息结构

平台发往前端的消息以及前端返回平台的回应采用统一格式，如表2所示。

表2消息结构

消息头整体数据字节数消息体

UINT32UINT32数据长度可变

注：整体数据字节数为消息总的长度（按字节记），包括消息头、整体数据字节数和消息体

5.2消息头

消息头的内容应采用规范表述，如表3所示。

表3消息头内容类型

消息标识说明数据流方向是否需要回复

0xefff0001前端验证平台→前端是

0xefff0002前端向平台反馈包前端→平台否

0xefff0004卡口记录V1前端→平台是

0xefff0005接收数据反馈包平台→前端否

0xefff0007心跳信号前端→平台否

0xefff0008卡口记录V2前端→平台是

0x3fff000a前端验证V2前端→平台是

0x3fff000b平台向前端反馈包平台→前端否

6协议流程

前端与平台之间的协议交互流程如图1所示。

2

DB3311/T32—2019

身份认证

认证结果

身份认证

认证结果

前前平平

端端台台

心跳保活

上传卡口记录

确认结果

图1协议交互流程

7接口协议

7.1前端认证（平台→设备）

平台连接前端时，应携带用户名和验证码进行身份认证。认证包格式见表4，反馈包格式见表5。身

份认证不成功，应返回认证失败消息且断开连接不提供服务。

认证码由前端进行管理，前端应可以配置。

表4认证包格式

平台向前端发出验证包

消息头：

验证0xefff0001

整体数据长度：96字节

消息体：

1Char[44]用户名

数据内容

2Char[44]认证码

3

DB3311/T32—2019

表5反馈包格式

前端向平台反馈包

消息头：

认证状态0xefff0002

整体数据长度：12字节

消息体：

数据内容1UINT320：认证成功、1：用户名错误、2：认证码错误

7.2前端认证V2（设备→平台）

前端连接平台时，应携带通道编号和验证码进行身份认证。认证包格式见表6，反馈包格式见表7。

身份认证不成功，应返回认证失败消息且断开连接不提供服务。

认证码由平台进行管理，平台应可以配置。

表6认证包格式

前端向平台发送验证包

消息头：

验证0xefff000a

整体数据长度：8+结构化信息长度+结构化信息

消息体：

描述名称类型备注

结构化信息长度结构化信息长度Integer说明后面的结构化信息JSON的长度

结构化信息结构化信息StringJSON封装的结构化信息

结构化信息JSON如下，编码格式采用UTF-8。

{

"DeviceID":"通道编号",

"Password":"认证码"

}

表7反馈包格式

平台向前端反馈包

消息头：

认证状态0xefff000b

整体数据长度：8+结构化信息长度+结构化信息

消息体：

描述名称类型备注

结构化信息长度结构化信息长度Integer说明后面的结构化信息JSON的长度

结构化信息结构化信息StringJSON封装的结构化信息

结构化信息JSON如下，编码格式采用UTF-8。

{

"Result":0,//0：认证成功；1：用户名错误；2：认证码错误；3：重定向

"RedirectAddress":"10.33.214.126:42022"

4

DB3311/T32—2019

}

7.3心跳保活信号（设备→平台）

前端在通讯空闲时，应每5秒钟向平台发送一次心跳保活信号，心跳包格式见表8。

如果平台在11秒钟内未收到前端发送的任何信息，应该断开连接，并重新建立连接。平台收到前端

发送的心跳保活信号后，不应回复消息。

表8心跳包格式

前端向平台发送心跳包

消息头：

心跳头0xefff0007

整体数据长度：8字节

7.4发送卡口记录（设备→平台）

前端向平台发送卡口识别数据包见表10。平台向前端发送接收数据反馈包格式见表9。

表9接受数据反馈包

平台向前端反馈接收数据反馈包

消息头：

接收数据成功0xefff0005

整体数据长度：64字节

消息体：

1UINT64数据编号(在设备上的数据编号)

回复接收数据状态：

0入库成功

数据内容2UINT321解析第一步失败

2解析第二步失败

3入库失败

3Char[44]通道编号

5

DB3311/T32—2019

表10识别数据包格式

前端向平台发送卡口识别数据包

消息头：

卡口识别数据头0xefff0004

整体数据长度：8+关于全景图的信息长度+图片数据长度+n*识别数据长度

消息体：

1UINT64图片编号，填默认值填0

2UINT32图片字节数

3UINT32关于图片的识别数据个数n条

关于全景图的

4UINT32图片宽度

信息

5UINT

2图片高度

6Char[48]通道编号

7Char[48]图片存储路径，填默认值”\0”

图片数据1Char[]保存的实际图片

1UINT64数据编号，填默认值0

2UINT64在设备上的数据编号8字节

3time_t过卡口时间8字节

4UINT64关联的图片信息编号，填默认

0

5UINT32过卡口时间毫秒

6float车辆速度单位公里

7UINT32车道号

8float识别精度

9UINT3

方向代码(见附录A.2)

10UINT32车牌类型(见附录A.1)

总数n条识别

11UINT32车牌颜色(见附录A.3)

数据

12UINT32车辆类型(见附录A.7)

13UINT32车辆logo(见附录A.6)

14U

NT32车辆颜色(见附录A.5)

15UINT32车牌结构(见附录A.4)

16UINT32在全景图中的特征图坐标x1如无填99999999

17UINT32在全景图中的特征图坐标y1如无填99999999

18UINT32在全景图中的特征图坐标x2如无填99999999

19UINT32在全景图中的特征图坐标y2如无填99999999

车牌号（“00000000”表示未识别出、行人或非机动车，

20Char[20]

“11111111”表示无牌车）

7.5发送卡口记录V2（设备→平台）

前端向平台发送卡口识别数据包格式见表11。平台向前端反馈接收数据反馈包格式见表13。

6

DB3311/T32—2019

表11识别数据包格式

前端向平台发送卡口识别数据包

消息头：

卡口识别数据头0xefff0008

整体数据长度：8+结构化信息长度+结构化信息+图像数据

消息体：

描述名称类型备注

结构化信息长度结构化信息长度Integer说明后面的结构化信息JSON的长度

结构化信息结构化信息StringJSON封装的结构化信息，见表12

总共N个图像UINT32图

个数。

图像1大小UINT32图像数据的数据长度由图像大小确定。

图像1数据Char[]保存的实际图片

图像2大小UINT32

图像数据

图像2数据Char[]保存的实际图片

…

图像N大小UINT32

图像N数据Char[]保存的实际图片

结构化信息JSON如下，编码格式采用UTF-8。

{

"SeqID":"在设备上的数据编号",

"VehicleInfo":{

"RecordID":"记录唯一ID",

"DeviceID":"通道编号",

"PlateNo":"车牌号码",

"VehicleType":"车辆类型",

"VehicleColor":"车辆颜色",

"Vehi