478 lines
26 KiB
Plaintext
478 lines
26 KiB
Plaintext
《开放油气数据服务规范第1部分：总则》草案-0507
|
||
ICS
|
||
中华人民共和国石油天然气行业标准SY/TXXXX-20XX
|
||
开放油气数据服务规范
|
||
第1部分：总则
|
||
Specificationfor open data service in petroleum exploration and development
|
||
Part 1: General principles
|
||
202X-XX-XX发布202X-XX-XX实施
|
||
国家能源局
|
||
目次
|
||
前言
|
||
1范围1
|
||
2规范性引用文件1
|
||
3术语和定义1
|
||
4 缩略语3
|
||
5 总体要求4
|
||
5.1总体架构4
|
||
5.2 数据服务架构设计要求5
|
||
5.3业务域扩展要求5
|
||
5.4 功能与扩展要求5
|
||
6数据交换模型要求5
|
||
6.1数据交换模型要求5
|
||
6.2验证机制7
|
||
6.3版本管理7
|
||
7数据服务接口要求8
|
||
7.1通用技术要求8
|
||
7.2 数据服务接口分类8
|
||
7.3数据服务接口开发设计9
|
||
7.4 数据服务接口管理与运维要求9
|
||
8数据服务接口安全要求10
|
||
8.1传输安全10
|
||
8.2访问控制10
|
||
附录A11
|
||
附录B18
|
||
参考文献19
|
||
前言
|
||
油气行业作为稳定型的传统工业和典型的数字化深度应用行业，基于其复杂、多样的专业特质，具有不断创新与
|
||
深厚的科学技术积淀。在业务数智化、能源低碳化发展的时代背景下，石油工业软件面临着新型工业业态、数据生
|
||
态、技术与安全环境的全面变革。面对工业软件多样性和开发与运行环境迥异、数据孤岛、数据异构等复杂性，导致
|
||
了数据交互难、成果共享难、业务协同难等问题，严重制约了全产业链的协同效率与智能化发展。通过规范并统一数
|
||
据服务接口技术，实现跨学科、跨专业数据共享与系统互操作，降低软件集成难度，推动新型工业软件的转型升级，
|
||
提升油气行业数字化转型效能，编制本系列规范。首批共6个部分：
|
||
--第1部分总则：规定了开放油气数据服务的总体原则和通用技术要求-。
|
||
-一第2部分地震：规范了地震数据服务要求；
|
||
—一第3部分测井：规范了测井数据服务要求；
|
||
-一第4部分油气藏：规范了油气藏地质建模和数值模拟数据服务要求
|
||
-一第5部分钻井：规范了钻井工程设计和实钻数据管理数据服务要求
|
||
-一第6部分 油气生产：规范了油气生产数据管理与动态分析数据服务要求。
|
||
本文件是其中的第1部分，即“总则”部分。
|
||
本文件按照GB/T1.1-2020《标准化工作导则第1部分：标准化文件的结构和起草规则》的规定起草。
|
||
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。
|
||
本文件由石油工业标准化技术委员会石油信息与计算机应用专业标准化委员会提出并归口。
|
||
本文件起草单位：
|
||
本文件主要起草人
|
||
开放油气数据服务规范第1部分：总则
|
||
1.范围
|
||
本文件规定了油气行业工业软件数据服务接口开发的总体框架、技术要素、设计原则及通用要求。
|
||
本文件适用于油气行业地震、测井、油气藏、钻井、油气生产等专业数据交换的数据服务设计与开发。
|
||
2.规范性引用文件
|
||
下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对
|
||
应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。
|
||
GB/T 5271.1-2000信息技术 词汇第1部分：基本术语
|
||
GB/T18391.3-2009信息技术元数据注册系统（MDR）第3部分：注册系统元模型与基本属性
|
||
GB/T 527117-2010信息技术词汇第17部分：数据库
|
||
GB/T 36344-2018信息技术 数据质量
|
||
GA/T 911-2019信息安全技术日志分析产品安全技术要求
|
||
GB/T 32907-2016 信息安全技术 SM4分组密码算法
|
||
3.术语和定义
|
||
下列术语和定义适用于本文件。
|
||
数据元（素）data element
|
||
数据元（素）是数据结构中的基本单位，也被称为数据项、元素或节点。它是描述客观事物的最小逻辑单元，可
|
||
以包含一个或多个具体的数据项，通常作为一个整体进行存储、处理和分析。
|
||
数据元（素）是由一组属性规定其定义、标识、表示和允许值的数据单元。数据元通常用于构建一个语义正确、
|
||
独立且无歧义的特定概念语义的信息单元。数据元由对象类、特性和表示三部分组成。
|
||
[来源：GB/T18391.3-2009，3.3.36，有修改]
|
||
数据结构 data structure
|
||
数据结构是计算机系统中存储、组织和管理数据的一种方式，旨在实现一组相关数据元素之间的逻辑关系，并支
|
||
持高效的数据访问、修改和操作。
|
||
结构化数据 structured data
|
||
数据具有固定格式和明确的关系，通常存储在二维表格中，并遵循预定义的模型（如关系型数据库）。
|
||
非结构化数据 unstructured data
|
||
数据无固定格式，无法直接按规则解析，通常包含自然语言或二进制内容。
|
||
半结构化数据 semi-structured data
|
||
数据部分结构化，通过标签、标记或层级关系隐含一定逻辑，但无严格模式。
|
||
元数据metadata
|
||
元数据是描述数据的数据(或关于数据元素的数据)，用于解释数据的结构、含义、来源、规则、权属、易变性
|
||
等属性，是理解和管理数据的基础工具。
|
||
[来源：GB/T5271.17-2010,1706.05，有修改]
|
||
蒋亮亮
|
||
主数据master data
|
||
主数据是对企业核心业务实体标准化的关键数据，是跨系统、跨流程共享的关键信息（如油田、工区、并/井
|
||
筒、油藏、地层等业务类实体，客户、供应商、项目等管理类实体，以及设备、产品等资产类实体等），具有权威
|
||
性、稳定性和一致性。
|
||
参考数据 reference data
|
||
参考数据是指用于分类或分组其他数据的静态数据集，通常为预定义的标准化值，限定数据取值范围（如国家代
|
||
码、订单状态)，支撑数据一致性。
|
||
本文件中是指基于业务活动所产生的重要数据，与主数据构成“父-子”关系，并被主数据或业务数据引用。
|
||
数据服务data service
|
||
数据服务是指提供数据采集、数据传输、数据存储、数据处理（包括计算、分析、可视化等）、数据交换、数据
|
||
销毁等数据生存形态而演变的一种信息技术驱动的服务或例程(程序)。
|
||
数据服务接口 data service interface
|
||
数据服务接口是指计算机系统中为开放的特定业务数据而开发并发布的可供其他系统或应用调用的访问模式。
|
||
数据交换 data exchange
|
||
数据交换是指在应用软件与应用软件、应用软件与其他数据源之间建立数据通道，以实现数据的查询、获取与保
|
||
存。
|
||
数据交换模型 data exchange model
|
||
数据交换模型是指实现应用软件与应用软件之间、应用软件与其他数据源之间数据交换及其配套功能调用的通信
|
||
协议、交互模式或范式，包含接口协议、数据格式、传输机制等技术要素。
|
||
数据对象data object
|
||
数据对象在计算机科学和信息技术领域中是指能够被计算机程序处理的数据单元。数据对象是一个抽象的概念，
|
||
它并不直接对应于计算机内存中的具体位置，而是表示程序中可以操作的数据单元。数据对象是计算机系统中可以存
|
||
储和处理的数据实体，该实体可以是一个单一的数据元素或一组相关的数据元素的集合。数据对象通常有相应的数据
|
||
类型，用于定义数据对象可能包含的数值的种类，以及对这些数值进行的操作。
|
||
数据封装 data encapsulation
|
||
数据封装是指将待交换的数据对象包装成适合网络传输和交换主体之间便于快速有效识别的格式，而对原数据对
|
||
象添加标准化的描述性信息的过程。
|
||
数据解封装data decapsulation
|
||
数据解封装是数据封装的反过程，是指去掉已封装的数据对象中添加的描述性信息的过程。
|
||
领域数据管理服务 domain data management services
|
||
面向油气行业特定专业业务领域（如地震、测井等），基于领域知识体系构建的专业化数据服务，通过标准化接
|
||
口提供领域专属的数据处理、业务逻辑执行以及专业分析能力，满足专业领域内垂直方向上业务场景中的工业软件协
|
||
同和跨专业领域水平方向上业务场景中的数据共享与数据交换的需求。
|
||
租户 tenant
|
||
在云计算环境中的多租户架构中独立使用系统资源的业务实体，例如：油气企业下属子公司、合作单位或独立项
|
||
目组，其数据存储、计算资源及访问权限通过逻辑或物理隔离机制实现安全边界划分，确保不同租户间的数据与操作
|
||
互不影响。
|
||
数据域data domain
|
||
按油气行业业务属性或技术特征划分的数据逻辑分类单元，用于规范数据的存储策略、处理流程及服务边界，确
|
||
保地震、测井、油气藏等专业领域数据的标准化管理与跨系统协同。
|
||
4.缩略语
|
||
下列缩略语适用于本文件。
|
||
API: 应用程序编程接口 (Application ProgramminglInerface)。
|
||
gRPC：是由谷歌（Google）开源的一1
|
||
一个现代高性能远程过程调用(RPC)框架（Google Remote Procedure
|
||
状况检查和身份验证。
|
||
HTTP：超文本传输协议（Hypertext rnsfer Protocl)
|
||
HTTPS：超文本传输安全协议（HypertextTrnsferProtocol ecure 。
|
||
JSON： JavaScript对象表示法（JavaScript Object Notation)。
|
||
OpenAPI:开放API规范（OpenAPI Specification）。
|
||
RESTful: 表述性状态传递 (Representational State Transfer)。
|
||
TLS：传输层安全性协议（Transport Layer Security)
|
||
URL：统一资源定位符（Uniform Resource Locator)
|
||
5.总体要求
|
||
总体架构
|
||
数据服务接口设计和实现的总体架构如图1所示。
|
||
空制等代理服务
|
||
伤领层
|
||
集成层：效据集成与数据发布等代理服务
|
||
图1数据服务接口总体架构
|
||
-应用层为分布于云/非云环境中的业务管理、研究与决策场景或单个应用，例如：地震解释、钻井优化、综合
|
||
地质研究、资源评价等。
|
||
服务，支持业务数据的单个或组合调用及数据请求、鉴权、解封装等服务。
|
||
--传输层为基于工业物联网或互联网络，支持数据的可靠、安全和高效传输，兼容跨系统平台
|
||
(Windows/Liux/国产OS等）应用的数据传输需求。
|
||
一协议层为定义数据交换模型、安全协议及服务契约，确保数据交互接口的规范性、可靠性与安全性
|
||
一-数据接口服务为提供统一的数据存取访问、计算服务调用等核心功能。 通过服务中心的服务治理、安全控制
|
||
等保障标准化与安全性，支持多租户隔离与弹性扩展，满足数据协同需求。
|
||
一数据存储层集中管理油气各领域的核心业务数据资源，通过对数据的封装，为上层提供规范化的数据访问。
|
||
数据服务架构设计要求
|
||
数据服务架构设计应遵循以下要求：
|
||
一一模块化设计：应采用分层架构实现接口核心功能解耦，同时支持在云环境下运行；
|
||
一跨平台兼容：应支持国际以及国内常用操作系统运行环境；
|
||
－一协议中立性：应兼容HTTP及gRPC等主流协议；
|
||
一一数据标准化：应兼容行业已发布的其它数据标准。
|
||
业务域扩展要求
|
||
应通过模块化架构设计，支持专业业务领域（如：各种新能源业务）新增和快速接入，各领域通过插件化的数据
|
||
连接于适配器与各层实现便捷扩展。
|
||
功能与扩展要求
|
||
5.1 核心功能应满足
|
||
一一数据存取服务：应提供标准化的数据查询、读取、写入接口，服务的输出满足数据交换格式;
|
||
-一计算服务调用：应支持算法模型远程调用与计算资源调度
|
||
一一状态监控接口：应实时反馈系统运行状态与接口健康度。
|
||
5.2 业务领域数据服务扩展
|
||
各专业领域数据服务接口扩展，应基于本文件中的各项要求进行
|
||
-一专业领域数据交换模型，应按照各专业领域应用要求设置；
|
||
-一安全策略，应参考第8节安全要求设置。
|
||
6.数据交换模型要求
|
||
数据交换模型要求
|
||
数据交换模型模式应满足：
|
||
一一应使用JSON Schemar作为数据封装的描述语言（见参考文献2和参考文献3）;；
|
||
-一数据对象的结构定义应符合油气行业数据结构的相关规范要求；
|
||
-一一应标明数据交换模式版本，例如：schema":"htp:/son-schema.org/drft-7/schema"。
|
||
6.1 交换模型命名要求
|
||
数据服务交换模型命名宜采用不定长分段层次码作为命名规则，每个段层之间用字符“”进行连接，代码总长度
|
||
不宜超过30个字符。数据交换模型命名代码结构见图2
|
||
xxxxxxx
|
||
第三段(实体名称码)
|
||
第二段（子关胰定词)）.,
|
||
第一放（分类排）
|
||
图2 交换模型命名规则
|
||
a.第一段(分类码),，应使用专业分类作为命名分类码。
|
||
b．第二段（子类限定词)，用于说明交换模型分类，宜使用分类首拼字母或英文简写作为子类限定词。
|
||
C、第三段（实体名称码），用于说明数据对象，宜使用数据对象首拼字母或关键英文单词作为实体名称码。若采
|
||
用关键英文单词，最多不超过两个单词。
|
||
6.2 数据交换模型设计
|
||
数据交换主体之间进行数据交换时，应使用约定的数据交换模式对待交换的数据对象进行封装，交换后再进行解
|
||
封装。交换过程中应基于数据交换主体之间的请求（数据使用端）和响应（数据服务端）机制进行，内容包括请求信
|
||
息与响应信息。响应信息主要包括两种类型，一是正确地返回所请求的结果，即封装在数据交换模式中的数据对象
|
||
(体)；二是不能正确地返回所需要的结果时，则返回错误信息。
|
||
其中，待交换的数据对象（体）使用JSON格式报文形式（样例见附录A.1），错误返回信息采用自定义的JSON错
|
||
误代码描述格式（定义见附录B），具体要求如下
|
||
_一交换数据对象 (体)：应包括消息头及业务数据对象（体);
|
||
一一返回错误信息：应包括错误码、错误描述、错误原因分析及运行日志等信息。日志符合《GA/T911-2019信
|
||
息安全技术 日志分析产品安全技术要求》。
|
||
6.3 数据交换模型设计要求
|
||
数据交换模型应满足：
|
||
一一类型约束：应明确定义基础数据类及数据元素类等类型，油气专业数据类还应包括数据约束及量纲，安全设
|
||
计应符合《GB/T3634-2018信息技术数据质量》中的数据一致性要求；
|
||
一一元数据描述：每个数据模型应包含标准元数据属性；
|
||
二-组合结构：复杂数据对象应采用组合结构实现扩展。
|
||
6.4 数据分类交换模型结构及数据封装设计与方法
|
||
数据分类交换模型应按照以下四种数据对象大类进行设计，其中，数据交换模型根据数据结构分类对待交换的数
|
||
据对象进行封装和传输操作，其他分类以及分级信息作为数据对象的属性或标识性信息进行描述与封装。
|
||
一元数据类：除用于明确定义元数据所描述的数据对象外，还应包括数据结构分类类型，数据管理分级、数据
|
||
敏感性（或安全性）分级、业务分级以及业务关联信息等，对元数据的封装方法参见附录A.2。
|
||
(1数据对象元数据：宜包含数据对象名称、结构组成、元素及类型、元素约束条件、元素量纲等；
|
||
(2） 数据结构分类：宜包含结构化、非结构化、半结构化以及对象存储类等；
|
||
（3）数据管理分类：宜包含元数据、主数据、参考数据：
|
||
(4）数据敏感性（或安全性）分级：宜按照各企业相关的数据敏感性或安全性管理规定进行定义，例如：敏感/
|
||
非敏感数据，或保密(国家/企业/项目/个人秘密）/非保密数据（企业外部/企业内部等公开范围)，或公开共享/私有数
|
||
据 (企业/项目/个人)
|
||
（5）业务分级：应以油气数据业务逻辑为核心架构，主数据定义为关键业务实体（例如：油田、并筒、油藏等
|
||
核心对象），参考数据包含业务属性（例如：物性参数、测井曲线、地震解释成果等）及数据关联关系（例如：并区-
|
||
工区空间拓扑、油藏-生产动态逻辑映射)。
|
||
_一结构化数据类：是指按照二维表格方式存储的数据对象。对结构化数据的封装方法见附录A.3
|
||
-非结构化数据类：是指按照“非结构化数据描述信息头+非结构化或二进制数据体”存储的数据对象。对结构
|
||
化数据的封装方法见附录A.4。
|
||
一一半结构化数据类：是指按照“结构化信息头+非结构化或二进制数据体”存储的数据对象。对半结构化数据的
|
||
封装方法见附录A.5。
|
||
验证机制
|
||
数据交换模型应提供规范性验证机制，包括：
|
||
一一接口提供方：应公开JSON Schema定义端点，例如:：/schema/(model-type);
|
||
_一数据交换时：执行Schema验证，出错时返回标准的错误代码，见附录B。
|
||
版本管理
|
||
数据交换模型应支持版本管理，版本定义格式为“主版本号.次版本号.修订号”，变更要求如下：
|
||
一修订号变更仅涉及非功能性修改。
|
||
7.数据服务接口要求
|
||
通用技术要求
|
||
构成数据服务接口的技术实现应遵循以下要求：
|
||
一一接口描述语言：应使用OpenAPIi语法，用于定义接口契约;
|
||
三一数据序列化：应使用JSON格式，便于校验数据。
|
||
数据服务接口分类
|
||
7.1数据服务接口
|
||
数据服务接口应满足如下要求：
|
||
一-功能：应实现专业数据的可靠性存取，支持分页查询、条件过滤、版本回溯等数据操作；
|
||
实现模式：应遵循RESTful API设计原则，主要操作见表1。
|
||
一一接口组成：应包括接口名称、接口参数、返回码以及返回数据交换模型结构。
|
||
数据服务接口的核心组成要素、命名规则与设计要求见表1。
|
||
表1接口组成与命名
|
||
组成要素
|
||
命名规则与设计要求
|
||
示例
|
||
接口名称
|
||
义，例如：“GetV
|
||
'SubmitSeismic.ob.
|
||
HTTP方法
|
||
遵循RESTful规范：
|
||
GET /wells/{well_id)
|
||
GET：数据检索
|
||
POST：创建资源
|
||
PUT：更新资源
|
||
DELETE：删除资源
|
||
路径结构
|
||
格式：
|
||
：“专业)v版本号)资源类
|
||
/logging/v1.2/wells
|
||
型
|
||
-—专业：seismicprospecting,
|
||
-版本号：语义化版本，例如 v1.2
|
||
公共
|
||
必含字段
|
||
请求头
|
||
X-Tenant-ID：租户标识
|
||
"buu-oduo.al-ueua-x.
|
||
"bubbol. .ujewoa-ejea-X.
|
||
：Bearer令牌
|
||
路径参数
|
||
使用全小写+下划线命名，反映资源
|
||
/wells/{well_id)
|
||
唯一标识
|
||
支持过滤/分页/排序
|
||
查询参数
|
||
min_depth=1500&max_depth=200
|
||
一复数形式表示资源集合
|
||
("/wells )
|
||
一使用行业标准术语
|
||
`trajectory"而非`path’)
|
||
错误响应
|
||
结构化错误码（见附录B），包含
|
||
code、message
|
||
"code": 4001,
|
||
unit"
|
||
7.2计算服务接口
|
||
应提供计算服务接口的功能和接口协议：
|
||
一一功能：应提供专业的和高性能计算等种类的远程调用，支持异步任务管理与结果回调。
|
||
一一协议：应兼容高性能计算应用与通用应用，定义SubmitJob、GetJobStatus等方法。
|
||
7.3模型管理接口
|
||
应提供元数据管理接口，设计和安全原则包括：
|
||
一一功能：应包含管理数据字典、权限策略、接口版本等元信息，支持动态配置与审计追踪。
|
||
一一安全：应提供对敏感数据的访问限制。
|
||
数据服务接口开发设计
|
||
7.4 模式化设计
|
||
数据服务接口的开发，应按照6.1、6.2、6.3等技术与非技术要求进行设计，其中数据对象（体）的封装应按照
|
||
6.1.4中的相关要求进行。
|
||
7.5兼容性要求
|
||
数据服务接口设计应考虑版本和可扩展性的兼容性要求，即：
|
||
一一版本：数据服务接口调用的URL中嵌入版本号，例如：M1/datasets，且支持多版本共存与平滑升级；
|
||
-一扩展性：增加optional属性标记字段用于扩展，以提升与现有客户端的兼容性。
|
||
7.6服务质量要求
|
||
服务质量主要包括用户应用体验和服务性能等方面，其中服务性能主要是提高数据访问体验，可采取的技术措施
|
||
有
|
||
一分页：支持数据服务响应的分页控制；
|
||
-传输压缩：数据服务请求时，可根据数据体及类型选择是否压缩，以降低数据传输对网络带宽的占用;
|
||
一缓存策略：通过设置返回信息头中的数据缓存周期，定义数据在数据缓存中的存放周期，以提升数据服务效
|
||
数据服务接口管理与运维要求
|
||
数据所有权单位，应结合数据应用需求，在数据源端对数据服务接口设计、开发与应用等过程进行全生命周期管
|
||
理，对数据服务接口的应用质量进行跟踪和持续改进，对数据应用安全进行审计和应急处置。
|
||
8.数据服务接口安全要求
|
||
传输安全
|
||
数据服务接口应使用安全的传输协议和认证鉴权方法。
|
||
数据服务接口应提供对敏感数据的安全防护：
|
||
—-敏感字段加密：应采用字段级加密，宜使用符合《GB/T 32907-2016 信息安全技术 SM4分组密码算法》的
|
||
国密算法保障端到端安全。
|
||
一传输加密：宜配合认证鉴权对传输内容强制启用加密。
|
||
访问控制
|
||
数据服务接口应提供安全访问控制，提供包括但不限于数据增加、删除、修改和查询等权限的
|
||
附录A
|
||
(资料性)
|
||
数据交换JSON格式示例
|
||
A.1 JSON格式报文模式
|
||
JSON是一种常用的开放标准的文件格式和数据交换格式，是基于ECMAScript的一个子集设计的，它易于人阅读
|
||
和编写，同时也易于机器解析和生成。它在电子数据交换中有多种用途，包括与服务器之间的Web应用程序的数据交
|
||
换。其简洁和清晰的层次结构有效地提升了网络传输效率，使其成为理想的数据交换语言。
|
||
JSON独立于编程语言设计，很多编程语言都支持JSON格式的数据交换。其文件通常使用扩展名json。通过使
|
||
用JSON格式对待交换信息进行封装，以实现对信息的完整、快速、可靠传输，其中，对信息本体的描述采用“信息头
|
||
+信息体”的报文形式，举例如下。
|
||
请求报文
|
||
请求报文：
|
||
/响应报文
|
||
响应报文：
|
||
A.2元数据类JSON格式封装
|
||
"$schema": "https://ison-schema.org/draft-07/schema",
|
||
"title": "SeismicMetadata",
|
||
type" "objet",
|
||
'properties":
|
||
"id": (
|
||
'type": "string".
|
||
"format": "uid".
|
||
"description"："数据唯一标识符
|
||
_version":
|
||
'tye". "strin"
|
||
"patern":"\llld+$"
|
||
"example": "1.2.0"
|
||
"_acl": (
|
||
"properties":
|
||
buus madA}:swalm'Aeue mad:saumo,
|
||
'viewers": ("type": "array", "items": "type": "string"}
|
||
"required": ["owners"]
|
||
"Jlegal"r:
|
||
"type": "object"
|
||
"properties":
|
||
"clasication": "enum": [PUBLIC","CONFIDENTIAL", RESTRICTED),.
|
||
'retention_days": ("type": "integer", "minimum": 30}
|
||
"business_metadata": {
|
||
'type": "object",
|
||
"properties":
|
||
usssuouepe
|
||
(busadAweuAauns
|
||
"aep,ewoyu,us dAa aepuosnbom
|
||
"coordinate_system": ("type":"string","example": "EPSG:32650")
|
||
'required": ["survey_name"]
|
||
required":["_id","_version","business_metadata"]
|
||
元数据类JSON格式封装样例如下;
|
||
说明：
|
||
一系统元数据（前缀字段）：包含数据标识、版本控制、权限管理（ACL）及合规性标签；
|
||
一一业务元数据：定义地震工区名称、采集日期等业务属性，严格绑定seismic数据域;
|
||
-一符合核心元数据模型，支持多租户隔离（通过_acl.owners关联租户ID）。
|
||
A.3结构化数据类JSON格式封装
|
||
"$schma* :/schmas/wllog-data-2.0.son",
|
||
"header":
|
||
"bu!u-oqen.pueua,
|
||
'data":
|
||
"well_i" "W-2023"
|
||
'dept_unit": "m",.
|
||
'reference_point":
|
||
"": 432150.3,
|
||
"y": 356780.1,
|
||
"crs": "EPSG:32650"
|
||
"log_curves": [
|
||
"curve_name": "GR",
|
||
"unit": "API",
|
||
values": [65.3, 671, 70.5],
|
||
"depth_index":[1500.0 1500.1,1002].
|
||
"qultyflas": [0,1,0/0=正常，1-可疑
|
||
).,.eiepeiaur.
|
||
"tol,type": *x""
|
||
"Z::-p
|
||
结构化数据类JSON格式封装样例如下;
|
||
数据结构说明：
|
||
亚三wellore： 定义井筒基础信息及坐标;；
|
||
--og_curves：测井曲线数据，包含采样间隔、深度索引及质量标签。
|
||
A.4 非结构化数据类JSON格式封装
|
||
"file_reference":
|
||
"file_id"r"segy-8a3d"
|
||
"file_name"r"abc_3D.segy"
|
||
"file type": "SEGY",
|
||
"protocol": "s3","
|
||
'endpoint": "https://os.example.com",
|
||
"bucket": "seismic-raw"
|
||
"key": "2023/SS-2023-PB01.sgy"
|
||
"technical_metadata": (
|
||
fl_size_GB": 245.7,
|
||
'md5_hash": "a3d5e8f102.".
|
||
'trace_count":100000,
|
||
'sample_interval_ms": 4
|
||
'_security":
|
||
'encryption":
|
||
'algorithm": "SM4-CTR",
|
||
"key_id": "Kkms-001"
|
||
非结构化数据类JSON格式封装样例如下;
|
||
说明：
|
||
一一—采用引用式存储（非结构化数据本体存于对象存储，JSON仅封装元数据）;
|
||
一包含文件校验信息（MD5哈希）及加密状态声明。
|
||
A.5 半结构化数据类JSON格式封装
|
||
interpretation_report": {
|
||
"report_id":"IR-2023-001",
|
||
"bueuzsibojoa.".Joune,
|
||
"z00:0:801--opuoeo
|
||
"sections"
|
||
'ssieue anej. .aduooas,
|
||
'content": (
|
||
"fault id": "F-102"
|
||
'confidence": 0.85,
|
||
"annotations":
|
||
"text":"逆断层，断距约200m",
|
||
'position": ("rinline": 150, "xline": 320)
|
||
"attachments": [
|
||
半结构化数据类JSON格式封装样例如下；
|
||
兑明
|
||
一一自由格式内容与结构化字段混合存储；
|
||
一支持动态扩展字段，兼容未来新增业务属性
|
||
附录B
|
||
(资料性)
|
||
JSON关键字与错误代码描述
|
||
JSON关键字与错误代码描述见表B-1
|
||
表B-1JSON关键字与错误代码描述
|
||
JSON关键字
|
||
错误码
|
||
描述
|
||
type
|
||
4001
|
||
类型校验失败
|
||
required
|
||
4003
|
||
必填字段缺失
|
||
minimum/maximum
|
||
4002
|
||
数值越界
|
||
format
|
||
4004
|
||
自定义格式校验失败
|
||
uniqueltems
|
||
4005
|
||
数组元素重复
|
||
enum
|
||
4006
|
||
非法枚举值
|
||
参考文献
|
||
[1]国家发展改革委，中央网信办.关于推进“上云用数赋智”行动培育新经济发展实施方案》的通知（发改高技
|
||
（2020]552号）
|
||
https://www.ndrc.gov.cn/xwdt/ztzl/fkyqfgwzxdzt/fkgjdt/fgfc/202004/t20200410_1225542.html?
|
||
code=&state=123,(2020-04-07)
|
||
[2]JSON组织.JSON核心元模式定义Draft-O7（JSONSchemaDraft-O7）.https://jison-schema.org/draft-
|
||
07/schema.
|
||
[3]OSDU组织.OSDU数据定义（OSDUDATADEFINITIONS）.https://osduforum.org/osdu-data-definition-
|
||
documentation/.
|
||
[4]中华人民共和国数据安全法，2021.
|