1、 ICS 03.220.20 CCS R 80 4501 南宁市地方标准 DB4501/T 0011.32023 城市道路智能交通管理系统 第 3 部分：数据接入 Urban road intelligent traffic management systemPart 3:Data access 2023-07-282023-06-25 发布实施南宁市市场监督管理局发 布 DB4501/T 0011.32023 I 目次 前言.II 引言.III 1 范围.1 2 规范性引用文件.1 3 术语和定义.1 4 缩略语.2 5 接口要求.2 6 接口功能.3 公共功能.3 6.1 采集接口.4 6
2、.2 接口交互安全.5 6.3 7 接口流程.6 注册流程.6 7.1 设备上报流程.7 7.2 平台查询设备信息流程.7 7.3 平台下发指令或数据流程.8 7.4 8 信息安全.9 基本要求.9 8.1 设备身份认证.9 8.2 数据加密.9 8.3 SIP 信令认证.10 8.4 数据完整性保护.10 8.5 访问控制.10 8.6 DB4501/T 0011.32023 II 前言 本文件按照GB/T 1.12020标准化工作导则 第1部分：标准化文件的结构和起草规则的规定起草。本文件是DB4501/T 0011城市道路智能交通管理系统的第3部分，DB4501/T 0011已经发布了以
3、下部分：第 1 部分：总则；第 2 部分：通用要求；第 3 部分：数据接入；第 4 部分：运行维护；第 5 部分：建设、验收及移交。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本文件由南宁市公安局提出、归口并宣贯。本文件起草单位：南宁市公安局交通警察支队、华蓝设计（集团）有限公司、南宁市建筑规划设计集团有限公司。本文件主要起草人：宁志忠、李子龙、吴文皓、唐扬、陈林、黄海、蔡志文、王灏、陈宇、黄雁、潘毅、黄海峰、蒋俊、杨敏、万千、吕柳璇、张婧、彭国庆、叶坷、刘勇、梁启宇。本文件在实施过程中如有建议或疑问，归口单位负责解释及分析处理。意见和建议反馈渠道如下：归口单
4、位（南宁市公安局）：通讯地址：南宁市青秀区厢竹大道46号；联系电话：0771-2891918；电子邮箱：。主要起草单位（南宁市公安局交通警察支队）：通讯地址：南宁市青秀区贤宾路3号；联系电话：0771-2890055；电子邮箱：。DB4501/T 0011.32023 III 引言 为规范南宁市道路智能交通管理系统的建设工作，营造良好的道路交通环境，确保南宁市道路交通运行安全、文明、畅通、有序，制定本文件。根据本文件使用者的不同需求及文件编制目的，本文件由五个部分构成。第 1 部分：总则。确立了城市道路智能交通管理系统建设的总体原则。第 2 部分：通用要求。规定了城市道路智能交通管理系统建设的
5、通用要求。第 3 部分：数据接入。规定了城市道路智能交通管理系统数据接入的相关要求。第 4 部分：运行维护。规定了城市道路智能交通管理系统运行维护的相关要求。第 5 部分：建设、验收及移交。规定了城市道路智能交通管理系统建设、验收及移交管理的相关要求。DB4501/T 0011.32023 1 城市道路智能交通管理系统 第 3 部分：数据接入 1 范围 本文件规定了城市道路智能交通管理系统各子系统的数据接入公安交通管理部门应用平台的接口要求、接口功能、接口流程和信息安全的要求。本文件适用于南宁市城区范围内的城市道路智能交通系统建设，南宁市下属县（市）参照执行。2 规范性引用文件 下列文件中的内
6、容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。GB/T 9387.1 信息技术 开放系统互连 基本参考模型 第1部分：基本模型 GB/T 15126 信息技术 开放系统互连 网络服务定义 GB/T 17547 信息技术 开放系统互连 数据链路服务定义 GB/T 20999 交通信号控制机与上位机间的数据通信协议 GB/T 28181-2016 公共安全视频监控联网系统 信息传输、交换、控制技术要求 GB 35114-2017 公共安全视频监控联网信息安全技术要求 GA/T
7、 497 道路车辆智能监测记录系统通用技术条件 GA 648 交通技术监控信息数据规范 GA/T 832 道路交通安全违法行为图像取证技术规范 GA/T 1049(所有部分)公安交通集成指挥平台通信协议 GA/T 1055 LED道路交通诱导可变信息标志通信协议 GA/T 1400.1 公安视频图像信息应用系统 第1部分：通用技术要求 GA/T 1400.4-2017 公安视频图像信息应用系统 第4部分：接口协议要求 DB4501/T 0011.1 城市道路智能交通管理系统 第1部分：总则 IETF RFC 2616 超文本传输协议（HTTP/1.1）IETF RFC 2617 HTTP认证:
8、基本和摘要访问认证（HTTP Authentication:Basic and Digest Access Authentication）IETF RFC 2818 安全的超文本传输协议（HTTP Over TLS）IETF RFC 3261 会话发起协议（Session Initiation Protocol）IETF RFC 3986 统一资源描述符（URI）IETF RFC 8259 JSON文本格式（The JavaScript Object Notation(JSON)Data Interchange Format）ISO/IEC 21778 信息技术.JSON数据交换语法 3 术语
9、和定义 DB4501/T 0011.1界定的以及下列术语和定义适用于本文件。DB4501/T 0011.32023 2 3.1 公安交通管理部门应用平台（简称“平台”）traffic management application platform for public security 南宁市公安交通管理部门用于公安交通相关指挥、管理工作的集成平台，是集道路交通监测、决策、控制和服务为一体的指挥平台。注：其包含了城市道路智能交通管理系统各子系统（3.4）的后端服务，提供了各子系统对应的前端设备的数据接入接口。3.2 心跳 heartbeat 用于检测网络设备连接状态的周期性消息。3.3 保活
10、keep-alive 通过在固定的时间间隔内发送周期性消息，来确保网络连接和防止超时的机制。3.4 子系统 Subsystem 属于城市道路智能交通管理系统，包括交通视频监视、道路车辆智能监测记录（卡口）、交通信号控制、交通信息发布、交通流量检测、交通技术监控之中某项相对独立功能的系统部分。注：主要由前端设备与后端服务以及相关附属设施所构成。4 缩略语 CMS：可变情报板（Changeable Message Sign）HTTP：超文本传输协议（HyperText Transfer Protocol）HTTPS：安全的超文本传输协议（HyperText Transfer Protocol ov
11、er Secure Socket Layer）JSON：JavaScript 对象标记语言（JavaScript Object Notation）REST：表述性状态转移（Representational State Transfer）SIP：会话初始协议（Session Initiation Protocol）URI：统一资源标识符（Uniform Resource Identifier）WGS：地球坐标系（World Geodetic System）5 接口要求 各子系统的前端设备与平台连接的要求为：5.1 a)通信协议体系结构宜符合 GB/T 9387.1 所定义的基本模型结构；b)物理
12、层宜采用以太网进行传输；c)数据链路层宜采用以太网协议，并应符合 GB/T 17547 的相关要求；d)网络层宜采用 IP 协议，并应符合 GB/T 15126 的相关要求；e)传输层协议与应用层协议的选取应符合各子系统前端设备各自相应的标准。在协议可选的情况下，宜符合表 1 的规定。表1 各子系统与平台对接协议选取列表 序号 子系统 传输层 应用层 平台信令 1 交通信号控制 TCP 二进制协议 二进制协议 DB4501/T 0011.32023 3 表1 各子系统与平台对接协议选取列表（续）序号 子系统 传输层 应用层 平台信令 2 交通视频监视 TCP RTSP、HTTP SIP、RES
13、T 3 道路车辆智能监测记录（卡口）TCP HTTP REST 4 交通流量检测 TCP HTTP REST 5 交通信息发布 UDP 二进制协议 二进制协议 6 交通技术监控 TCP HTTP REST 各子系统的前端设备与平台连接时的接口协议要求为：5.2 f)交通信号控制设备的接口协议应符合 GB/T 20999 的相关规定；g)交通视频监视设备的接口协议应符合 GB/T 28181 的相关规定；h)道路车辆智能监测记录（卡口）设备、交通流量检测设备、交通技术监控设备的接口协议宜符合 GA/T 1400.4、GA/T 832 的规定；i)交通信息发布设备的接口协议宜符合 GA/T 105
14、5 的规定。设备所支持的 HTTP 服务接口应符合 GA/T 1400.1 的规定，定义为 REST 架构下的资源，使用 URI5.3 唯一标识，并按照树状层级结构组织。URI 应符合 IETF RFC 3986 的规定，其树状层级结构不宜超过 5 层，标识长度不宜超过 200 个半5.4 角字符。HTTP 服务接口宜使用 HTTPS 的方法实现，HTTPS 的方法实现应符合 IETF RFC 2818 的规定。在不5.5 使用 HTTPS 的方法实现时，应使用 HTTP 的方法实现，HTTP 的方法实现应符合 IETF RFC 2616 的规定。服务接口应通过 HTTP 的方法（即动作）来实
15、现，HTTP 方法和资源服务的对应关系应符合表 2 的5.6 要求。表2 HTTP 方法和资源服务对应表 HTTP 方法 操作 操作要求 POST 创建资源（Create）POST 方法应用于添加原先不存在的资源，或者全量更新原先已经存在的资源。GET 读取资源（Retrieve）GET 方法调用应不改变系统状态。PUT 更新资源（Update）PUT 方法应用于更新已经存在资源的部分内容。对同一资源内容重复调用 PUT 方法时，应保持结果一致，且不产生副作用。DELETE 删除资源（Delete）DELETE 方法应用于删除已经存在的资源。指定的资源不存在时，应不改变系统状态。服务接口消息体
16、应采用 JSON 格式封装，JSON 格式应符合 ISO/IEC 21778 的规定。HTTP 的5.7 Content-Type 头域应设置为 application/json，应符合 IETF RFC 8259 的规定。HTTP 的 Accept 头域应设置为 application/json，应符合 IETF RFC 8259 的规定。各子系统的后端服务与平台连接时宜符合 GA/T 1049 相关部分的要求。5.8 6 接口功能 公共功能 6.1 DB4501/T 0011.32023 4 6.1.1 各子系统的前端设备应具有设备标识符，且设备标识符应在同一子系统范围内唯一，宜在平台范围
17、内唯一。6.1.2 各子系统的前端设备应支持主动上报数据的功能。宜支持平台主动查询数据后，在设备规定的超时时间内返回结果数据的功能。6.1.3 各子系统的前端设备应支持心跳保活的功能：a)平台与前端设备应统一配置“心跳间隔”参数。前端设备宜按照“心跳间隔”定时向平台发送心跳消息进行保活。前端设备不能按照“心跳间隔”定时向平台发送心跳消息时，平台宜按照“心跳间隔”主动向前端设备查询状态。b)平台与前端设备应统一配置“保活超时次数”。心跳消息连续超时达到“保活超时次数”时，应判断前端设备已下线，平台宜对此发出警示信息。注：心跳间隔可默认为90s。保活超时次数可默认为3次。6.1.4 各子系统的前端
18、设备应支持平台下发指令设置前端设备时间的功能。6.1.5 交通信号控制设备应支持 GA/T 20999 所规定的公共时间参数设置功能。6.1.6 交通信息发布设备应支持 GA/T 1055 所规定的联机请求、联机检测、时间管理功能。6.1.7 交通视频监视设备应支持 GB/T 28181 所规定的注册、注销、保活、校时功能。6.1.8 道路车辆智能监测记录（卡口）设备、交通流量检测设备、交通技术监控设备，应支持 GA/T 1400.4所规定的注册、注销、保活、校时功能。采集接口 6.2 6.2.1 交通信号控制设备 6.2.1.1 应支持 GB/T 20999 所规定的接口功能。6.2.1.2
19、 宜支持平台查询和设置临时方案表的功能。临时方案表应具有 GB/T 20999-2017，B.2.10 方案信息所规定的所有属性，并具有方案是否启用的属性。6.2.2 交通视频监视设备 应支持GB/T 28181所规定的网络设备信息查询、状态信息报送、历史音视频回放功能。6.2.3 道路车辆智能监测记录（卡口）设备 6.2.3.1 应支持主动向平台上报过车数据的功能。过车信息内容应符合 GA 648 的相关规定，并宜符合表 3 的规定。6.2.3.2 宜符合 GA/T 497 所规定的功能要求。6.2.3.3 宜支持平台查询与设置限速配置的功能。6.2.4 交通流量检测设备 6.2.4.1 应
20、支持向平台主动上报过车信息、主动上报交通事件信息的功能。过车信息内容应符合 GA 648的相关规定，并宜符合表 3 的规定。表3 过车信息内容 序号 中文名称 数据类型 数据要求 1 抓拍点经度 浮点数 应使用WGS-84坐标系，精度应达到小数点后4位。2 抓拍点纬度 浮点数 应使用WGS-84坐标系，精度应达到小数点后4位。3 车道号 整数 应使用1位自然数表示，应支持双向8车道。DB4501/T 0011.32023 5 表3 过车信息内容（续）序号 中文名称 数据类型 数据要求 4 车牌号 字符串 应使用UTF-8编码格式，包含中文，可不包含车牌颜色。5 车牌颜色 字符串 宜单独记录车牌
21、颜色，宜使用中文记录车牌颜色。6.2.4.2 应支持向平台主动上报交通流量信息的功能。交通流量信息内容应符合表 4 的规定。表4 交通流量信息内容 序号 中文名称 数据类型 数据要求 1 数据上报时间 字符串 应使用半角20字符日期字符串。格式应为“YYYY-MM-DD HH24:mm:ss”。2 数据统计时长 字符串 应能够通过计算得到统计时长的数值。3 车道号 整数 应支持双向8车道。4 交通量 整数 应使用自然数表示，单位应使用“辆/小时”5 流量值 整数 应使用自然数表示，单位应使用“辆”。6 流率 整数 应使用自然数表示，单位应使用“辆/小时”。7 平均速度 浮点数 精度应达到小数点
22、后1位，单位应使用“千米/小时”。8 交通密度 整数 应能够通过计算得到交通密度的数值。6.2.5 交通信息发布设备 应支持GA/T 1055所规定的接口功能。6.2.6 交通技术监控设备 6.2.6.1 应支持 GA/T 1400.4 所规定的上传自动采集人员、人脸、机动车、非机动车的功能。6.2.6.2 上传信息后，若在一定延迟时间（例如 5s）内未接收到响应，则视为上传失败，应重传。如连续多次（例如 3 次）重传仍未成功，则视为链路发生问题，缓存信息，并重新进行注册。在注册成功后，补传所有未报送数据。6.2.6.3 应支持 GA/T 1400.4-2017，7.2.5 所规定的平台向设备
23、查询设备属性信息的功能。6.2.6.4 应支持平台向设备查询设备采集能力的功能。接口交互安全 6.3 6.3.1 一般要求 6.3.1.1 基于 REST 架构的 HTTP 接口交互安全应符合 GA/T 1400.42017 第 9 章的规定。即消息交互的双方应进行身份认证，认证过程应遵循 IETF RFC 2617 规定的摘要认证，宜遵循 IETF RFC 2818 规定。6.3.1.2 摘要认证时服务器随机数 nonce 超过 3600s 后应重置。6.3.1.3 非 REST 架构的接口交互应在确保网络环境安全的情况下进行。DB4501/T 0011.32023 6 6.3.2 摘要认证
24、 公共功能接口应支持身份认证。其他接口请求方宜向接口提供方进行身份认证，认证过程应遵循IETF RFC 2617规定的摘要认证，宜遵循IETF RFC 2818规定。7 接口流程 注册流程 7.1 7.1.1 基于 REST 架构的注册接口流程见图 1。图1 REST 架构前端设备注册流程图 流程描述如下：a)发起注册请求：设备上电启动后向平台发起 HTTP 注册请求；b)401Unauthorized：平台收到设备请求后发送 401 响应，并在响应的 HTTP 头部携带WWW-Authenticate；c)注册请求WWW-Authenticate：设备收到响应后向平台发起 HTTP 摘要注册
25、请求，并在请求的HTTP 头部携带 Authorization 认证信息；d)注册响应：平台对设备的认证信息进行验证，如果验证出身份合法，则向设备发送注册通过响应。如果身份不合法则发送注册失败响应。7.1.2 非 REST 架构的前端设备注册接口流程见图 2。图2 非 REST 架构前端设备注册流程图 流程描述如下：a)发起注册请求：设备上电后主动向平台发送注册请求的数据帧；设备 平台 发起注册请求 401Unauthorized 注册请求WWW-Authenticate 注册响应 设备 平台 发起注册请求 接口响应 DB4501/T 0011.32023 7 b)接口响应：平台收到设备发送的
26、数据帧后，向设备发送响应。设备上报流程 7.2 7.2.1 基于 REST 架构的前端设备向平台上报数据的接口流程见图 3。图3 REST 架构前端设备上报流程图 流程描述如下：a)发起 HTTP POST 请求：设备检测到事件后主动向平台发起 HTTP POST 请求；b)接口响应：平台收到设备发送的请求后，向设备发送创建数据的接口响应。7.2.2 非 REST 架构的前端设备（例如交通信号控制设备和交通信息发布设备）向平台上报数据的接口流程见图 4。图4 非 REST 架构前端设备上报的流程图 流程描述如下：a)上报数据帧：设备检测到事件后主动向平台发送上报数据的数据帧；b)数据帧响应：平
27、台收到设备发送的数据帧后，向设备发送数据帧响应。平台查询设备信息流程 7.3 7.3.1 平台向基于 REST 架构的前端设备查询信息的接口流程见图 5。设备 平台 发起 HTTP POST 请求 接口响应 设备 平台 上报数据帧 数据帧响应 DB4501/T 0011.32023 8 图5 平台向 REST 架构前端设备查询数据流程图 流程描述如下：a)查询 HTTP GET 请求：平台向设备发起查询数据的 HTTP GET 请求；b)数据响应：设备收到请求后，向平台发送查询的数据。7.3.2 平台向非 REST 架构的前端设备（例如交通信号控制设备和交通信息发布设备）查询数据的接口流程见图
28、 6。图6 平台向非 REST 架构前端设备查询数据流程图 流程描述如下：a)查询数据帧：平台向设备发送查询数据的数据帧；b)数据帧响应：设备收到平台发送的查询数据的数据帧后，向平台发送查询结果的数据帧。平台下发指令或数据流程 7.4 7.4.1 平台向基于 REST 架构的前端设备下发指令或数据的接口流程见图 7。图7 平台向 REST 架构前端设备下发指令或数据流程图 设备 平台 查询 HTTP GET 请求 数据响应 设备 平台 查询数据帧 数据帧响应 设备 平台 下发指令或数据的 HTTP 请求 接口响应 DB4501/T 0011.32023 9 流程描述如下：a)下发指令或数据的
29、HTTP 请求：平台向设备下发指令或数据的 HTTP 请求；b)接口响应：设备收到请求后，向平台发送执行结果。7.4.2 平台向非 REST 架构的前端设备（例如交通信号控制设备和交通信息发布设备）下发指令或数据的接口流程见图 8。图8 平台向非 REST 架构前端设备下发指令或数据流程图 流程描述如下：a)下发指令或数据的数据帧：平台向设备发送指令或数据的数据帧；b)数据帧响应：设备收到平台发送的数据帧后，向平台发送执行结果。8 信息安全 基本要求 8.1 8.1.1 交通视频监视设备的信息安全要求应符合 GB/T 28181 中的规定。8.1.2 应对接入系统的所有设备进行统一的编码,设备
30、编码规范应符合 GB/T 281812016 中 6.1 的规定。8.1.3 采用数字摘要认证时，数字摘要算法应符合 GB 351142017 第 5 章对证书和密钥的要求。设备身份认证 8.2 接入设备认证应根据不同情况采用不同的认证方式：a)对于非标准 SIP 设备,宜通过网关进行认证；b)在低安全级别应用情况下,应采用基于口令的数字摘要认证方式对设备进行身份认证,认证流程应符合 GB/T 281812016 中 9.1.2.1 和 IETF RFC 32612002 的第 22 章；c)在高安全级别应用情况下,应采用基于数字证书的认证方式对设备进行身份认证,认证流程应符合 GB/T 28
31、1812016 中 9.1.2.2 的要求。数据加密 8.3 8.3.1 在高安全级别应用情况下,宜在网络层采用 IPSec 或在传输层采用 TIS 对 SIP 消息实现逐跳安全加密。应用层宜采用 S/MIME 机制的端到端加密，加密方法应符合 IETF RFC 3261 规定。8.3.2 在高安全级别应用情况下,传输过程中与数据存储宜使用国家密码管理行政机构批准的非对称密码算法、对称密码算法和随机数生成算法进行加密，算法应采用获得国家密码管理行政机构批准的安设备 平台 下发指令或数据的数据帧 数据帧响应 DB4501/T 0011.32023 10 全密码产品实现。SIP 信令认证 8.4
32、8.4.1 应对 SIP 信令做数字摘要认证。8.4.2 在 SIP 消息头域中,应启用 Date 域,增加 Note 域。Note=(Digest nonce=,algorithm=),nonce的值为数字摘要经过 BASE64 编码后的值,algorithm 的值为数字摘要的算法名称。8.4.3 当跨域访问时,若该信令是由本域的用户发起,则信令安全路由网关宜将发送到外域的信令添加Monitor-User-Identity 头域,其取值为信令安全路由网关 ID 和用户的身份信息；若该信令不是由本域的用户发起,则应在原有 Monitor-User-Identity 域值前添加信令安全路由网关
33、ID；各段分隔符为“”。用户的身份应为用户 ID 以及用户身份属性信息(用户身份属性信息包括:用户隶属机构属性、用户类别属性和用户职级属性)。数据完整性保护 8.5 8.5.1 联网系统宜采用数字摘要数字时间戳及数字水印等技术防止信息的完整性被破坏,即防止恶意篡改系统数据。8.5.2 交通信号控制设备应采用帧校验序列技术来保证传输信息的数据正确。帧校验序列应符合 GB/T 209992017 中 A.2.2.6 的规定。8.5.3 交通信息发布设备应采用帧校验码技术来保证传输信息的数据正确。帧校验码列应符合 GB/T 10552013 中 5.2 的规定。访问控制 8.6 联网系统应实现统一的用户管理和授权。在身份鉴别的基础上,系统宜采用基于属性或基于角色的访问控制模型对用户进行访问控制。当跨域访问时,宜采用信令Monitor-User-ldentity 携带的用户身份信息进行访问控制。DB4501/T 0011.32023 中华人民共和国南宁市地方标准城市道路智能交通管理系统 第 3 部分：数据接入DB4501/T 0011.32023南宁市市场监督管理局版权专有
