下载文档原格式
交通部IC卡技术规范篇一：《城市公共交通IC卡业务及技术应用规范》(征求意见稿)编制说明附件：《城市公共交通IC卡业务及技术应用规范》（征求意见稿）编制说明一、任务来源为贯彻《国务院关于城市优先发展公共交通的指导意见》（国发?2012?64号）精神，落实交通运输部368号文件《交通运输部关于贯彻落实<国务院关于城市优先发展公共交通的指导意见>的实施意见》要求，推进城市公共交通“一卡通”的普及和互联互通，满足社会公众对公共交通的新期待、新要求，提升城市公共交通智能化水平，交通运输部决定组织开展城市公共交通“一卡通”互联互通建设和运营工作，为确保“一卡通”行业长期、稳定、健康发展，特制定《城市公共交通IC卡业务及技术应用规范》（以下简称“本规范”）。
本规范的制订工作于2012年11月正式启动，交通运输部道路运输司牵头组织。
二、目的及意义本规范的制订在于满足城市公共交通IC卡在公共汽电车、轨道交通、出租等公共交通领域的支付需求，并具备向其它小额支付领域的扩展能力，形成统一的指导性规范，保障联网通用。
本规范的制订为完善城市公共交通IC卡支付体系建设，推广普及城市公共交通“一卡通”，加快建设城市公共交通“一卡通”互联互通平台，推进城市公共交通“一卡通”跨市域、跨省域互联互通工作奠定了坚实基础，符合当前优先发展公共交通、转变城市交通发展方式、提升人民群众生活品质、提高政府基本公共服务水平的整体要求，是构建资源节约型、环境友好型社会的战略选择。
三、主要内容本规范包括以下8个部分。
第1部分《总则》：从系统组成、系统功能、性能指标、业务流程、检测标准五个方面总体阐述了城市公共交通IC卡系统要求。
第2部分《公共交通IC卡技术要求》：定义了卡片技术要求及卡片应用技术要求，明确了公共电汽车、出租车、轨道交通、停车场、城际客运、城际铁路、轮渡等应用场景，支持包括圈存、标准扣费、分时分段扣费、脱机预授权、单次扣款优惠等交易。
ICS93.080.30R 84 DB34 安徽省地方标准DB 34/ XXXXX—XXXX 智能交通系统工程检验规范XXXX-XX-XX发布XXXX-XX-XX实施目次前言 (II)1 范围 (1)2 规范性引用文件 (1)3 术语和定义 (1)4 基本要求 (2)5 检验流程及规则 (2)6 检验项目 (2)6.1 道路交通信号控制系统 (2)6.2 闯红灯自动记录系统 (2)6.3 道路车辆智能监测记录系统 (5)6.4 道路交通视频监控系统 (5)6.5 机动车违法停车自动记录系统 (6)6.6 人行横道道路交通安全违法行为监测记录系统 (7)6.7 机动车违法鸣笛抓拍系统 (9)6.8 LED交通信息诱导发放系统 (9)6.9 道路智能限高控制系统 (10)6.10 电气安全性 (11)6.11 控制中心 (11)6.12 施工质量 (11)7 检验方法 (12)7.1 道路交通信号控制系统 (12)7.2 闯红灯自动记录系统 (12)7.3 道路车辆智能监测记录系统 (15)7.4 道路交通视频监控系统 (16)7.5 机动车违法停车自动记录系统 (16)7.6 人行横道道路交通安全违法行为监测记录系统 (17)7.7 机动车违法鸣笛抓拍系统 (18)7.8 LED交通信息诱导发放系统 (19)7.9 道路智能限高控制系统 (19)7.10 电气安全性测试 (19)7.11 控制中心检查 (20)7.12 施工质量检验 (20)附录 (21)前言本文件按照GB/T 1.1-2020《标准化工作导则第1部分：标准化文件的结构和起草规则》的规定起草。
请注意本文件的某些内容可能涉及专利。
本文件的发布机构不承担识别专利的责任。
本文件由安徽省公安厅提出并归口。
本文件起草单位：安徽省计量科学研究院、XXXXXX、XXXXXX、XXXXXX。
本文件起草人：魏元东、XXX、XXX、XXX。
智能交通系统工程检验规范1 范围本文件规定了智能交通系统工程检验规范的术语和定义、基本要求、检验流程及规则、检验项目和检验方法。
ICS xxxxxxJT X xx备案号：JT/T xxxxx—xxxxJT/T xxxxx—xxxx目次前言........................................................................................... I II 引言 (V)1 范围 (1)2 规范性引用文件 (1)3 术语和定义 (2)4 符号和缩略语 (3)5 物理特性 (6)5.1一般特性 (6)5.2尺寸 (6)5.3附加特性 (6)6 射频功率和信号接口 (7)6.1 PICC的初始对话 (7)6.2功率传送 (7)6.3信号接口 (7)6.4 Type A通信信号接口 (8)6.5 Type B通信信号接口 (10)6.6 PICC最小耦合区 (11)7 初始化和防冲突 (12)7.1轮询 (12)7.2 Type A的初始化和防冲突 (12)7.3 Type B的初始化和防冲突 (26)8 传输协议 (39)8.1 Type A PICC的协议激活 (39)8.2 Type B PICC的协议激活 (47)8.3半双工块传输协议 (47)8.4 Type A和Type B PICC的协议停活 (53)9 数据元和命令 (53)9.1关闭非接触通道命令 (53)9.2激活非接触通道命令 (54)附录 A （资料性附录）标准兼容性和表面质量 (56)A.1 标准兼容性 (56)A.2 印刷的表面质量 (56)附录 B （资料性附录）Type A的通信举例 (57)附录 C （规范性附录）CRC_A和CRC_B的编码 (59)C.1 CRC_A编码 (59)C.2 通过标准帧发送的位模式举例 (59)C.3 CRC_B编码 (59)C.4 通过标准帧传送的位模式实例 (60)C.5 用C语言写的CRC计算的代码例子 (60)IJT/T xxxxx—xxxx附录 D （资料性附录）Type A时间槽——初始化和防冲突 (63)D.1 术语和缩略语 (63)D.2 位、字节和帧格式 (63)D.2.1 时序定义 (63)D.2.2 帧格式 (63)D.3 PICC状态 (63)D.4 命令/响应集合 (64)D.5 时间槽防冲突序列 (64)附录 E （资料性附录）Type B——防冲突序列举例 (66)附录 F （资料性附录）使用多激活的举例 (68)附录G （资料性附录）协议说明书 (69)G.1 记法 (69)G.2 无差错操作 (69)G.2.1 块的交换 (69)G.2.2 等待时间扩展请求 (69)G.2.3 DESELECT (69)G.2.4 链接 (70)G.3 差错处理 (70)G.3.1 块的交换 (70)G.3.2 等待时间扩展请求 (71)G.3.3 DESELECT (72)G.3.4 链接 (73)附录H （资料性附录）块和帧编码概览 (75)参考文献 (132)IIJT/T xxxxx—xxxx前言《城市公共交通IC卡业务及技术应用规范》分为8个部分：——第1部分：总则；——第2部分：城市公共交通IC卡技术要求；——第3部分：城市公共交通IC卡读写终端技术要求；——第4部分：业务规则规范；——第5部分：信息技术接口规范；——第6部分：通讯报文接口规范；——第7部分：安全规范（密钥系统）；——第8部分：检测规范。
智能交通系统数据接口规范一、交通违法监测系统接口非现场执法平台作为一个能够容纳各类非现场执法数据的强大的综合性多媒体平台允许异构的非现场执法端口数据接入，从而对这些数据进行前期预处理和后期的信息发布与违法处理。
为保证非现场执法数据的准确性、有效性、合法性，对于异构数据的结构、数据格式和接入接口需要进行一定的采集、储存或转换。
接口定义接口所在地址：http://10.118.141.218:86/接口描述文件：http://10.118.141.218:86/fxczfWebService.ws 接口函数定义函数名说明upLoadRawData 用于上传自动收集违法数据信息upLoadMediaFile 用于上传自动收集违法媒体信息delPTable 用于删除服务器上的收集记录以便重新收集insertPTable 用于往服务器写入新的收集记录ChkPTable 用于从服务器检查是否已收集，防止重复收集GetNextVVehID 用于从服务器获取下一个违法编号getDist 获取地区列表getHpzl 获取号牌种类列表getConMode 获取连接模式getCodePlace 获取所有地点代码列表getDiverDir 获取行驶方向代码列表getCameraDir 获取相机方位代码列表getCamera 获取相机列表getLane 获取车道类型代码列表接口调用流程新增路口的设备组，调用接口上传违法信息主要包括准备过程和上传过程两大步，准备过程和违法上传不直接相关，但这是违法上传前的必须步骤，具体描述如下：准备工作在新增一个路口的设备组时，需要先进行一定量的准备工作，才能开始正式上传数据，它主要又可以分为设备组信息登记、用户注册和保存登记信息三步：1.设备组信息登记中心软件对设备组进行统一管理，需要知道新增设备组的详细信息。
需要通过人工的方式，向中心软件管理员提供新增设备组信息，进行设备组登记。
2.用户注册需要注册一个有上传违法信息权限的有效用户，新增设备组需要保存已登记的详细信息和用户信息。
V2X消息签名和验签流程——应用层安全1.简介为了保证V2X消息的来源可靠性(authenticity)和完整性(integrity)，发送方在发送V2X消息时需要对消息进行签名，当然用于对消息签名的证书是合法的，这也是前提，具体涉及到PKI(Public key infrastructure)系统，这里不做详谈。
接收方接收到V2X消息后首先需要对证书进行验证，进一步利用证书上的公钥对V2X消息的签名进行验证，以保证V2X消息的可靠性和完整性。
2.V2X消息签名流程发送方在发送V2X消息时需要对消息进行签名，签名流程如下图。
在 ITS_SignData 接口函数中，V2X消息（Tbs Data）、签名者信息和签名算法（SM2, ECDSA等）传递给数据处理实体，首先对签名者消息进行编码，然后对编码值进行哈希计算，得到签名者信息的摘要，然后需要把V2X信息和headerInfo进行整合，headerInfo 主要包括PSID, 消息生成时间、地点等，具体的细节可在上一篇中国C-V2X SPDU 格式解读文章查看。
对整合后的消息tbs data进行编码、摘要计算，对tbs data的摘要和证书的摘要进行整合，利用签名者私钥（secure storage 安全储存）对整合值进行签名计算，得到签名值。
对tbs data、签名者信息和签名进行整合、得到Secured Message, 经过编码以及序列化后通过OBU/RSU发送。
3.V2X消息验签流程OBU/RSU 接收到V2X消息后需要对消息进行签名验证，签名验证流程如下图。
在ITS_VerifySignedData 接口函数中,首先对接收到的Secured Message 进行解码，获取签名者信息、tbs data以及签名，然后验证证书是否有效，消息是否为自签、证书是否包含签名者公钥以及V2X消息是否有效，任何一项fail，都会丢弃此消息。
如果此前项都验证通过，下一步开始对签名者消息进行编码摘要计算（图中摘要未写出），得到签名者摘要，进一步进行tbs data摘要值计算，对两个摘要值进行整合，利用证书上的公钥和摘要值对签名进行验签，返回签名验证结果。
数字证书介质接口及使用规范草稿1.范围本规范描述了国家公共资源交易服务平台支持的数字证书介质的各项要求，包括对安全机制、软件要求、硬件指标等要求，用于指导电子认证服务机构在国家公共资源交易服务平台内进行数字证书介质的定制和选型。
本标准遵循GM/T 0027-2014 《智能密码钥匙技术规范》和GM/T 0016-2012 《智能密码钥匙密码应用接口规范》。
2.安全机制2.1.密钥管理数字证书介质的密钥空间必须能够至少保存2对RSA密钥对，2对SM2密钥对和2个对称密钥（包含1个设备认证密钥和1个会话密钥的空间）。
所有密钥必须安全存储。
签名私钥必须在数字证书介质内生成，且不能以任何形式导出。
加密私钥以密文方式导入，且不能以任何形式导出，对称密钥不能以明文倒出。
2.2.数字证书介质中数字证书的安装注册、反注册要求数字证书介质驱动程序安装后，数字证书为RSA算法时，要求介质插入到电脑后，介质内的数字证书自动注册到操作系统的证书存储区，介质从电脑拔出后，介质内的数字证书自动从证书存储区删除。
数字证书为SM2算法时无此要求。
2.3.数字证书介质的扩展区要求数字证书介质内可创建用户私有文件区，对私有文件区操作时，用户应输入介质口令进行验证，扩展区的空间大小不小于64K3.软件要求3.1.数字证书介质接口要求介质接口及数据类型必须遵循国家密码管理局《智能密码钥匙密码应用接口规范》的要求，提供设备管理、访问控制、文件管理和密码服务等相关服务接口。
介质有应用、容器，应用中可有多个容器，容器中可有多个私钥和证书。
介质初始化后，无应用，无容器。
3.1.1.设备管理接口设备管理主要完成介质的插拔事件处理、枚举设备、连接设备、断开连接、获取设备状态、设置设备标签，锁定设备、解锁设备和设备命令传输等操作。
设备管理接口函数如下表所示：3.1.2.访问控制接口访问控制主要完成设备认证、PIN码管理和安全状态管理等操作。
访问控制接口函数如下表所示：3.1.3.应用管理接口应用管理主要完成应用的创建、枚举、删除、打开和关闭等操作。
交通运输行业有了密钥管理安全认证统一平台2013年03月新闻中华人民共和国交通运输部2013-03-08 00:07:40来源: 交通运输部有0人参与日前，国家密码管理局正式发文，交通运输行业密钥管理与安全认证系统通过国家安全性审查，可以正式面向全行业提供密钥和安全认证服务。
这将进一步强化交通运输行业信息化应用领域的系统安全和数据安全，提高交通运输服务和管理中各参与方身份认证的可靠性和可信性，并为不停车收费、公交“一卡通”、车辆和船舶跟踪与认证、物联网应用中的标识识别等提供相关服务。
该系统从全行业应用和服务的角度，整体规划各类业务系统中需要用到的密钥及证书，成为交通运输行业统一的安全认证平台。
联网收费密钥管理及安全认证服务系统收藏本文分享引言本文通过对收费公路密钥管理及安全认证服务系统的功能描述、系统架构与部署、系统软件的设计，建立跨省市联网收费公共数据服务和管理系统，为实现国家高速公路联网电子收费提供安全保证的支持，为实现跨区域联网收费数据的互连互通，为实现跨运营商、跨省域的通行费结算提供数据安全保障。
系统功能密钥管理系统作为高速公路安全支付体系、网络信任体系的基础和核心，是密钥管理与安全认证系统建设的重点。
安全电子支付系统是面向高速公路跨省市区域联网电子收费系统，以用户工C卡和电子标签为电子交易的载体，建立相对完善的跨区域联网电子收费的安全支付体系。
为交通运输部建设全国统一的联网电子收费密钥管理系统，为区域联网电子不停车收费应用示范提供密钥分发管理和收费交易的安全认证服务，确保电联网电子收费系统的交易安全，实现电子收费系统的跨行政区域(运营商)运行。
网络信任系统则通过构建基于PKI技术的信任环境，为高速公路跨区域联网电子收费系统、出行信息服务及路网管理与应急处置系统提供安全、可信、可控、可管的统一支撑环境，为收费公路(交通行业)的网络、应用实体和服务资源等有效解决安全数据传输、身份认证、授权管理和责任认定等问题。
城市公共交通IC卡业务及技术应用规范(征求意见稿)第2ICS xxxxxxxX xx备案号：JT城市公共交通IC卡业务及技术应用规范（征求意见稿）第2部分：公共交通IC卡技术要求The Application Standards of business and technology of City PublicTransportation IC CardPart II：Technical Requirements for Public Transportation IC Card2xxx-xx-xx发布2xxx-xx-x实施XXXXXXXXXXXX发布目次1 范围 (1)2 规范性引用文件 (1)3 术语和定义 (3)3.1 应用application (3)3.2 CAPP记录CAPP records (4)3.3命令command (4)3.4扩展应用专用文件comprehensive application specified file (4)3.5扩展应用循环记录文件comprehensive application cyclic file (4)3.6密文cryptogram (4)3.7押金抵扣deposit deduction (5)3.8电子现金（EC）electronic cash (EC) (5)3.9 电子现金余额 electronic cash balance (5)3.10 电子现金余额上限 electronic cash funds limit (5)3.11 ID号 identify number (5)3.12 集成电路（IC） integrated circuit (IC) 5 3.13 发卡机构行为代码 issuer action code (5)3.14圈存load (6)3.15 支付系统环境 payment system environment6 3.16近距离支付系统环境proximity payment systems environment (6)3.17响应response (6)3.18脱机预授权交易offline pre-authorization.. 7 3.19脱机预授权完成交易offline pre-authorization completion (7)3.20分段扣费section purchase (7)3.21交易终止transaction terminated (7)3.22交易拒绝transaction declined (7)4 符号和缩略语 (8)5 文件、数据元、数据对象列表 (14)5.1文件 (14)5.2数据元 (18)5.3数据对象列表 (18)6 卡片技术要求 (21)6.1功能要求 (21)6.2命令要求 (22)7 卡片应用技术要求 (23)7.1卡片通用要求 (23)7.2应用选择要求 (25)7.3卡片初始应用处理要求 (27)7.4交易时间 (28)8 电子现金双币应用 (28)8.1基于快速城市公共交通IC卡应用的双币电子现金 (28)8.2支持双币电子现金的分时分段扣费流程 (33)8.3基于城市公共交通IC卡应用的双币电子现金369 扩展应用个人化要求 (40)附录 A （规范性附录）应用指令 (42)A.1 APPLICATION BLOCK(应用锁定)命令 (43)A.1.1 定义和范围 (43)A.1.2 命令报文 (44)A.1.3 命令报文的数据域 (44)A.1.4 响应报文的数据域 (44)A.1.5 响应报文返回的处理状态 (44)A.2 APPLICATION UNBLOCK（应用解锁）命令45 A.2.1 定义和范围 (45)A.2.2 命令报文 (45)A.2.3 命令报文的数据域 (45)A.2.4 响应报文的数据域 (45)A.2.5 响应报文返回的处理状态 (45)A.3 CARD BLOCK（卡片锁定）命令 (46)A.3.1 定义和范围 (46)A.3.2 命令报文 (46)A.3.3 命令报文的数据域 (47)A.3.4 响应报文的数据域 (47)A.3.5 响应报文返回的处理状态 (47)A.4 EXTERNAL AUTHENTICATE（外部认证）命令 (47)A.4.1 定义和范围 (47)A.4.2 命令报文 (47)A.4.3 命令报文的数据域 (48)A.4.4 响应报文的数据域 (48)A.4.5 响应报文返回的处理状态 (48)A.5 GENERATE AC（生成应用密文）命令 (49)A.5.1 定义和范围 (49)A.5.2 命令报文 (49)A.5.3 命令报文的数据域 (50)A.5.4 响应报文的数据域 (50)A.5.5 响应报文返回的处理状态 (52)A.6 GET DATA（取数据）命令 (52)A.6.1 定义和范围 (52)A.6.2 命令报文 (54)A.6.3 命令报文的数据域 (54)A.6.4 响应报文的数据域 (54)A.6.5 响应报文返回的处理状态 (54)A.7 GPO（获取处理选项）命令 (54)A.7.1 定义和范围 (55)A.7.2 命令报文 (55)A.7.3 命令报文的数据域 (55)A.7.4 响应报文的数据域 (56)A.7.5 响应报文返回的处理状态 (57)A.8 INTERNAL AUTHENTICATE（内部认证）命令 (57)A.8.1 定义和范围 (57)A.8.2 命令报文 (57)A.8.3 命令报文的数据域 (58)A.8.4 响应报文的数据域 (58)A.8.5 响应报文返回的处理状态 (58)A.9 PIN CHANGE/UNBLOCK（PIN修改/解锁）命令 (58)A.9.1 定义和范围 (58)A.9.2 命令报文 (59)A.9.3 命令报文的数据域 (60)A.9.4 响应报文的数据域 (62)A.9.5 响应报文返回的处理状态 (62)A.10 PUT DATA（设置数据）命令 (62)A.10.1 定义和范围 (62)A.10.2 命令报文 (63)A.10.3 命令报文的数据域 (63)A.10.4 响应报文的数据域 (63)A.10.5 响应报文返回的处理状态 (63)A.11 READ RECORD（读记录）命令 (64)A.11.1 定义和范围 (64)A.11.2 命令报文 (65)A.11.3 命令报文的数据域 (65)A.11.4 响应报文的数据域 (65)A.11.5 响应报文返回的处理状态 (66)A.12 SELECT（选择）命令 (66)A.12.1 定义和范围 (66)A.12.2 命令报文 (66)A.12.3 命令报文数据域 (67)A.12.4 响应报文数据域 (67)A.12.5 响应报文状态字 (69)A.13 UPDATE RECORD（修改记录）命令 (70)A.13.1 定义和范围 (70)A.13.2 命令报文 (70)A.13.3 命令报文的数据域 (70)A.13.4 响应报文的数据域 (71)A.13.5 响应报文返回的处理状态 (71)A.14 VERIFY（验证）命令 (72)A.14.1 定义和范围 (72)A.14.2 命令报文 (72)A.14.3 命令报文的数据域 (73)A.14.4 响应报文的数据域 (73)A.14.5 响应报文中的处理状态 (73)A.15 READ CAPP DATA（读取扩展应用数据）命令 (74)A.15.1 定义和范围 (74)A.15.2 命令报文 (75)A.15.3 命令报文数据域 (75)A.15.4 响应报文数据域 (76)A.15.5 响应报文的状态码 (76)A.16 UPDATE CAPP DATA CACHE(更新数据缓存)命令 (76)A.16.1 定义和范围 (76)A.16.2 命令报文 (78)A.16.3 命令报文数据域 (79)A.16.4 响应报文数据域 (79)A.16.5 响应报文的状态码 (80)A.17 APPEND RECORD(新增记录)命令 (80)A.17.1 定义和范围 (80)A.17.2 命令报文 (81)A.17.3 命令报文数据域 (81)A.17.4 响应报文数据域 (82)A.17.5 响应报文的状态码 (82)A.18 GET TRANS PROVE（取脱机交易应用密文）命令 (82)A.18.1 定义和范围 (82)A.18.2 命令报文 (83)A.18.3 命令报文数据域 (83)A.18.4 响应报文数据域 (83)A.18.5 响应报文的状态码 (83)附录 B （规范性附录）扩展应用文件短文件标识符定义 (85)附录 C （规范性附录）卡片与发卡机构数据元数据元 (86)附录 D （规范性附录）应用数据与文件 (109)D.1 应用数据 (110)D.1.1 联机应用数据 (110)D.1.2 脱机应用数据 (126)D.1.3 非接触式应用数据 (129)D.2 应用文件 (133)D.2.1 支付应用专用文件 (133)D.2.2 扩展应用专用文件 (135)D.2.3 扩展应用循环记录文件 (136)附录 E （资料性附录）交易应用举例 (144)E.1 公共汽电车/轨道交通/停车场/城际客运班车/城际铁路/轮渡应用 (144)E.1.1 出租收费应用 (144)E.1.2 公共汽电车/地铁收费应用 (146)E.1.3 停车咪表应用 (152)E.2 公交日票/月票交易流程说明 (152)E.2.1 公交日票/月票应用 (152)附录 F （规范性附录）支持的密文版本 (157)附录G （规范性附录）算法标识 (158)G.1 公钥算法标识 (158)G.2 哈希算法标识 (159)G.3 发卡行自定义数据（对称密钥算法标识）.. 160 附录H （资料性附录）行业应用开通指南. 161前言《城市公共交通IC卡业务及技术应用规范》分为8个部分：——第1部分：总则；——第2部分：公共交通IC卡技术要求；——第3部分：公共交通IC卡读写终端技术要求；——第4部分：业务规则规范；——第5部分：信息技术接口规范；——第6部分：通讯报文接口规范；——第7部分：安全规范（密钥系统）；——第8部分：检测规范。
国家标准《道路交通管理数据字典 交通信号控制》（征求意见稿）编制说明一、制定标准的目的和意义智能交通系统（ITS）作为多主体、多领域交叉、多应用系统构成的复杂大系统，各应用系统间的互联互通、信息交换与共享，以及在此基础上的数据整合、综合管理与应用，是体现其系统性的必备条件和关键环节。
而要达到上述目的，ITS数据的规范性和标准化是最为关键的技术手段。
其中的核心工作就是制定ITS数据字典。
ITS数据字典是推进ITS领域标准化工作的一个重要组成部分，通过对ITS各个具体应用领域数据的分类表述和管理，为各类交通数据信息广泛地共享与交换提供保障，并将有助于ITS中各类服务和功能的整合。
本标准项目作为ITS应用领域之一的道路交通管理领域数据字典的其中一部分，尽快开展相关工作是非常必要的。
当前我国在ITS数据标准化方面，已经和正在开展中央数据登记薄的数据管理机制以及数据字典要求的相关工作。
这些工作为ITS数据的综合管理和规范化明确了管理机制与具体要求，为下一步开展ITS各个具体应用领域数据字典的编制工作奠定了基础，提供了可能。
道路交通管理领域作为需求迫切并有一定工作基础的ITS应用领域，选择该领域作为我国ITS数据字典编制工作的切入点，是恰当的、可行的。
通过本标准的研究制定，将在很大程度上提升我国ITS数据的管理水平和交通信息资源共享程度，为ITS及其相关产业的发展提供强有力的基础支撑。
同时，本项目作为我国ITS数据字典编制工作的开端，将为后续其它ITS应用领域数据字典的编制提供范例、积累经验。
二、任务来源及简况推荐性国家标准《道路交通管理数据字典 交通信号控制》（以下简称本标准）是国家科技基础条件平台工作重点项目“智能交通系统标准及检测技术”中的一个子课题。
为保证本标准能作为国家标准正式发布，主编单位青岛海信网络科技股份有限公司于2004年上报国家标准计划，并获国家标准化管理委员会批准，国家标准计划号： 本科技基础条件平台工作项目将结合“十五”国家科技攻关项目“ITS关键技术及示范工程”，深入研究我国进入WTO后ITS各应用领域面临的新形势及其标准化需求，制定我国ITS标准化发展规划，研究我国应当优先开展的ITS关键标准，并研究制定我国采用国际及国外ITS标准对策，在“九五”期间制定的ITS标准体系研究的基础上，修订我国ITS标准体系。
国家标准《智能交通数字证书应用接口规范》（征求意见稿）编制说明《智能交通数字证书应用接口规范》标准编制组2017年7月31日目录一、工作简况 (1)二、编制原则和确定主要内容论据 (2)三、主要试验（或验证）的分析、技术经济认证或预期的经济效果 (6)四、与国际、国外同类标准水平的对比情况 (6)五、与有关的现行法律、法规和强制性标准的关系 (6)六、重大分歧意见的处理经过和依据 (6)七、标准作为强制性标准或推荐性标准的建议 (6)八、贯彻标准的要求和措施建议 (7)九、废止现行有关标准的建议 (7)十、其他应予说明的事项 (7)一、工作简况1、任务来源《智能交通数字证书应用接口规范》列入了《2011年国家标准制修订计划》，计划编号20111694-T-469。
通过对智能运输系统深入的研究，对智能运输系统中数字证书应用的安全消息的语法和数字证书应用接口进行了规范，同时对安全消息语法的基本元素格式进行了定义。
本标准由全国智能运输系统标准化技术委员会（SAC/TC 268）提出并归口，标准起草单位是交通运输部公路科学研究院。
2、协作单位标准编制参加单位为北京中交国通智能交通系统技术有限公司、360企业安全集团、恒安嘉新(北京)科技股份公司、国家互联网应急中心、北京信息科技大学。
3、主要工作过程2011年10月~2012年1月，将《智能运输数字证书应用接口规范》标准，作为交通运输部信息化课题《交通运输行业密钥管理与安全认证系统应用研究》的研究成果之一，纳入标准课题研究计划，成立标准编写组。
2012年1月~2012年7月，对国家政策、相关标准进行搜集整理，先后到卫生部、水利部、民航空管局、中科院信息安全国家重点实验室进行专题调研。
2012年8 月~2014年1月，确定标准编制技术方案后，先后在公路网出行报送系统、台湾海峡两岸航运网上行政许可系统、国家干线路网信息系统中进行验证性工作。
2014年1月~2014年6月，编制组起草了标准草稿，并对标准草稿进行详细研究讨论。
2014年7月，完成标准征求意见稿的编写工作，通过网络、发函、会议等方式广泛征求意见。
送达单位有中科院信息工程研究所、国家信息安全技术工程研究中心、全国信息安全标准化技术委员会、国家密码行业标准化技术委员会、山东大学网络信息安全研究所、公安部第一研究所、山西、吉林数字证书认证中心、长春吉大正元信息技术股份有限公司等20余家。
2014年12月，为确保标准先进性，经研究确定在标准原有内容基础上融合合作式智能运输系统和车联网概念，以满足相关内容要求。
2015年1月~2017年6月，与360企业安全集团、恒安嘉新(北京)科技股份公司、国家互联网应急中心、北京信息科技大学成立研究工作组，完成新版标准征求意见稿的编写工作。
4、主要起草人及其所做的工作本标准主要起草人：王笑京、孟春雷、梅新明、周洲、孙婧、王立岩、武俊峰、宋向辉、王龑、郑新华、刘鸿伟、王永建、赵童、吴秋新。
上述同志承担的主要工作如下：——王笑京负责标准编制的组织、协调工作，进行标准需求分析、技术方案确定等工作。
——孟春雷、宋向辉、武俊峰、梅新明，负责数字证书应用接口部分内容编写工作。
——周洲、王龑、郑新华、刘鸿伟、王永建、王立岩、赵童、孙婧、吴秋新负责合作式ITS安全消息语法部分内容编写。
二、编制原则和确定主要内容论据编制组收集了《交通运输信息化“十三五”发展规划》、《信息安全技术信息系统通用安全技术要求》、《信息安全技术公钥基础设施数字证书格式》、《信息安全技术公钥基础设施时间戳规范》、《信息安全技术信息系统安全等级保护基本要求》、《信息安全技术基于互联网电子政务信息安全实施指南》、《信息安全技术公钥基础设施安全支撑平台技术框架》、《基于SM2密码算法的数字证书格式规范》、《证书应用综合服务接口规范》、《时间戳接口规范》等标准。
编制组通过国内专题调研，广泛搜集资料等，对卫生部、水利部、人力资源与社会保障部、民航空管局、中科院信息安全国家重点实验室等单位进行了调研，明确了《智能交通数字证书应用接口规范》的编制内容、技术要求及相关规定。
1、标准编制原则(1)发展性原则标准的制定既要符合我国国情，又要为发展留有充分的余地，以适合国内现状及发展。
(2)先进性原则数字证书系列标准是信息系统信任体系的核心，对于交通运输行业网络信任体系的建设与发展具有至关重要的意义，同时要与我国相关标准协调一致。
(3)延续性原则具有相对的稳定性，在一定的时期内保持标准的延续性。
2、标准的主要内容的说明编制组对于数字证书应用接口的制定进行了充分的调研，收集了国内外有关技术资料、标准文本，分析了国际上智能交通运输相关安全标准的现状、发展趋势及产业化情况，结合中国的技术和标准情况，对面向智能运输系统证书应用的统一服务接口进行了定义，同时定义了ITS设备证书环境下使用SM2密码算法的加密签名消息数据结构。
本标准按照GB/T1.1的格式要求编写。
(1)关于标准名称标准名称“智能交通数字证书应用接口”，定位于智能运输系统中的数字证书应用接口和安全消息语法，适用于智能运输系统中数字证书应用相关的软硬件系统的设计、研发、测试及数字证书认证机构的运行、维护和管理。
(2)规范性引用文件近几年，国家颁布实施了一系列信息安全和密码技术相关的标准，其中非对称加密算法SM2、摘要算法SM3和对称加密算法SM4是支撑加密机制的基础算法，数字证书格式的定义和和应用的规范是本标准引用的依据。
为此确定的规范性引用文件如下：GB/T 16262.1 信息技术抽象语法记法-(ASN.1) 第1部分：基本记法规范GB/T 20518-2006 信息安全技术公钥基础设施数字证书格式GB/T 25069-2010 信息安全技术术语GM/T 0009 SM2密码算法使用规范GM/T 0010 SM2密码算法加密签名消息语法规范GM/T 0015-2012 基于SM2密码算法的数字证书格式规范GM/T 0020-2012 证书应用综合服务接口规范(3)术语和定义针对智能交通数字证书应用接口规范新增定义术语包括：智能运输系统 intelligent transport systems(ITS)。
又称智能交通系统，是在较完善的交通基础设施之上，在先进的信息、通信、计算机、自动控制和系统集成等技术前提下，通过先进的交通信息采集与融合技术，交通对象交互以及智能化交通控制与管理等专有技术，加强载运工具载体和用户之间的联系，提高交通系统的运行效率，减少交通事故，降低环境污染，从而建立一个高效、便捷、安全、环保、舒适的综合交通运输体系。
合作式智能运输系统 cooperative ITS。
通过人、车、路信息交互，实现车辆和基础设施之间（V2I）、车辆与车辆（V2V）、车辆与人（V2P）之间的智能协同与配合的一种智能运输系统体系。
(4)缩略语主要定义包括数字证书应用、密码应用、智能运输系统、编解码相关的缩略语。
ASN.1：抽象语法标记（Abstract Syntax Notation One）CA：认证机构（Certificate Authority）OER：八位字节编码规则（Octet Encoding Rules）CRL：证书撤销列表（Certificate Revocation List）ITS：智能运输系统（Intelligent transport system）OID：对象标识符（Object Identifier）UTC：协调世界时（Coordinated Universal Time）(5)数字证书应用接口本部分定义在合作式智能交通、车联网等应用中，与数字证书相关的数据接口，这些接口包括获取版本号、消息签名与验证、消息加密与解密、消息信封等。
这些接口主要完成基于数字证书的密码应用，是为安全服务的基础。
(6)安全消息语法安全消息语法定义了智能交通系统中安全消息的数据结构，根据安全消息应用场景和系统的不同，划分为传统的安全消息和智能交通专用安全消息。
传统的安全消息可遵照国家现有的相关标准定义使用，如GM/T 0010。
智能交通专用消息时结合传统安全消息的规定，为适应行业特色专门定义的消息结构，这种消息的数据结构更简单，复杂度更低、安全消息加解密的效率更高，更适合在交通无线通信领域中的应用。
智能交通安全消息在结构上划分为协议版本、头部字段、有效负载、尾部字段几部分，在标准中对每部分规定了详细的字段内容。
其中有效负载是承载应用数据的关键部分，应用数据的加解密在这部分中完成，尾部字段是整个消息的数字签名，是确认消息发送主体、判断传输中未被篡改的重要标识。
(7)基本元素格式数据类型组成合作式智能交通系统数据结构的基本元素，这些元素类型在合作式智能交通系统的安全消息中使用。
在本标准中使用ASN.1对数据结构和消息语法进行描述，采用八位字节编码规则(OER)对签名加密消息的各项信息进行编码。
本节主要定义整型、32位时间、64位时间、3D位置、8字节哈希值、3字节哈希值、公钥算法、对称算法、加密密钥、公钥、加密的对称密钥、加密参数、签名者信息、接收者信息、签名等数据类型。
(8)附录合作式ITS安全消息示例本部分提供一个合作式ITS安全消息的示例，给出一个安全消息的数据结构的具体实例，方便标准的使用者能通过这个实例分析安全消息的编码原理，更容易理解正文中的定义。
三、主要试验（或验证）的分析、技术经济认证或预期的经济效果本标准规定了面向智能交通系统证书应用的统一服务接口，定义了签名加密消息的基本元素格式，同时定义了ITS设备证书环境下使用SM2密码算法的加密签名消息数据结构。
本标准的制定，明确了智能交通数字证书应用接口的具体要求，对于密码技术及其相关产业在交通运输领域的落地发展，具有重要的指导意义。
四、与国际、国外同类标准水平的对比情况参照国家密码管理局《通用密码服务接口规范》结合交通运输领域应用情况进一步规范应用。
五、与有关的现行法律、法规和强制性标准的关系遵循《交通运输信息化“十三五”发展规划》，符合交通运输部、工业和信息化部现行有效的政策法规及有关规定，协调好与相关标准的关系。
以适用性、可操作性为目的，进行标准研究和编制。
六、重大分歧意见的处理经过和依据无。
七、标准作为强制性标准或推荐性标准的建议编制组建议本标准制定为推荐性国家标准。
八、贯彻标准的要求和措施建议1、开展标准宣贯培训制定标准尽管重要，也只是标准化工作的基本前提，标准化工作的关键是标准的贯彻实施，离开宣贯，再好的标准也不能产生任何社会和经济效益。
在全国智能运输系统标准化技术委员会的组织协调下，积极开展本标准的宣贯培训，使得业务人员、管理人员和技术人员及时了解、熟悉本标准，提高采标人员的标准应用水平，充分发挥本标准的规范和指导作用。
