CESA-2024《市场监管用异构系统数据互联要求》

ICS35.240.01

CCSL66

团体标准

T/CESAXXXX—2024

市场监管用异构系统数据互联要求

Requirementsforheterogeneoussystemdatainterconnectionformarket

supervision

征求意见稿

在提交反馈意见时，请将您知道的相关专利连同支持性文件一并附上。

已授权的专利证明材料为专利证书复印件或扉页，已公开但尚未授权的专利申请

证明材料为专利公开通知书复印件或扉页，未公开的专利申请的证明材料为专利申请

号和申请日期。

2024-XX-XX发布2024-XX-XX实施

中国电子工业标准化技术协会发布

T/CESAXXXX—202X

目次

前言...............................................................................III

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

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

3术语和定义...........................................................................1

4缩略语...............................................................................1

5市场监管用异构数据互联架构...........................................................1

6市场监管用异构系统数据互联应用场景...................................................3

7市场服务领域异构系统数据交换要求.....................................................3

8市场服务异构系统数据质量保障.........................................................7

9市场监管用异构系统数据互联安全要求...................................................7

10市场监管用异构系统数据互联资源管理要求..............................................8

11市场监管用异构系统数据互联运维保障和故障处理要求....................................8

II

T/CESAXXXX—202X

市场监管用异构系统数据互联要求

1范围

本文件规定了市场服务系统资源数据交换中，多源异构系统的互联参考模型，包括互联方式、一般

要求、模型组件及数据安全要求。

本文件适用于市场监管用服务系统资源数据交换中的异构系统对接。

2规范性引用文件

下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，

仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本

文件。

3术语和定义

GB/T17969.1和GB/T26231界定术语和定义适用于本文件。

数据集dataset

数据记录汇聚的数据形式。

注：它可以具有大数据的体量、速度、多样性和易变性特征。数据集的特征表征是数据本身或静态

数据，而数据的特征，当其在网络上传输时或暂时驻留与计算机存储器中以备读出或更新时，表征的是

动态数据。

[来源：GB/T35295-2017,2.1.46]

4缩略语

下列缩略语适用于本文件。

API：应用编程接口(ApplicationProgrammingInterface)

FTP：文件传输协议（FileTransferProtocol）

JSON：JAVA脚本对象记法（JavaScriptObjectNotation）

REST：表述性状态传递（RepresentationalStateTransfer）

XML：可扩展置标语言（ExtensibleMarkupLanguage）

5市场监管用异构数据互联架构

5.1一般要求

市场监管用异构数据互联架构用于连接、整合和管理来自不同源、不同格式、不同结构的数据的系

统架构。

1

T/CESAXXXX—202X

市场监管用异构数据互联架构应满足如下一般要求：

a)能兼容数据多样性问题：包括关系型数据库、非关系型数据库、文件系统、数据流等。

b)能处理数据差异性问题：包括数据格式、结构和存储方式各不相同，命名冲突、格式冲突和结

构冲突等问题。

c)能协调异构系统自治性问题：包括各个数据源通常具有自身的数据管理系统和访问控制机制，

保持一定的独立性和自治性。

5.2市场监管用异构系统数据交互流程图

市场监管用异构系统数据交互流程如图1所示。

数据交换引擎

信息系统AWebService信息系统B

RESTAPI

数据映射转换引擎

电子邮件

数据集A抽取加密解密数据元映射数据集B

FTP

代码映射

网盘

数据转换

开放数据库

……

图1市场监管用异构系统数据交互流程图

5.3市场监管用异构系统数据交互组件

异构系统互联模型包含如下组件：

a）信息系统A

信息系统A中应至少包含数据集A，以及可选的数据抽取和数据加密。

b）数据集A

数据集A应为采用非市场服务系统资源标准的资源数据。

c）数据抽取

数据抽取应实现从数据集A中抽取部分数据子集或全部数据集。

d）数据加密

数据加密应实现对抽取的部分数据子集或全部数据集进行加密。

e）数据交换引擎

数据交换引擎应实现市场服务系统资源数据从信息系统A到信息系统B交换，交换方式可采用

WebService接口、RESTAPI接口、电子邮件、FTP、网盘、开放数据库等方式。

f）信息系统B

信息系统B中应至少应包含数据映射转换引擎模块和数据集B，以及可选的数据解密。

g）数据解密

数据解密应实现对d）中已加密数据进行解密。

h）数据映射转换引擎

数据映射转换引擎应将采用非市场服务系统资源标准的资源数据转换为符合市场服务系统资源标

准的资源数据，应至少包括数据元映射、代码映射和数据转换。

i）数据集B

2

T/CESAXXXX—202X

数据集B应为采用市场服务系统资源标准的资源数据。

6市场监管用异构系统数据互联应用场景

市场监管用异构数据互联应用场景包括：

a)监管信息统一化

监管体系内各个部门可能使用不同的系统和数据库来存储和管理数据。通过异构数据互联架构，可

以实现跨部门的数据共享和协同工作，提高整体运营效率。。

b)监管大数据分析

在监管大数据分析中，应要处理来自不同源、不同格式的海量数据。异构数据互联架构能够支持这

种复杂的数据处理需求，提供高效的数据整合和分析能力。

c)市场监管网络

市场监管网络，设备种类繁多、数据格式各异。通过异构数据互联架构，可以实现对各种物联网设

备的数据进行统一管理和分析，推动监管设备应用的深入发展。

7市场服务领域异构系统数据交换要求

7.1数据交换方式

数据交换引擎应提供数据交换方式，包括数据查询、数据订阅和多媒体下载等部分，其中数据订阅

分为实时订阅和批量订阅两类。具体如下：

a)数据查询。用于对生命周期内的历史数据按条件查询，返回查询结果。数据查询的结果通过实

时传输或者批量下载的方式进行反馈：对于结果数据量小、速度快的查询可通过实时传输的方

式反馈结果，对于结果数据量大、查询速度慢的查询可通过批量下载的方式反馈结果。

b)数据订阅。用于用户提出订阅条件，返回最新命中数据。其中，实时订阅通过实时传输的方式

反馈结果，批量订阅通过批量下载的方式反馈结果。

c)多媒体下载。用于下载消息中涉及的多媒体文件，多媒体下载可通过实时传输或者批量下载的

方式反馈结果。

7.2数据交换引擎组成

数据交换引擎分为接口层、服务层、缓存层、数据转存、权限管理服务、日志审计服务和运维监控。

其中：

a)接口层负责用提供户访问的界面和各数据交换请求的接口；

b)服务层负责提供各类数据交换服务和数据元存储；

c)缓存层负责提供实时数据、批量结构化数据以及多媒体数据的缓存；

d)数据转存负责从大平台拉取数据，进行数据脱敏，并依数据类型不同分别存入消息队列和各类

缓存数据库；

e)权限管理服务负责提供权限验证和修改服务；

f)日志审计管理负责提供系统模块日志追踪和用户行为审计；

g)运维监控负责保障系统平稳运行，及时发现并反馈故障。

7.3数据交换引擎详细要求

数据交换引擎通过详细规范细化具体的要求，包括接口规范、缓存要求、安全性要求、资源管理要

求、运维保障和故障处理要求，数据交换引擎实现方应根据本标准执行这些详细规范，其中：

3

T/CESAXXXX—202X

a)接口规范包括数据查询规范、数据订阅规范、多媒体下载规范和数据交换规范，分别定义了查

询、订阅和多媒体获取功能的数据传输过程以及数据交换API的使用方法；

b)缓存要求、安全性要求、资源管理要求和运维保障和故障处理要求则分别从数据缓存、系统安

全性、资源分配和可用性、可靠性等方面对数据交换系统的建设提出了要求。

7.4数据查询

7.4.1数据查询功能要求

数据查询请求由用户发起数据交换请求，数据交换引擎执行查询后返回查询结果。

7.4.2数据查询请求

数据查询请求以TCP方式实现，并通过SSL/TLS进行数据传输加密。

用户发送请求后、数据接收结束前，每隔60秒发送一次心跳维持包。若接收到平台的心跳反馈，则

重新计算心跳次数。如果3次心跳结束后，还未接到平台的心跳反馈，则认为连接断开。

连接断开时应进行重试，共重试3次。若3次重试无法成功，则轮询其他节点进行重试，每个节点重

试3次。当所有节点轮询结束后无法成功，则认为请求失败。

7.4.3数据查询响应

查询结果以批量或者实时的方式进行反馈。

7.5数据订阅

7.5.1数据订阅功能要求

数据订阅请求由用户发起数据交换请求，数据交换引擎执行查询后返回查询结果。

7.5.2数据订阅请求

数据订阅请求以TCP方式实现，并通过SSL/TLS进行数据传输加密。

数据订阅请求分为两类：实时数据订阅和批量数据订阅。

数据订阅请求由用户发起数据交换请求，数据交换引擎执行查询后返回查询结果。

用户发送请求后、数据接收结束前，每隔60秒发送一次心跳维持包。若接收到平台的心跳反馈，则

重新计算心跳次数。如果3次心跳结束后，还未接到平台的心跳反馈，则认为连接断开。

连接断开时应进行重试，共重试3次。若3次重试无法成功，则轮询其他节点进行重试，每个节点重

试3次。当所有节点轮询结束后无法成功，则认为请求失败。

7.5.3数据订阅响应

实时数据订阅请求以实时的方式进行反馈。批量数据订阅请求以批量的方式进行反馈。用户通过响

应路径下载结果数据文件。每隔5分钟，或者积攒的结果数据量达到10MB，结果路径中会增加一个结果

文件。

7.6多媒体获取

7.6.1多媒体获取功能要求

多媒体获取请求由用户发起数据交换请求，数据交换引擎代为获取多媒体文件后返回多媒体文件。

多媒体获取请求为多媒体URL、FTP资源位置、网盘资源位置、电子邮件等。

4

T/CESAXXXX—202X

7.6.2多媒体获取请求

多媒体获取请求以TCP方式实现，并通过SSL/TLS进行数据传输加密。

用户发送请求后、数据接收结束前，每隔60秒发送一次心跳维持包。若接收到平台的心跳反馈，则

重新计算心跳次数。如果3次心跳结束后，还未接到平台的心跳反馈，则认为连接断开。

连接断开时应进行重试，共重试3次。若3次重试无法成功，则轮询其他节点进行重试，每个节点重

试3次。当所有节点轮询结束后无法成功，则认为请求失败。

7.6.3多媒体获取响应

多媒体获取结果以二进制形式呈现，可以以批量或者实时的方式进行反馈。对于实时方式的反馈；

对于批量方式的反馈，用户通过响应路径下载结果数据文件。

7.7数据交换API

7.7.1数据交换API功能要求

数据交换API用于发起实时数据请求，包括实时查询、实时订阅和实时多媒体获取三种请求。

7.7.2建立连接

异构互联平台可提供两种建立连接的方式：

a)用户名和密码；

b)授权码。

7.7.3发起请求

异构互联平台可提供多种发起请求的方式，不同请求得到的结果集也不同，包括：

a)实时查询请求；

b)实时订阅请求；

7.7.4获取数据

结果集提供如下数据获取函数：

a)是否拥有下一个元素；

b)获取实时请求、订阅请求的下一个元素；

c)获取多媒体请求的下一个元素。

7.7.5获取数据元素

异构互联平台提供获取数据元素接口：

a)获取所有字段；

b)获取指定字段内容；

可通过JSON的方式获得字段的具体内容，也可通过二进制数据流，获取多媒体内容。

7.7.6关闭请求

不同请求可采用同样的关闭方式。请求关闭后，结果集中数据应不再可用。应确认无需继续处理后

再关闭请求。

7.7.7关闭连接

5

T/CESAXXXX—202X

在所有请求都结束后，请求方应主动关闭连接。

7.8缓存要求

7.8.1缓存类型要求

数据交换引擎应提供包括实时数据、离线数据、多媒体数据等的多种数据缓存能力，将大平台数据

缓存至数据交换引擎，降低数据交换对大平台的影响。

数据交换引擎应提供对源数据和结果数据的缓存能力。

7.8.2缓存数据管理要求

数据缓存应具有生命周期，对于超出生命周期的数据应进行自动删除，以免影响系统稳定性和新数

据的共享。

数据交换引擎应提供对缓存数据的生命周期的管理能力，能够增加、减小缓存数据的生命周期。

7.9数据组织描述要求

数据组织描述应采用文档模型对结构化、半结构化、非结构化数据进行统计建模，数据是由若干字

段组成的内容实体，其中每个字段属于某种特定的类型。类型包括简单类型，如整形、浮点型、字符型、

字符串型等，也包括复杂的类型，如数组：

a)数据：一个数据由若干字段组成的内容实体；

b)数据集：一个数据集由若干相同类型的数据组成，还包含了对数据集进行统一表述的一组公共

数据元信息。

7.10数据持久化

数据交换引擎可包含数据持久化模块。

数据持久化模块包含一系列的存储子系统持久化模块，这些持久化模块读取消息队列中的数据，并

调用各类存储子系统提供的写入接口将数据存储到对应的存储子系统中。

数据持久化的典型处理过程如下：

a)数据持久化模块从分布式消息队列中读取消息；

b)数据持久化模块按照数据结构描述及通用加载结构描述对消息体执行反序列化操作得到数据；

c)数据持久化模块按照处理逻辑对数据进行处理，并通过数据交换引擎的存储子系统持久化接口

执行数据持久化操作；

d)存储子系统接收数据并执行数据持久化；

e)存储子系统将数据持久化的状态或异常信息返回给数据持久化模块。

7.11数据元服务

必要时，信息系统应建立数据元服务。

数据元服务主要对进行交换的信息系统中需要交换的各类数据元进行统一存、取服务，如数据结构

描述、数据结构描述与消息队列的对应关系以及各个部件运行所需的配置等。具体的，加载系统数据元

服务主要提供如下三个方面的功能：

a)加载系统的数据元管理服务调用外部数据元服务的数据元获取接口，加载系统的数据元包括几

个方面的信息：

1)存储的逻辑信息：例如用于交换的表（数据库）、表的列（属性）、列上是否有索引，列

的数据类型等，还包括系统中的索引等辅助数据。

2)数据物理信息：如数据文件的存储位置、大小，数据文件的状态会被更改，因此数据服务

还包括文件状态的管理。

6

T/CESAXXXX—202X

3)硬件运行状态信息：如节点配置，状态等。

4)消息队列的状态信息。

b)数据元缓存。加载数据交换引擎对本地数据元进行缓存，一方面保证数据元访问的速度，同时

能及时获得数据交换引擎数据元的更新，另一方面通过避免频繁访问外部数据元服务，提高加

载服务的执行效率；

c)数据元服务具备消息通知功能，当软件或者硬件出现异常时，会及时通知相关的节点对异常做

出响应，如某消息服务器异常宕机后的接入系统消息处理的负载均衡。

8市场服务异构系统数据质量保障

8.1异构数据互联前的准备

市场服务异构系统在进行互联时，首先应明确互联过程数据发送方、接收方的地址，数据发送方和

接收方应按照预先约定的数据传输协议进行数据传输，以便解析对方所发送的数据内容。数据传输协议

通常可选择REST协议或者自定义的数据传输协议。传输返回的数据格式可包括JSON、XML等。

8.2优化数据处理性能

市场服务信息系统应加载数据互联引擎，执行异构系统之间的互联传输功能。宜采用分布式计算、

内存计算等高性能计算技术，提高数据处理的速度和效率。

8.3中间件的功能要求

数据互联引擎应作为市场服务信息系统互联的控件，通过接口调用等方式向异构系统互联服务平台

获取电子数据传输所必需的数据模板、通讯地址等信息，并负责实现异构信息系统之间的数据互联工作。

9市场监管用异构系统数据互联安全要求

9.1用户安全保障能力

用户安全保障能力包括日志监控能力、行为审计能力和权限控制能力三部分组成：

a)日志监控能力

数据交换引擎应提供日志监控能力，监控各模块的行为日志、警告日志和错误日志；能够及时发现

错误、致命错误等日志异常并及时报警。

b)行为审计能力

数据交换引擎应提供用户行为审计能力，能够审计包括且不限于权限申请、权限审核、任务下发、

任务删除等多项用户行为，为可能出现的故障和事故提供行为数据支持。

c)权限控制能力

数据交换引擎应提供用户权限控制能力，实现对不同用户展示的数据不同、不同用户能够获取的数

据不同、不同用户能够下发的数据获取指令不同。该权限能够由地方网信办申请并由中央网信办审核及

修改。

9.2数据安全

数据交换引擎应对电子传输数据进行加密传输，并可接入安全产品。同时要求针对数据的访问权限

进行控制，具体要求如下：

a)身份验证。要求数据对接双方的身份都要可鉴别，以防止第三方假冒。

7

T/CESAXXXX—202X

b)访问控制。对不同的用户有不同的权限，以控制其在系统中的操作。

c)数据的机密性。防止没有权限的用户窃取数据库中数据。

d)数据的完整性。在异构数据库间进行数据互联时，确保数据在传输的过程中没有被篡改。

e)非否认服务。保证收发双方无法否认自己已经接收或者己经发送数据的事实。

f)数据脱敏能力。杜绝敏感数据的外传，对于需要共享的敏感数据，应在数据共享前对数据进行

脱敏操作，保证脱敏后数据无法与原始数据关联。

g)安全传输能力。提供安全传输能力，设计安全的数据传输协议，保障分享的数据不被第三方获

取。

10市场监管用异构系统数据互联资源管理要求

10.1网络带宽控制与动态分配能力

数据交换引擎应提供网络带宽控制与动态分配能力，确保数据交换占用带宽不会影响到信息系统其

他业务。并且能够依据不同用户的数据需求量动态分配带宽，实现网络带宽使用的高效、安全。

10.2数据资源缓存与存储周期管理能力

数据交换引擎应提供数据资源缓存与存储周期管理能力。数据交换引擎应能够利用缓存技术减小数

据共享系统对大平台的影响；能够保证数据在超出存储周期后会自动删除，数据交换引擎不会因数据堆

积导致运行缓慢或者系统故障；并且能够调整数据存储周期。

10.3计算任务复用与计算资源分配能力

数据交换引擎应提供计算任务复用与计算资源分配能力。对于不同用户提出的相同任务进行必要的

复用，以减少系统任务量，提高系统可用性。对于不同的计算任务弹性分配相应的计算资源，保证负载

均衡与系统健壮性。

11市场监管用异构系统数据互联运维保障和故障处理要求

11.1运维保障要求

为了加强数据交换系统的稳定性，数据交换系统需加强运维，建立良好的运维机制，从而提高数据

交换的可靠性。针对数据交换系统的运维要求如下。

a)应建立7*24小时的运维响应机制。数据交换引擎实现对数据交换系统的实时运维监测，保障数

据交换的顺利进行。

b)提供数据监测服务。对交换的数据进行实时监测，具体监测内容包括：实时数据传输量监测、

多媒体文件传输量监测、带宽监测。

c)提供报警服务。当数据交换过程中出现故障时，大平台应主动报警，具体报警服务可包括：集

群故障报警服务、数据链路中断报警。

11.2故障处理要求

11.2.1故障等级

故障处理要求旨在规定数据提供方、大平台在数据交换出现故障时的响应机制及相关恢复要求。

根据故障的影响程度及紧急程度，将故障分为三级，具体要求如下：

a)紧急级故障：故障的严重性高、影响的业务系统较多，紧急程度高；

8

T/CESAXXXX—202X

b)重要级故障：故障的严重性中等、影响的业务系统重要程度中等，紧急程度中等；

c)一般级故障：故障的严重性一般、影响的业务系统少，紧急程度一般。

11.2.2故障响应时间

故障响应时间应满足：

a)紧急级故障：当数据交换引擎遇到故障时，数据交换引擎响应时间均不得超过30分钟；

b)重要级故障：当数据交换引擎遇到故障时，数据交换引擎响应时间均不得超过1小时；

c)一般级故障：当数据交换引擎遇到故障时，数据交换引擎响应时间均不得超过2小时。

11.2.3故障上报时间

故障上报时间应满足：

a)紧急级故障：当数据交换引擎遇到故障时，数据交换引擎上报相关负责人的时间均不得超过30

分钟；

b)重要级故障：当数据交换引擎遇到故障时，数据交换引擎上报相关负责人的时间均不得超过1

小时；

c)一般级故障：当数据交换引擎遇到故障时，数据交换引擎上报相关负责人的时间均不得超过2

小时。

11.2.4故障恢复时间

故障恢复时间应满足：

a)紧急级故障：当数据交换引擎遇到故障时，数据交换引擎故障恢复时间均不得超过30分钟；

b)重要级故障：当数据交换引擎遇到故障时，数据交换引擎故障恢复时间均不得超过1小时；

c)一般级故障：当数据交换引擎遇到故障时，数据交换引擎故障恢复时间均不得超过2小时。

9

中国电子工业标准化技术协会

团体标准《市场监管用异构系统数据互联要求》（征求意见

稿）编制说明

一、工作简况

1、任务来源

近年来，随着信息技术的飞速进步，市场监管领域的各类信息服务系统、平

台层出不穷。各异构系统在支撑市场业务系统的同时，也带来异构系统数据互联

互通的挑战。这些异构系统可能来源于不同部门、不同地区，甚至不同企业，它

们之间的数据格式、数据结构、通信协议等方面可能存在较大差异。为了确保这

些系统之间的数据能够顺畅、准确地传输，在市场监管领域制定统一的数据互联

规范显得尤为重要。

本标准的编制目的是，在多系统框架下，通过标准化数据互联，提高市场监

管领域数据的共享和整合能力，进而提升数据的利用效率。在数据互联的过程中，

确保数据的安全性和完整性。包括对数据的加密、访问控制、错误检测等方面的

规定，以防止数据泄露、篡改等安全问题。这对于市场监管执法部门来说，意味

着能够更好地利用数据进行决策、分析和监管，对现代化市场监管服务具有重要

意义。

本团体标准属于国家重大研发计划的国家质量基础设施体系（NQI）专项（项

目号：2021YFC33404）。

本团体标准任务来源于中国电子工业标准化技术协会（以下简称“中电标

协”）2024年8月12日发布的《2024年第八批团体标准制修订项目的通知》（中

电标通[2024]023号），项目号为CESA-2024-139，标准项目名称：市场监管用异

构系统数据互联要求，本标准是新制定标准，项目周期12个月。项目牵头单位是

湖北省标准化与质量研究院。

2、标准起草单位

本标准由湖北省标准化与质量研究院、中国电子技术标准化研究院、武汉迎

风聚智科技有限公司、中国计量大学、湖北省市场监督管理局执法稽查局等单位

共同起草。

中国电子工业标准化技术协会

3、主要工作过程

2023年10月-2024年3月，湖北省标准化与质量研究院对市场监管执法景下的

异构系统互联进行了广泛的前期调研，初步确定了OID标识作为互联中间件的标

准的框架。

2024年3月31日，湖北省标准化与质量研究院就标准内容框架与标准起草组

内单位进行讨论，结合组内单位意见，确定了标准的框架和主体内容，并开始撰

写标准的草案。

2024年5月26日，湖北省标准化与质量研究院完成了标准草案的初步撰写，

并就撰写的草案与准起草组内单位进行讨论，重点对标准的范围、异构互联系统

的参考架构和OID标识工具所需要具有的功能要求、可信要求等方面进行了讨论。

2024年6月9日，湖北省标准化与质量研究院就修改后的草案与准起草组内单

位进行讨论，重点对市场服务异构系统互连方式选择、市场服务领域异构系统互

连传输数据要求、市场服务异构系统互连建设模型、市场服务异构系统互连数据

安全要求等相关意见进行了讨论。

2024年6月20日，湖北省标准化与质量研究院完成对相关意见的整合和对草

案的修改，形成了团体标准《市场监管用异构系统数据互联要求》（草案稿）。

2024年7月10日，由中国电子工业技术协会组织团体标准项目立项论证会，

对《基于OID的异构系统数据互联规范》等两项团体标准项目建议进行了论证，

会上建议修改标准名称为《市场监管用异构系统数据互联要求》后同意立项。

2024年7月24日，根据中电标协发布的《2024年第八批团体标准制修订项目

的通知》（中电标通[2024]023号）要求，湖北省标准化与质量研究院联合中国

电子技术标准化研究院等单位成立标准编制工作组，召开了第一次标准编制工作

会议，策划标准的编制工作，制定了编制工作任务，着手开展标准的编制工作。

2024年7月24日-2024年8月20日，标准工作组对标准草案进行研讨，初步形

成《市场监管用异构系统数据互联要求》（征求意见稿）。

2024年8月20日-2024年9月4日，对征求意见稿（初稿）进行再编制、研讨及

完善，形成了《市场监管用异构系统数据互联要求》（征求意见稿）。

二、标准编制原则和确定主要内容的论据及解决的主要问题

1、编制原则

中国电子工业标准化技术协会

在标准编制过程中，遵循了以下五方面的原则。

a)符合性。遵循国家法律、法规等相关规定，制定过程严格按照程序执行。

b)先进性。制定过程中充分考虑了异构系统通信框架，并在安全可信方面

保持了一定的前瞻性。

c)适用性。考虑异构数据互联的数据格式、数据内容基本要求，并参考了

多个现有市场监管系统。

d)中立性。在本文件制定过程中，编制工作组对标准文本进行了充分讨论，

确保了中立性和客观性。

e)科学性。本文件的指标经过科学合理的设计，试验方法已经经过验证。

2、确定主要内容的依据

本标准旨在多标准体制下，通过标准化数据互联，提高数据的共享和整合能

力，进而提升数据的利用效率。参考了现行的市场监管平台在数据互联的过程需

求，包括对数据的加密、访问控制、错误检测等方面的规定，确定了本标准基于

OID标识的互联框架。

通过规范引用OID标识，及完成市场监管系统内容数据与OID标识数据的关

联，通过异构系统间OID标识数据的中转及解析，实现异构系统的数据互联，并

减少异构系统整合的时间和成本，从而提高市场服务部门的工作效率。规范的数

据互联可以促进不同部门、不同地区之间的信息共享，打破信息孤岛，提高整体

的市场服务水平。准确、及时的数据是科学决策的基础。

通过