DB11/T ****—
2012
电动汽车远程监控技术规范 第4部分：平台交换协议及数据格式
Technical specifications of remote monitoring for electric vehicles Part4：Protocol specifications and data format of exchange platform
（送审稿）
ICS **.***
北京市质量技术监督局 发布
DB11
目次
目次 (1)
前言 (2)
1 范围 (3)
2 规范性引用文件 (3)
3 术语、定义和缩略语 (3)
4 协议结构 (4)
5 通信连接 (4)
6 数据包结构和定义 (11)
7 数据单元格式和定义 (12)
附录A (17)
前言
本标准按照GB/T1.1-2009给出的规则起草。
本标准由北京市科学技术委员会提出。
本标准由北京市科学技术委员会组织实施。
本标准的主要起草单位：北京交通大学，北京理工大学本标准的参与起草单位：
本标准的主要起草人：
本标准的参与起草人
电动汽车远程监控技术规范
第4部分：平台交换协议及数据格式
1范围
本标准规定了电动汽车监控和服务平台与接入平台间的通信协议，描述了用于平台交换的协议格式和数据要求。
本标准适用于电动汽车监控和服务平台与接入平台间之间的通信。
2规范性引用文件
下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准。凡是不注日期的引用文件，其最新版本适用于本标准。
GB 16735 道路车辆识别代号(VIN)
GB/T 19596电动汽车术语
GB/T 1988 信息技术信息交换用七位编码字符集（eqv ISO/IEC 646）
DB11/Z 801-2011 电动汽车电能供给与保障技术规范动力蓄电池包编码
DB**/* ***-2012 电动汽车远程监控技术规范第1部分：总则
DB**/* ***-2012 电动汽车远程监控技术规范第2部分：车载终端通信协议及数据格式
3术语、定义和缩略语
3.1 术语和定义
GB/T 19596确立的以及下列术语和定义适用于本文件。
3.1.1
监控和服务平台monitoring and service platform
以计算机系统及通信技术为基础，通过移动通信技术和卫星定位技术等手段从车载终端和接入平台获取电动汽车动力蓄电池工作状态和电动汽车运行状态等数据信息，并通过对数据信息的分析和处理，实现电动汽车故障预警、故障处置、车载服务和管理等应用平台。
3.1.2
接入平台access platform
接入到监控和服务平台的平台，包括政府信息资源、社会信息资源和企业信息资源。
3.1.3
用户身份识别user identification
接入平台连接监控和服务平台时，需向监控和服务平台发送数据包进行身份识别。
3.1.4
上行方向upstream direction
从接入平台到监控和服务平台的数据传输方向。
3.1.5
下行方向downstream direction
从监控和服务平台到接入平台的数据传输方向。
3.2 符号及缩略语
IP 网间互联协议（Internet Protocol）
TCP 传输控制协议（Transfer Control Protocol）
HTTP 超文本传送协议（hypertext transport protocol）
WEBSERVICES 传输控制协议在线应用服务
4协议结构
Socket方式
4.1 以TCP/IP网络控制协议作为底层通信承载协议，本标准所规定的协议对应于ISO/OS定义的七层协议结构的应用层。
4.2 应用层以数据包（分组）的格式进行命令和数据的交互，按平台之间数据交互的功能需要规定数据组织结构。
4.3 应用层通信协议不依赖于所选用的传输网络，在基础传输层已经建立的基础上，应用层通信协议与具体传输网络无关。
Webservices方式
4.4 以HTTP协议作为数据传输协议。
5通信连接
Socket方式
5.1连接的建立
5.1.1 当通信链路连接建立，接入平台应立即向监控和服务平台发送信息进行用户身份识别，流程如图1所示。
图1用户身份识别流程示意图
5.1.2 接入平台向监控和服务平台发送用户身份识别信息，监控和服务平台需要对接收到的数据进行校验，校验包括数据校验和用户身份校验。在校验正确的情况下，监控和服务平台返回成功应答；在校验错误的情况下，监控和服务平台返回错误应答。
5.1.3 接入平台在接收到监控和服务平台的应答指令后完成身份识别；接入平台在规定时间内未收到应答指令，应启动重发机制。接入平台如果收到监控和服务平台返回的错误应答，应根据错误应答提示，再次启动重发机制。
5.2 连接的维持
身份识别成功后，接入平台应按一定周期向监控和服务平台发送心跳信息，监控和服务平台在收到心跳信息后返回成功应答，发送周期由接入平台规定。如果想重新建立连接，需要再次进行身份识别。
5.3 连接的过程
连接的过程包括信息数据交换、信息查询、接入平台请求与监控和服务平台控制命令。
5.3.1信息数据交换
由于每个用户的需求和权限不一样，信息数据交换分为三个模式，具体如下。
5.3.1.1接入平台只上报数据给监控和服务平台
身份识别成功后，接入平台应把信息数据按照设定的上报时间周期（T）主动地上报监控和服务平台。流程如图2所示。
图2信息数据上报流程示意图
5.3.1.2监控和服务平台只下发数据给接入平台
如果接入平台需要监控和服务平台下发数据，需要向监控和服务平台进行请求。监控和服务平台对请求进行校验，如果校验正确，监控和服务平台按一定下发时间周期给接入平台下发数据，流程如图3所示。如果检验错误，监控和服务平台返回一个错误应答。接入平台如果没收到应答或收到错误应答，应启动重发机制。流程如图4所示。
图4信息数据下发（错误应答）流程示意图
5.3.1.3 监控和服务平台与接入平台数据交换，同时具有上报和下发功能。
5.3.1.4 进行数据交换时，接收方需要对接收到的信息数据进行校验。如果检验错误，接收方忽略此包的信息数据。
5.3.1.5 进行数据交换时，要求连续完成单体动力蓄电池电压数据转发、动力蓄电池包温度数据转发、整车数据转发、卫星定位系统数据转发、极值数据转发、报警数据转发和充电时动力蓄电池数据转发。
5.3.1.5 信息数据上报时间周期或者下发时间周期应按不同的平台进行调整。当出现报警，监控和服务平台与接入平台之间的周期应该实时的调整，转发时间应缩短到不大于1秒，保证信息的实时性。
5.3.2 信息查询
5.3.2.1 信息查询是监控和服务平台发送查询命令，获取接入平台数据的过程，查询流程如图5所示。
图5信息查询流程示意图
5.3.2.2 监控和服务平台对接入平台发送查询命令，查询命令中参数值均用一个0x00表示，接入平台对接收到的数据进行校验。在校验正确的情况下，接入平台返回成功应答和查询参数值；在校验错误的情况下，接入平台返回错误应答。
5.3.2.3 监控和服务平台收到接入平台的正确应答指令后完成本次信息查询传输。监控和服务平台收到错误应答后重新发送查询命令。监控和服务平台在规定时间内未收到应答指令，启动重发机制。
5.3.3 接入平台请求命令设置与监控和服务平台控制命令设置
5.3.3.1接入平台请求命令设置是接入平台发送请求命令给监控和服务平台，对监控和服务平台进行请求设置的过程，具体设置内容见表18。接入平台请求命令设置流程如图6所示。
图6接入平台请求命令流程示意图图7监控和服务平台控制命令流程示意图
5.3.3.2 监控和服务平台控制命令设置是监控和服务平台发送控制命令给接入平台，请求对接入平台进行控制的过程，具体设置内容见表18。监控和服务平台控制命令设置流程如图7所示。
5.3.3.3 监控和服务平台或接入平台向对方发送命令设置，接收方对接收到的命令信息数据进行校验。在校验正确的情况下，接收方返回成功应答；在校验错误的情况下，接收方返回错误应答。
5.3.3.4 监控和服务平台或接入平台在接收到对方的成功应答后完成自身命令传输；监控和服务平台或接入平台在规定时间内未收到应答指令，发送命令端应启动重发机制。
5.4重发机制
5.4.1 重发超时时间根据具体的通信方式和通信过程自行定义，但不应大于10秒。
5.4.2 达到重发规定次数后仍未收到应答指令，则本次通信失败，结束本次通信。超时重发次数应为3次。
5.5 连接的断开
监控和服务平台与接入平台可根据TCP协议主动断开连接，双方都应主动判断TCP连接是否断开，释放端口。
5.5.1 TCP连接断开
监控和服务平台判断TCP连接断开的方法：
——根据TCP协议判断接入平台主动断开；
——相同身份的接入平台建立新连接，表明原TCP连接已断开；
接入平台判断TCP连接断开的方法：
——根据TCP协议判断监控和服务平台主动断开；
——数据通信链路断开；
5.5.2 TCP连接通畅
当TCP连接通畅的情况下，服务器和接入平台断开连接的情况有：
——数据通信链路正常，达到重发次数后仍未收到应答；
——监控和服务平台超过一定时间未收到接入平台发来的上报信息或心跳信息；
——接入平台超过在一定时间内未收到监控和服务平台发来的下发信息或者心跳信息；Webservices方式
5.6 连接的建立
当通信连接建立，接入平台应立即向监控和服务平台发送信息进行用户身份信息和数据，流程如图8所示。
图8监控和服务平台数据传输流程示意图
5.7 连接的方式
连接的方式包括信息数据交换、信息查询、接入平台请求与监控和服务平台控制命令。
5.3.1信息数据交换
由于每个用户的需求和权限不一样，信息数据交换分为三个模式，具体如下。
5.3.1.1接入平台只上报数据给监控和服务平台
接入平台把信息数据按照设定的上报时间周期（T）主动地上报监控和服务平台。流程如图2所示。
图1信息数据上报流程示意图
5.3.1.2监控和服务平台只下发数据给接入平台
如果接入平台需要监控和服务平台下发数据，需要向监控和服务平台进行请求。监控和服务平台对请求进行校验，如果校验正确，监控和服务平台按一定下发时间周期给接入平台下发数据，流程如图3所示。如果检验错误，监控和服务平台返回一个错误应答。接入平台如果没收到应答或收到错误应答，应启动重发机制。流程如图4所示。
图2信息数据下发（成功应答）流程示意图
图3信息数据下发（错误应答）流程示意图
5.3.1.3 监控和服务平台与接入平台数据交换，同时具有上报和下发功能。
5.3.1.4 进行数据交换时，接收方需要对接收到的信息数据进行校验。如果检验错误，接收方忽略此包的信息数据。
5.3.1.5 进行数据交换时，要求连续完成单体动力蓄电池电压数据转发、动力蓄电池包温度数据转发、整车数据转发、卫星定位系统数据转发、极值数据转发、报警数据转发和充电时动力蓄电池数据转发。
5.3.1.5 信息数据上报时间周期或者下发时间周期应按不同的平台进行调整。当出现报警，监控和服务平台与接入平台之间的周期应该实时的调整，转发时间应缩短到不大于1秒，保证信息的实时性。
5.3.2 信息查询
5.3.2.1 信息查询是监控和服务平台发送查询命令，获取接入平台数据的过程，查询流程如图5所示。
图4信息查询流程示意图
5.3.2.2 监控和服务平台对接入平台发送查询命令，查询命令中参数值均用一个0x00表示，接入平台对接收到的数据进行校验。在校验正确的情况下，接入平台返回成功应答和查询参数值；在校验错误的情况下，接入平台返回错误应答。
5.3.2.3 监控和服务平台收到接入平台的正确应答指令后完成本次信息查询传输。监控和服务平台收到错误应答后重新发送查询命令。监控和服务平台在规定时间内未收到应答指令，启动重发机制。
5.3.3 接入平台请求命令设置与监控和服务平台控制命令设置
5.3.3.1接入平台请求命令设置是接入平台发送请求命令给监控和服务平台，对监控和服务平台进行请求设置的过程，具体设置内容见表18。接入平台请求命令设置流程如图6所示。
图5接入平台请求命令流程示意图图7监控和服务平台控制命令流程示意图
5.3.3.2 监控和服务平台控制命令设置是监控和服务平台发送控制命令给接入平台，请求对接入平台进行控制的过程，具体设置内容见表18。监控和服务平台控制命令设置流程如图7所示。
5.3.3.3 监控和服务平台或接入平台向对方发送命令设置，接收方对接收到的命令信息数据进行校验。在校验正确的情况下，接收方返回成功应答；在校验错误的情况下，接收方返回错误应答。
5.3.3.4 监控和服务平台或接入平台在接收到对方的成功应答后完成自身命令传输；监控和服务平台或接入平台在规定时间内未收到应答指令，发送命令端应启动重发机制。
5.4重发机制
5.4.1 重发超时时间根据具体的通信方式和通信过程自行定义，但不应大于10秒。
5.4.2 达到重发规定次数后仍未收到应答指令，则本次通信失败，结束本次通信。超时重发次数应为3次。
5.5 连接的断开
监控和服务平台与接入平台可根据TCP协议主动断开连接，双方都应主动判断TCP连接是否断开，释放端口。
6数据包结构和定义
6.1 数据说明
6.1.1 数据类型
协议中传输的数据类型见表1所示。
表1数据类型
6.1.2 传输规则
协议采用大端模式（big-endian）的网络字节序来传递字和双字。约定如下：
——字节按照字节流的方式传输；
——字先传递高八位，再传递低八位；
——双字先传递高24位（B31~B24），然后传递高16位（B23~B16），再传递高8位（B15~B8），最后传递低8位（B7~B0）。
6.2 数据包结构
一个完整的数据包应由起始符、命令单元、日期、时间、数据单元长度、数据单元和校验码组成，数据包结构和定义见表2所示。
表2数据包结构和定义
6.3 命令单元
6.3.1 命令标识
命令标识是命令发起方的唯一标识，命令标识定义见表3所示。其中编码0x01到0x06编码已经被《电动汽车远程监控技术规范第2部分：车载终端通信协议及数据格式》占用，详见第2部分表3。
6.3.2 应答标志
作为命令的主动发起方，应答标志为0xFF，此包表示为命令包；若应答标志不为0xFF，被动接收方不应答。作为命令的被动接收方，应答标志表示被动接收方对命令的执行情况，应答标志不为0xFF，此包表示为应答包。在应答包中，不同的执行情况用不同的应答标志进行区分，并将接收到的数据单元返回发起方。如果此为命令包，数据包里的数据单元长度显示0x0000，且数据单元没有字节。
应答标志定义见表4所示。
表4应答标志定义
6.4 日期与时间
日期与时间数据格式具体内容参见《电动汽车远程监控技术规范第2部分：车载终端通信协议及数据格式》6.4-6.5。
7数据单元格式和定义
数据单元按功能的不同分为用户身份识别、信息数据交换、心跳、信息查询、接入平台请求命令与监控和服务平台控制命令设置，数据单元具体说明如下。
7.1 用户身份识别
用户身份识别数据格式和定义见表5所示。
表5用户身份识别数据格式和定义
7.2 信息数据转发
信息数据转发格式和定义见表7所示。
7.2.1信息类型标志
信息类型标志定义见表9所示。
表9信息类型标志定义
7.2.2信息体
信息体按照信息类型的不同分为动力蓄电池放电时电池数据及车辆数据和动力蓄电池充电时电池数据等，具体说明如下。
7.2.2.1动力蓄电池放电时电池数据及车辆数据
动力蓄电池放电时电池数据及车辆数据包括单体蓄电池电压数据、动力蓄电池包温度数据、整车数据、卫星定位系统数据、极值数据、报警数据、用户自定义数据，其格式和定义具体内容参见《电动汽车远程监控技术规范第2部分：车载终端通信协议及数据格式》7.2.2.1-7.2.2.7。
7.2.2.2 动力蓄电池充电时电压数据
动力蓄电池充电时电压数据格式和定义具体内容参见《电动汽车远程监控技术规范第2部分：车载终端通信协议及数据格式》中7.2.2.1。
7.2.2.3 动力蓄电池充电时温度数据
动力蓄电池充电时温度数据格式和定义具体内容参见《电动汽车远程监控技术规范第2部分：车载终端通信协议及数据格式》中7.2.2.2。
7.2.2.4 动力蓄电池充电时极值数据
动力蓄电池充电时极值数据格式和定义见表10所示。
7.2.2.5 动力蓄电池充电时故障数据
动力蓄电池充电时电池故障数据格式和定义见表11所示。
表11电池故障数据格式和定义
7.3 心跳
心跳的数据格式和定义见表12所示。
表12心跳数据格式和定义
7.4 信息转发查询
查询命令的数据格式和定义见表13所示。
7.5 监控和服务平台控制命令设置和接入平台请求命令设置
命令设置的数据格式和定义见表16所示。
表18命令值定义
附录A
（规范性附录）
部分字段定义
动力蓄电池编码定义
动力蓄电池包编码按照DB11/Z 801 5.2定义数据结构。
动力蓄电池包编码定义见表A.1所示。
表A.1动力蓄电池包编码定义
档位状态位定义
表A.2档位状态位定义
━━━━━━━━━━━━
ESK数据交换平台常见业务功能介绍V1.0 一：数据库同步处理 现在的企业正在使用的软件，只要业务量大的，基本上都存在问题，导致问题的主要原因是：数据量大，使用报表分析的频率很高，造成数据库的压力太大,而解决这个问题的一个方法就是：将报表使用的数据库分开，然后将报表使用的数据库与正式的数据库自动同步，同步的方法有很多种，有的难有的易，ESK数据交换平台提供一个解决方案，很简单。 1):首先设置要同步的两个数据库，即设置两个数据源. 2):设置一个数据库模型,模型处理类要选表同步处理.你还可以设置同步的条件，比如从2011/01/01之后的数据才需要同步.为了进行自动增量同步，假如是从A库的A1表同步到B库的A1表，你需要将A1表增加一个时间戳字段. 3):设置一个JOB,并进行调度。让系统按照你的设置自动同步. 二：当作一个简单的ETL抽取工具 现在很多人都在讲数据仓库，多维分析，其实这是同一类型内的概念,BI之所以分析数据快，除了它特殊的存储格式之外,还有一个原因就是它对一些关系型的数据进行了预处理.在不用数据仓库的情 如果我们能就上面的表格建立一个事实表，将每天产生的业务数据，按照某种条件汇总成一条insert,这就是一个进行预处理的过程.如果我们再对这个报表进行数据分析，性能是不是提高了很多.采用这种办法的软件很多，但大多要自已写代码单独进行抽取汇总，而使用ESK数据交换平台就很简单，设置多个数据库传输模型即可. 三：常见的数据导入处理 这种业务是很多的，比如： 1):软件实施前，需要将原来客户使用的系统导入到新的系统里面; 2):公司用了很多软件，但这些软件是数据是不相通的，需要将A软件的数据导到到B软件里面,常见的,业务系统导财务软件. 有的人说，这种情况我写sql也可以，是的，没错，有的情况是可以的,但有的情况使用工具确很简单,比如： 1):我要经常性的导入, 2);从A表到B表，它们的字段差别很大，B表的字段有的可能是固定值，有的是变量，有的是通过某种规则从别的表中取过来的另外一个值，有的数据 是汇总的. 四：与淘宝网，拍拍网的数据同步 现在是一个电子商务的时代，除了以前进行的线下业务之外，线上还有很多新的业务。分销零售行业，这种企业很多。比如我现在所处的鞋服行业，它的店铺就包含了实体店，淘宝店，拍拍店等.传统的行业管理软件基本上不能解决线上店的业务模式，比如（库存同步，分销订单同步）,有的企业为了解决这种需求，一般有两种方案: A:买第三方软件 B:请原来的软件供应商进行二次开发 对于这两种方案都有弊端，对于A,成本高，可能还不支持多仓多店模式，对于B，成本高，时间是一个问题.ESK数据交换平台提供第三种方案，简单的设置一下接口模型，就可以让企业使用的软件和淘宝网，拍拍网进行数据传输.
附件4：数据交换接口规范 一、概述 计量器具检定数据交换接口采用Web service作为数据传输机制，是自包含、自描述（WSDL）、模块化的应用，由省局发布、定位、各技术机构通过web方式调用。接口基于标准的互联网协议，支持超文本传输协议(HTTP)和XML。与省局交换的数据都封装成XML格式的文件，传输前以GZIP格式将文件压缩，然后设置BASE64编码，最后在接收端将其解压，解析读取数据。 二、软件准备 JDK1.6，tomcat6.0，Web service相关包以及数据库。三、数据交换示意图 四、服务端接收数据过程 1、用户合法性校验：服务端在接收数据时同样需要进行用户合法性 校验，并返回信息。
2、数据封装：为方便数据传输和解析，客户端通过Web service交 换的数据需要封装成可扩展标记语言XML的规范，并严格按照此规范。 3、数据压缩：为提高数据的传输效率和减小传输的数据量，客户端 在传输之前需将数据以GZIP格式进行压缩，并设置BASE64位编码，以便基于HTTP传输。 4、对上传文件进行规范性校验：服务端在接收数据之前，校验客户 端数据是否按照XML规范要求，并按GZIP格式进行压缩，设置BASE64编码，否则返回不合法文件格式。 5、返回结果：服务端进行完校验，解析成功并反馈给业务系统后， 会反馈成功信息给客户端，如不成功则返回不成功。 五、客户端接收数据过程（与服务端接收过程类似。） 六、术语说明
THANKS !!! 致力为企业和个人提供合同协议，策划案计划书，学习课件等等 打造全网一站式需求 欢迎您的下载，资料仅供参考
数据交换平台技术规范
目录 前言 (4) 1.引言 (5) 1.1适用范围 (5) 1.2引用的规范文件和有关规定 (5) 1.3术语和定义 (6) 1.4缩略语 (7) 2.系统总体设计要求 (7) 2.1平台介绍 (7) 2.1.1概述 (7) 2.1.2体系架构 (7) 2.1.3系统结构 (9) 2.2功能体系 (9) 2.2.1数据交换 (9) 2.2.2交换节点管理 (10) 2.2.3交换流程管理 (11) 2.2.4系统管理 (11) 2.3技术要求 (12) 2.3.1基本要求 (12) 3.系统性能要求 (13) 3.1开发环境要求 (13) 3.1.1要求描述 (13) 3.1.2性能指标 (13) 3.2平台部署、运行要求 (14) 3.2.1要求描述 (14) 3.2.2性能指标 (15) 3.3数据共享交换服务要求 (15) 3.3.1要求描述 (15) 3.3.2性能指标 (17)
3.4平台扩展性需求 (17) 3.5平台管理模式要求 (18) 3.5.1要求描述 (18) 3.5.3性能要求 (18) 3.6共享交换应用服务要求 (18) 3.5.1要求描述 (19) 3.7对性能的规定 (19) 3.8运行环境适应性要求 (20)
前言 《数据交换平台技术规范》，是根据国家有关规定和国家标准，并且在多年电子政务系统建设和应用经验的基础上，针对信息资源交换平台的功能技术条件编制而成的。 政府各单位可根据本规范为本单位的办公业务系统开发软件接口，实现与数据交换平台无缝对接，从而实现与全市其他单位的系统联网进行电子公文、业务资料、业务信息等各类信息资源的交换。 本规范只给出交换平台的技术约定，不涉及信息资源的管理规定。各单位使用本规约的时候，应注意遵守国家和我省有关法律法规和规章制度。
大数据平台技术要求 1.技术构架需求 采用平台化策略，全面建立先进、安全、可靠、灵活、方便扩展、便于部署、操作简单、易于维护、互联互通、信息共享的软件。 技术构架的基本要求： ?采用多层体系结构，应用软件系统具有相对的独立性，不依赖任何特定的操作系统、特定的数据库系统、特定的中间件应用服务器和特定的硬 件环境，便于系统今后的在不同的系统平台、不同的硬件环境下安装、 部署、升级移植，保证系统具有一定的可伸缩性和可扩展性。 ?实现B（浏览器）/A（应用服务器）/D（数据库服务器）应用模式。 ?采用平台化和构件化技术，实现系统能够根据需要方便地进行扩展。2. 功能指标需求 2.1基础平台 本项目的基础平台包括：元数据管理平台、数据交换平台、应用支撑平台。按照SOA的体系架构，实现对我校数据资源中心的服务化、构件化、定制化管理。 2.1.1元数据管理平台 根据我校的业务需求，制定统一的技术元数据和业务元数据标准，覆盖多种来源统计数据采集、加工、清洗、加载、多维生成、分析利用、发布、归档等各个环节，建立相应的管理维护机制，梳理并加载各种元数据。 具体实施内容包括： ●根据业务特点，制定元数据标准，要满足元数据在口径、分类等方面的 历史变化。 ●支持对元数据的管理，包括：定义、添加、删除、查询和修改等操作，
支持对派生元数据的管理，如派生指标、代码重新组合等，对元数据管 理实行权限控制。 ●通过元数据，实现对各类业务数据的统一管理和利用，包括： ?基础数据管理：建立各类业务数据与元数据的映射关系，实现统一的 数据查询、处理、报表管理。 ?ETL：通过元数据获取ETL规则的描述信息，包括字段映射、数据转 换、数据转换、数据清洗、数据加载规则以及错误处理等。 ?数据仓库：利用元数据实现对数据仓库结构的描述，包括仓库模式、 视图、维、层次结构维度描述、多维查询的描述、立方体（CUBE）的 结构等。 ●元数据版本控制及追溯、操作日志管理。 2.1.2数据交换平台 结合元数据管理模块并完成二次开发，构建统一的数据交换平台。实现统计数据从一套表采集平台，通过数据抽取、清洗和转换等操作，最终加载到数据仓库中，完成整个数据交换过程的配置、管理和监控功能。 具体要求包括： ●支持多种数据格式的数据交换，如关系型数据库：MS-SQLServer、MYSQL、 Oracle、DB2等；文件格式：DBF、Excel、Txt、Cvs等。 ●支持数据交换规则的描述，包括字段映射、数据转换、数据转换、数据 清洗、数据加载规则以及错误处理等。 ●支持数据交换任务的发布与执行监控，如任务的执行计划制定、定期执 行、人工执行、结果反馈、异常监控。 ●支持增量抽取的处理方式，增量加载的处理方式； ●支持元数据的管理，能提供动态的影响分析，能与前端报表系统结合， 分析报表到业务系统的血缘分析关系； ●具有灵活的可编程性、模块化的设计能力，数据处理流程，客户自定义 脚本和函数等具备可重用性； ●支持断点续传及异常数据审核、回滚等交换机制。
数据交换平台方案2(总18 页) -CAL-FENGHAI.-(YICAI)-Company One1 -CAL-本页仅作为文档封面，使用请直接删除
目录 第一章概述..................................... 错误!未指定书签。 1.1建设背景 .................................. 错误!未指定书签。 1.2应用场景 .................................. 错误!未指定书签。第二章必要性、可行性及效益分析................. 错误!未指定书签。 2.1必要性分析 ................................ 错误!未指定书签。 2.2可行性分析 ................................ 错误!未指定书签。 2.3效益分析 .................................. 错误!未指定书签。第三章建设目标、思路及原则..................... 错误!未指定书签。 3.1建设目标 .................................. 错误!未指定书签。 3.2建设思路 .................................. 错误!未指定书签。 3.3建设原则 .................................. 错误!未指定书签。第四章关键问题解析............................. 错误!未指定书签。 4.1面临的几个重要问题........................ 错误!未指定书签。 4.2数据交换平台与业务应用的关系.............. 错误!未指定书签。第五章总体设计................................. 错误!未指定书签。 5.1总体结构 .................................. 错误!未指定书签。 5.2系统逻辑结构 .............................. 错误!未指定书签。 5.3系统技术架构 .............................. 错误!未指定书签。 5.4系统物理结构 .............................. 错误!未指定书签。第六章数据交换平台功能设计..................... 错误!未指定书签。 6.1交换中心子系统 ............................ 错误!未指定书签。 6.2接入管理子系统 ............................ 错误!未指定书签。 6.3前置机管理子系统 (12) 6.4运行监控子系统 ............................ 错误!未指定书签。 6.5系统管理 .................................. 错误!未指定书签。第七章交换平台安全设计......................... 错误!未指定书签。第八章本期主题应用开发......................... 错误!未指定书签。 8.1政务资源目录管理系统...................... 错误!未指定书签。
政府数据交换平台解决方案 目前，国内各地政府部门和机构或多或少均建立起自己的信息化系统，包括门户网站内容管理系统、OA办公系统、办事审批系统、其它业务系统等。但由于诸多因素的影响，即使同一地区的政府机构间也无法进行合理、有效的沟通，可以说是一座座的“信息孤岛”。电子政务实施的任务之一就是要将这些“孤岛”有机地串连在一起，充分发挥其效能，同时也保护了各部门在该方面的经济投入和精力投入。此外，电子政务建设过程中，即使是统一规划，但具体的实施单位和解决方案会有很多，建设完成后的系统常常是自治的，异构的，数据可能存放于数据库、文本文件、XML文件，甚至普通文件中。因此也需要一种机制使不同时期建设的应用系统能有机地结合为一个整体。上述两种情况，均要求解决应用系统间数据和信息的互通、互用问题。 如上图所示，原来的典型处理方法是需要一个个直接的“点对点”的数据链接，并且需要定制开发以实现系统之间的“会话”。随着新系统的不断增加，直接的定向连接和定制开发的情况会急剧增加，这最终将成为信息流动和系统维护的瓶颈。 在数据交换领域中，没有标准的部落式交换的代价是高昂的，相同的数据分析处理模块在很多应用中被重复地撰写，可能只是为了将某一数据源的数据转换到各个不同的目标数据源中去。由于没有中间标准，各个系统的实现人员也几乎没有可能将代码重用，昂贵的数据交换代价使得数据源只能散乱孤立地存在。 因此，有必要建立一个通用的、分布式的数据集成平台，用以解决电子政务实施过程中对于基于异构数据平台上的数据无法进行有效交流和沟通的问题。“大汉网络数据交换平台”就是解决该类问题的一个解决方案。
“大汉网络数据交换平台”能够为需要数据集成的应用提供数据服务，解决数据从何而来，哪个应用对其感兴趣，以及如何被每个系统使用的问题。“大汉网络数据交换平台”通过把信息提供者和消费者隔离，来构建灵活的系统，使得这些系统不会受到数据的物理位置的影响，也不会受到需要存取数据信息的应用个数的影响，对于每一个系统就不需要进行特别的定制处理，就可以在系统之间实现信息的集成了。 “大汉网络数据交换平台”通过一个集成框架的方案来解决这个问题，通过为开发人员提供一组标准接口（适配器）来实现这个方案。 “大汉网络数据交换平台”主要功能为：各应用系统数据的抽取或加载；交换数据通过交换平台完成数据的交换传输；各应用系统交换数据的比对、整理。各应用系统仅需负责确定本系统参与交换的数据，而不必关心数据库之间数据的传送。 二、系统设计 1．设计原则 数据交换平台应遵循以下几个基本设计原则： 不影响现有或其它相关信息系统的使用和信息安全。 采用先进成熟、稳定的技术和软硬件平台。 坚持开放性，易于技术更新。 采用国际通用标准，便于和国际接轨，易于系统扩展及升级。 建立一个坚实的系统应用平台，便于系统的管理和维护，技术易于更新，网络及业务规模可以逐步扩展。统一规划，分步实施。
污染源在线自动监控系统数据传输和接口标准技术规FIX 超时重发机制： 请求回应的超时，在一个请求命令发出后在规定的时间未收到回应，认为超时。超时后重发，重发规定次数后仍未收到回应认为通讯不可用，通讯结束。超时时间根据具体的通讯方式和任务性质可自定义。超时重发次数根据具体的通讯方式和任务性质可自定义。 执行超时 请求方在收到请求回应（或一个分包）后规定时间未收到返回数据或命令执行结果，认为超时，命令执行失败，结束。缺省超时定义表（可扩充）： 通讯协议数据结构 所有的通讯包都是由ACSII码字符组成(CRC校验码除外)。 通讯包结构组成：
字段对照表 代码定义 系统编码表（可扩充）（GB/T16706-1996）见《环境信息标准化手册》第一卷第236页
执行结果定义表（可扩充） 请求返回表（可扩充）
附录A：循环冗余校验（CRC）算法 CRC校验（Cyclic Redundancy Check）是一种数据传输错误检查方法，CRC码两个字节，包含一16位的二进制值。它由传输设备计算后加入到消息中。接收设备重新计算收到消息的CRC，并与接收到的CRC 域中的值比较，如果两值不同，则有误。 CRC是先调入一值是全“1”的16位寄存器，然后调用一过程将消息中连续的8位字节各当前寄存器中的值进行处理。仅每个字符中的8Bit数据对CRC有效，起始位和停止位以及奇偶校验位均无效。 CRC校验字节的生成步骤如下： ①装一个16位寄存器，所有数位均为1。 ②取被校验串的一个字节与16位寄存器的高位字节进行“异或”运算。运算结果放入这个16位寄存器。 ③把这个16寄存器向右移一位。 ④若向右（标记位）移出的数位是1，则生成多项式1010 0000 0000 0001和这个寄存器进行“异或”运算；若向右移出的数位是0，则返回③。 ⑤重复③和④，直至移出8位。 ⑥取被校验串的下一个字节 ⑦重复③~⑥，直至被校验串的所有字节均与16位寄存器进行“异或”运算，并移位8次。 ⑧这个16位寄存器的容即2字节CRC错误校验码。 校验码按照先高字节后低字节的顺序存放。
产品数据交换标准结构(chanpin shuju jiaohuan biaozhun STEP) 产品数据交换标准STEP (Product data exchange standard STEP) 指国际标准化组织(ISO)制定的系列标准ISO 10303 《产品数据的表达与交换》。这个标准的主要目的是解决制造业中计算机环境下的设计和制造（CAD/CAM）的数据交换和企业数据共享的问题。中国陆续将其制定为同名国家标准，标准号为GB/T 16656。该标准有一个非正式的，但在国际上非常流行的名字－STEP，它是Standard for the Exchange of Product model data的缩写。 企业的产品设计采用计算机辅助设计（CAD）技术以后遇到了很大的挑战。首先是由于企业的产品设计产生的CAD数据迅速膨胀。这些信息是企业的生命，它们不断的产生出来，不断地被更新改版。这种技术信息在企业的不同部门中和生产过程中流动，重要的档案信息要保存几十年。但是，CAD设计产生的数据不再象传统的图纸那样随便拿给任何地方的任何人都能阅读。各种CAD系统之间的不兼容造成企业不同系统之间的数据不能共享，有时会造成非常严重的经济损失。CAD系统不能发挥出最大的效益，很大的原因之一就是由于数据交换产生的障碍。 另一方面，很多企业的设计档案都要求保存几十年，这就意味着经过长期保存的CAD数据经过几十年以后，在已经更新了若干代的计算机软硬件系统中还应该能够正确读出并能得到再次使用。如果做不到，那将是企业的灾难。由于计算机系统软硬件的生命周期越来越短，CAD数据的长期存档在当前恰恰是很难做到的。 为了解决上述问题，国际标准化组织ISO/TC184/SC4 (以下简称SC4) 工业数据分技术委员从1983年开始着手组织制定一个统一的数据交换标准STEP。到目前为止，该标准的基本原理和主要的二维和三维产品建模应用协议已经成为正式的国际标准，市场上的主要CAD 软件都已经开始提供商品化的STEP的接口。虽然STEP标准的制定进展缓慢，但是它已经在一些发达国家的先进企业中得到应用，如飞机、汽车等制造行业。 STEP标准的体系结构如图所示，共分四个层次，下层主要是标准的原理和方法，中间两层是标准的资源，最上层是应用协议（AP）。其中资源是建立应用协议的基础，建立应用协议是制定本标准的目的，是开发CAD / CAM数据交换接口的依据。 STEP标准是一个系列标准，是由若干分标准（或“部分”）组成的。体系结构的矩形框表示了系列标准的分类，其中的编号对应分标准的编号规则。例如描述方法类分标准的编号是11、12、13…。应用协议类分标准的编号是201、202、203…。 EXPRESS语言 STEP标准描述方法中的一个重要的标准是ISO 10303 - 11 EXPRESS语言参考手册。EXPRESS语言是描述方法的核心，也是STEP标准的基础。该标准是一种形式化描述语言，但不是计算机编程语言。它吸收了现代编程语言的优点，主要目的是为了建立产品的数据模型，对产品的几何、拓扑、材料、管理信息等进行描述。 STEP标准体系结构 EXPRESS语言为了能够描述客观事物、客观事物的特性、事物之间的关系，它引入了实体（ENTITY）和模式（SCHEMA）的概念。在EXPRESS语言中把一般的事物（或概念）抽象为实体，若干实体的集合组成模式。这意味着小的概念可组成大的概念。事物的特性在EXPRESS语言中用实体的属性（attribute）表示。实体的属性可以是简单数据类型，如实数
大数据平台建设方案 (项目需求与技术方案) 一、项目背景 “十三五”期间，随着我国现代信息技术的蓬勃发展,信息化建设模式发生根本性转变,一场以云计算、大数据、物联网、移动应用等技术为核心的“新 IT”浪潮风起云涌,信息化应用进入一个“新常态”。***（某政府部门)为积极应对“互联网＋”和大数据时代的机遇和挑战,适应全省经济社会发展与改革要求，大数据平台应运而生。 大数据平台整合省社会经济发展资源,打造集数据采集、数据处理、监测管理、预测预警、应急指挥、可视化平台于一体的大数据平台,以信息化提升数据化管理与服务能力，及时准确掌握社会经济发展情况,做到“用数据说话、用数据管理、用数据决策、用数据创新”,牢牢把握社会经济发展主动权和话语权。 二、建设目标 大数据平台是顺应目前信息化技术水平发展、服务政府职能改革的架构平台。它的主要目标是强化经济运行监测分析，实现企业信用社会化监督,建立规范化共建共享投资项目管理体系，推进政务数据共享和业务协同,为决策提供及时、准确、可靠的信息依据,提高政务工作的前瞻性和针对性,加大宏观调控力度,促进经济持续健康发展。 1、制定统一信息资源管理规范,拓宽数据获取渠道，整合业务信
息系统数据、企业单位数据和互联网抓取数据，构建汇聚式一体化数据库,为平台打下坚实稳固的数据基础。 2、梳理各相关系统数据资源的关联性,编制数据资源目录，建立信息资源交换管理标准体系，在业务可行性的基础上，实现数据信息共享，推进信息公开，建立跨部门跨领域经济形势分析制度。 3、在大数据分析监测基础上，为政府把握经济发展趋势、预见经济发展潜在问题、辅助经济决策提供基础支撑。 三、建设原则 大数据平台以信息资源整合为重点，以大数据应用为核心，坚持“统筹规划、分步实施,整合资源、协同共享,突出重点、注重实效,深化应用、创新驱动”的原则,全面提升信息化建设水平,促进全省经济持续健康发展。
国家全民健康信息平台数据交换规范 1范围 本规范规定了国家全民健康信息平台数据交换采用数据接口规范，规定了平台数据交换范围与格式、交换方式与流程、交换管理等规范。 本规范适用于指导国家级与省级全民健康信息平台数据交换接口设计，以及交换体系的建立和管理工作，适用于规范全民健康信息平台数据采集、传输、存储等工作。 2规范性引用文件 下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。 WS/T303-2009卫生信息数据元标准化数据规范 WS/T305-2009卫生信息数据集元数据规范 WS363-2011卫生信息数据元目录 WS365-2011城乡居民健康档案基本数据集 WS372-2012疾病管理基本数据集 WS373-2012医疗服务基本数据集 WS374-2012卫生管理基本数据集 WS375-2012疾病控制基本数据集 WS376-2013儿童保健数据集 WS377-2013妇女保健基本数据集 WS445-2014电子病历基本数据集 WS/T447-2014基于电子病历的医院信息平台技术规范 WS/T448-2014基于居民健康档案的区域卫生信息平台技术规范 WS/T482-2016卫生信息共享文档编制规范 WS/T483-2016健康档案共享文档规范 WS/T500-2016电子病历共享文档规范 WS/T502-2016电子健康档案与区域卫生信息平台标准符合性测试规范
WS537-2017居民健康卡数据集 WS538-2017医学数字影像通信基本数据集 WS539-2017远程医疗信息基本数据集 WS541-2017新型农村合作医疗基本数据集 WS542-2017院前医疗急救基本数据集 WS374.1-2012卫生管理基本数据集第一部分：卫生监督检查与行政处罚WS374.2-2012卫生管理基本数据集第二部分：卫生监督行政许可与登记WS374.3-2012卫生管理基本数据集第三部分：卫生监督监测与评价 WS374.4-2012卫生管理基本数据集第四部分：卫生监督机构与人员 WS541-2017新型农村合作医疗基本数据集 WS/T546-2017远程医疗信息系统与统一通信平台交互规范 GB/T22611-2003个人基本信息分类与代码第1部分：人的性别代码 GB/T22612-2003个人基本信息分类与代码第2部分：婚姻状况代码 GB/T3304中国各民族名称罗马字母拼写法和代码 GB/T4761家庭关系代码 GB/T4658学历代码 GB/T6565职业分类与代码 GB/T2260中华人民共和国行政区划代码 GB/T2659世界各国和地区名称代码 GB/T21062.4-2007政务信息资源交换体系第4部分：技术管理要求 电子病历基本架构与数据标准（试行）原卫生部2009年 健康档案基本架构与数据标准（试行）原卫生部2009年 3术语和缩略语 3.1术语和定义 下列术语和定义适用于本文件。 3.1.1 居民、个人、患者resident，person，patient 通过医疗卫生服务体系获取和接受服务的个体。在本标准中这些术语可互换使用。 3.1.2
卡口大数据平台技术方案
目录 第1章总体技术架构 .................................................................................................... 错误!未定义书签。第2章车辆特征识别 .................................................................................................... 错误!未定义书签。 服务功能 .................................................................................................................... 错误!未定义书签。 服务性能 .................................................................................................................... 错误!未定义书签。第3章稽查业务功能 .................................................................................................... 错误!未定义书签。 车辆布控功能 ............................................................................................................ 错误!未定义书签。 车牌精确布控........................................................................................................ 错误!未定义书签。 车牌模糊布控........................................................................................................ 错误!未定义书签。 车型布控................................................................................................................ 错误!未定义书签。 车辆类别布控........................................................................................................ 错误!未定义书签。 布控实时预警........................................................................................................ 错误!未定义书签。 布控审批................................................................................................................ 错误!未定义书签。 车辆搜索功能 ............................................................................................................ 错误!未定义书签。 按车型搜车............................................................................................................ 错误!未定义书签。 按类别搜车............................................................................................................ 错误!未定义书签。 按车牌搜车............................................................................................................ 错误!未定义书签。 按车辆局部特征搜车............................................................................................ 错误!未定义书签。 轨迹重现................................................................................................................ 错误!未定义书签。 车辆综合研判 ............................................................................................................ 错误!未定义书签。 套牌车筛选............................................................................................................ 错误!未定义书签。 频繁过车................................................................................................................ 错误!未定义书签。 同行车辆................................................................................................................ 错误!未定义书签。
数据共享交换平台解决方案 1、概述 目前，政府职能正从管理型转向管理服务型，如何更好地发挥政府部门宏观管理、综合协调的职能，如何更加有效地向公众提供服务，提高工作效率、打破信息盲区、加强廉政建设已成为当前各级政府部门普遍关注和亟待解决的问题。国家“十五”计划纲要要求“政府行政管理要积极运用数字化、网络化技术，加快信息化进程”。各级政府、行政管理部门都面临着利用信息技术推动政务工作科学化、高效率的新局面。 随着电子政务建设的不断发展，政府拥有越来越多的应用数据，如何建立政府信息资源采集、处理、交换、共享、运营和服务的机制和规程，实现分布在各类政府部门和各级政府机关的信息资源的有效采集、交换、共享和应用，是电子政务建设的更高级的阶段和核心任务。信息资源只有交流、共享才能被充分开发和利用，而只有打破信息封闭，消除信息“荒岛”和“孤岛”，也才能创造价值。目前各级政府都在进行政务资源数据的“整合”，但“整合”什么？如何“整合”？“整合”后做什么？将是摆在政府各级领导面前的首要问题。 2、电子政务总体框架
由上图可以看出，数据共享交换平台交换体系共分为六个层次，分别是安全和标准体系、网络基础设施、信息资源中心、共享交换平台、应用层和展示层。 （1）展示层 通过建立综合信息集成门户系统为用户提供统一的用户界面，信息和应用通过门户层实现统一的访问入口和集中展现。 （2）应用层 应用层提供满足面向各类用户依据实际需求开展业务的需要。如支撑城市应急联动应用、辅助领导决策应用、城市管理应用、社会救助应用等。 （3）共享交换平台层 共享交换平台层为城市数据共享交换平台所在位置，连接各类应用和应用所需的信息资源，组织和整合各类数据、组件和服务。
附件1 大数据标准体系 序号一级分类二级分类国家标准编号标准名称状态 1 基础标准总则信息技术大数据标准化指南暂时空缺 2 术语信息技术大数据术语已申报 3 参考模型信息技术大数据参考模型已申报 4 数据处理数据整理GB/T 18142-2000 信息技术数据元素值格式记法已发布 5 GB/T 18391.1-2009 信息技术元数据注册系统(MDR)第1部分：框架已发布 6 GB/T 18391.2-2009 信息技术元数据注册系统(MDR)第2部分：分类已发布 7 GB/T 18391.3-2009 信息技术元数据注册系统(MDR)第3部分：注册系统元模型与基本属性已发布 8 GB/T 18391.4-2009 信息技术元数据注册系统(MDR)第4部分：数据定义的形成已发布 9 GB/T 18391.5-2009 信息技术元数据注册系统(MDR)第5部分：命名和标识原则已发布 10 GB/T 18391.6-2009 信息技术元数据注册系统(MDR)第6部分：注册已发布 11 GB/T 21025-2007 XML使用指南已发布 12 GB/T 23824.1-2009 信息技术实现元数据注册系统内容一致性的规程第1 部分：数据元已发布 13 GB/T 23824.3-2009 信息技术实现元数据注册系统内容一致性的规程第3 部分：值域已发布 14 20051294-T-339 信息技术元模型互操作性框架第1部分：参考模型已报批 15 20051295-T-339 信息技术元模型互操作性框架第2部分：核心模型已报批 16 20051296-T-339 信息技术元模型互操作性框架第3部分：本体注册的元模型已报批 17 20051297-T-339 信息技术元模型互操作性框架第4部分：模型映射的元模型已报批 18 20080046-T-469 信息技术元数据模块(MM) 第1 部分:框架已报批
市农业大数据应用平台 建设项目 技术要求 2016年
目录 1技术要求 (3) 1.1项目目标 (3) 1.2建设现状 (3) 1.3建设原则 (4) 1.3.1先进性和成熟性 (4) 1.3.2可靠性和安全性 (5) 1.3.3开放性和标准化 (5) 1.3.4伸缩性和可扩展性 (5) 1.3.5易用性和可控性 (5) 1.4总体要求 (6) 1.4.1技术路线 (6) 1.4.2技术要求 (6) 1.4.3界面设计要求 (8) 1.4.4技术指标要求 (8) 1.5建设内容 (10) 1.5.1门户网站建设 (10) 1.5.2农业项目管理系统建设 (11) 1.5.3现有业务系统整合 (12) 1.6工程控制及验收需求................................................................. 错误！未定义书签。 1.6.1工程控制......................................................................... 错误！未定义书签。 1.6.2总体建设进度................................................................. 错误！未定义书签。 1.6.3里程碑及阶段交付物..................................................... 错误！未定义书签。 1.6.4项目验收......................................................................... 错误！未定义书签。2数据采集设备参数要求 (12)
第一章概述 整合协同平台的主要功能是从其它子系统中提取共享数据，并对多来源渠道的、相互不一致的数据进行数据融合处理；基于数据字典对实时数据和历史数据进行组织，以保证数据间关系的正确性、可理解性并避免数据冗余；以各种形式提供数据服务，采用分层次的方法对各类用户设置权限，使不同用户既能获得各自所需要的数据，又能确保数据传输过程的安全性及共享数据的互操作性和互用性；维护基础信息、动态业务数据以及系统管理配置参数；支撑系统的网络构架、信息安全、网络管理、流程管理、数据库维护和备份等运维能力。整合协同平台根据功能可分为两个部分： 第一部分，基础数据和共享数据的交换服务和路由流程管理，该部分是交换平台的基础，包括：静态交换数据、动态交换数据、图形数据及表格、统计资料等属性数据。 第二部分，各子系统之间的接口实现，根据事先制订好的规范、标准，实现各子系统之间的数据共享和传输操作。在接入中心平台时，应按系统集成要求设计系统结构，各类数据接口遵循系统集成规范。
第二章中心平台设计 2.1 平台功能结构 整合协同平台服务器是公共基础平台的核心部分，XMA整合协同平台提供一整套规范的、高效的、安全的数据交换机制。XMA整合协同平台由部署在数据中心和各业务部门的数据交换服务器、数据接口系统共同组成，解决数据采集、更新、汇总、分发、一致性等数据交换问题，解决按需查询、公共数据存取控制等问题。 各业务子系统都要统一使用XMA整合协同平台进行数据交换。数据中心统一管理和制定数据交换标准。各业务部门通过数据级整合或者应用级整合通过XMA 整合协同平台向数据中心提供数据，也通过XMA整合协同平台访问共享数据。 XMA整合协同平台的基本功能如下： 共享数据库的数据采集、更新、维护。 业务资料库、公共服务数据库的数据采集。 提供安全可靠的共享数据服务。 业务部门之间的业务数据交换。 结合工作流的协调数据服务。
应指技装〔2012〕24号附件5 安全生产应急平台 信息交换与共享技术规 （试行） 安全生产应急救援指挥中心 二〇一二年八月
安全生产应急平台信息交换与共享技术规 （试行） 1围 本技术规提出了安全生产应急平台信息交换与共享体系架构、技术实现式、信息交换与共享系统的技术要求、数据接口规和数据交换共享容。 本技术规适用于规划设计和建设各级安全生产应急救援指挥机构应急平台之间，以及安全生产应急平台与政府应急平台、安委会成员单位应急平台、企业安全生产应急平台之间的信息交换和共享系统。 2规性引用文件 下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。 GB/T 7408-1994 数据元和交换格式信息交换日期和时间表示法 GB/T 18793-2002 信息技术可扩展置标语言（XML)1.0 GB/T 21062.1-2007 政务信息资源交换体系第1部分：总体框架 GB/T 21062.2-2007 政务信息资源交换体系第2部分：技术要求 GB/T 21062.3-2007 政务信息资源交换体系第3部分：数据接口规 GB/T 21062.4-2007 政务信息资源交换体系第4部分：技术管理要求
3术语及定义 3.1 安全生产应急平台信息交换 信息交换是指独立于具体应用，与具体应用耦合关系松而清楚，不随应用的变化而变化，保证数据可靠传输和安全传输，提供统一接口规，实现安全生产应急平台与不同部门异构系统之间不同格式数据的交换。 3.2 安全生产应急平台信息共享 信息共享指各级安全生产应急平台之间，或与政府应急平台、安委会成员单位应急平台、企业应急平台等不同层次、不同部门的应急平台系统间，信息和信息产品的交流与共用。 3.3 前置机 前置机是一种以数据交换为基础的中间交易设备，它实现的主要功能有网络通信、数据认证、数据格式转换、数据流水记录、数据预处理、数据监控和数据统计等。 3.4 服务接口 服务接口是指各级安全生产应急平台之间以及与其他不同层次、不同部门应急平台系统或人之间的共享边界。 4信息交换与共享体系 4.1概述 信息交换与共享在整个安全生产应急平台体系中居于中心地位。本级安全生产应急平台通过信息交换与共享系统抽取及共享下级安全生产应急平台提供的