随着科技的发展和环保要求的不断提高，矿山企业对资源的开采也有了更高的要求。为实现矿山企业信息化开采（于润沧等，2018）和绿色矿山（胡建军等，2012）的目标，建设数字矿山（卢新明等，2010）和智能矿山成为未来发展的必然趋势。然而在数字矿山建设过程中存在矿山地质、测量和采矿等全生命周期的业务数据缺乏统一的数据标准（周妍，2014），信息孤岛、信息断层以及业务流程不畅通等问题。因此，亟需构建一个业务数据标准化、工作流程规范化的矿山开采全生命周期业务管理平台，为矿山生产技术和管理提供统一的数字化作业环境，且业务数据能够按照工作流程在同一平台上自动流转，实现在整个矿山生命周期中各业务部门高效协作、业务信息的分布式集成以及数据互联互通、高度共享。因此，开展数字采矿协同技术研究十分必要。

国内外学者已从不同角度对数字采矿协同相关技术开展了研究。如在数据标准化处理过程中，针对XML技术具有可扩展性、结构性和独立性等特点，刘开南等（2007）和韩晓冰等（2009）采用XML技术对数字矿山的异构数据进行转换，王茹等（2002）使用XML Schema对数据命名、数据类型和数据结构进行约束，但并未解决数据转换后所需解析时间较长的问题。在矿山数据库部署方面，毕林等（2019）提出集中式存储方式，将矿山数据统一化组织管理，但随着平台业务复杂化、数据多样化，集中式存储数据存在数据追溯不清和海量数据管理困难等问题。在矿山功能模块部署方面，传统的单体架构将整个平台的功能模块视作整体，进行统一管理，但随着功能模块的增加，业务逻辑变得复杂化，单体架构难以实现功能模块之间的协同和功能模块的扩展。孙效玉等（2012）提出通过总控平台对应用进行集成，通过数据复制实现业务数据共享的方法，但其前提是需要构造共享信息结构，且存在数据传输量大以及难以保证共享数据质量等问题。赵志娟等（2015）提出基于SOA架构实现矿山异构数据的集成，使用企业服务总线（ESB）（谢继晖等，2007）将各应用相关联，采用XML技术对异构数据进行封装以实现标准化数据共享，但需要部署复杂的企业服务总线。Lu et al.（2008）分析总结煤炭企业信息化与数字矿山所面临的问题，并提出矿山企业信息化建设的总体布局。Singh et al.（2011）提出了基于建筑信息模型的多学科协作理论框架，叙述了协同多种学科的建筑项目的具体协同理论支持。Chen（2011）搭建了一个基于信息建筑模型作为协同平台的框架，提供了信息集成模型和系统的技术框架。Volk et al.（2014）对现有的建筑信息模型进行总结，并明确了构建建筑模型所面临的困难。因此。开展建筑信息模型的研究，为矿山行业借鉴建筑信息的模型从而建设矿山协同平台的框架奠定了基础。

综上所述，目前对于数字采矿协同相关技术的研究主要存在以下问题：数据标准化后占用的存储空间大、数据解析速度慢、信息难以溯源、数据传输效率不高、海量数据管理困难、业务软件协同程度低及业务边界模糊。为解决上述问题，本文以数字采矿协同平台为研究基础，通过对异构数据标准化和平台管理框架的分析，提出了一种基于JSON格式（孙书琼，2017）的分布式架构方法。该方法以数据标准化为基础，采用微服务架构（马雄，2017）部署业务与数据库，从而达到矿山业务高效协同与数据充分共享的目的。

传统的基于XML技术的异构数据交换方式具有良好的开放性、自描述性和可扩展性等特点，但也存在着一些不足，如：XML文件数据的冗余性高、解析速度慢及浏览器不兼容等问题。在选择标准化的数据格式时，其主要影响因素为标准化后数据占用的存储空间、传输时间、解析速度、查询时间和可读性等。本文采集了1 000条原始矿山数据，经过JSON和XML标准化处理后的对比结果如表1所示。由于JSON使用规范化的语法描述数据，而XML使用规范化的标签形式描述数据，因此对于JSON数据来说，不需要在解析时考虑数据的子节点和父节点，解析速度更快；此外，JSON结构更加简洁，所以数据存储空间更小、数据冗余更少且传输速度更快。通过对2种数据格式进行对比分析，最终选择JSON作为标准化数据格式。

基础数据标准化过程是采用规范化的语义、语法和结构对数据进行约束，通过组合使用键值对和“，”、“｛ ｝”、“［ ］”符号对一段数据进行描述，再结合JSON逻辑结构将数据段串联起来形成文档数据。具体实现过程如下：采集矿山源数据后，按照业务模块、业务类型和具体业务的层次依次划分为不同业务数据，再存储至数据库中。在标准化业务服务中调用JSON序列化函数将数据库中的信息转化为标准化JSON数据，然后使用JSON Schema对其标准化后的语法、语义格式进行验证，最后形成JSON文档存储至标准化数据库中。基础数据标准化流程如图1所示。

本文采用层次化方法描述数据。第一层由键值对表示业务模块，以区分不同业务协同模块；第二层为要素组，以定位至具体业务类型，如：矿孔设计和探矿巷道设计等；第三层则是要素类，是对要素组进行细分的单位元素。基础数据标准化示例如图2所示。在数据标准化后可根据JOSNiq或者JSONPath查询JSON数据，在存入数据库后可以通过业务模块、业务类型和具体业务对应的数值id所组合的ID值查询数据库中的数据。

在微服务架构中主要考虑服务配置、服务发现、权限控制、服务通信、调整服务负载和容错方案等功能。目前主流的微服务框架为Spring Cloud（郭致远等，2019）、gPRC、Dubbo（杨超，2017）、Motan和Tars，后4种框架属于RPC型框架，这类框架是通过通信协议像调用本地服务一样调用远程服务，从而实现高效可靠的传输服务。Spring Cloud框架是源于Spring boot（王永和等，2016）的一种RESTful型框架，是从资源角度对整体进行拆分，并为每个拆分后的模块设置特定的统一资源标识符。

Spring Cloud框架是功能组件的集合，包含Config Server、Eureka、Ribbon和Hystrix等组件。其中，Config Server组件提供配置功能，为软件开发创建不同的环境，提供@EnableConfigServer来启动配置；Eureka组件提供服务发现功能，实现不同业务服务之间的通信，提供@Enable Eureka Server和@Enable Eureka Client来启动配置，并使用Zuul来实现平台中的网关功能，实现外界访问功能，提供@EnableZuulProxy来启动；Ribbon组件用于实现平台的负载均衡，为系统与网络缓解压力，提供Rest Template实现负载均衡的配置；Hystrix组件用于实现平台的容错机制，在调用方法失败时提供解决策略，提供@HystrixCommand来启动断路由功能。相比之下，gPRC、Dubbo和Motan框架只实现了Spring Cloud框架的部分治理功能，而Spring Cloud框架为搭建微服务体系提供了全套功能。

通过对比分析4种微服务框架的关键技术（表2）发现，Spring Cloud中的Netflix Eureka组件相比Zookeeper来说不会有类似选举的过程，能够在减少维护工作量的同时保证Eureka的稳定性，且Spring Cloud与gPRC都自带可提供服务网关的组件。在负载均衡上，与其他组件相比，Netflix Ribbon更注重服务实例的请求并发处理。容错机制组件的Netflix Hystrix综合了服务超时、服务隔离和负载等情形，提供服务降级、熔断和线程隔离等容错技术，而其他组件主要考虑服务超时情况。因此，选取Spring Cloud作为协同平台的微服务治理框架。

微服务部署是将一些功能依据明确的业务边界划分为小而独立的服务，其主要目的是根据去中心化原则、隐藏内部实现细节原则、服务单独部署原则和可追踪原则，为矿山企业所需实现的业务管控各业务软件。在此基础上，通过Spring Cloud框架为微服务提供所需实现分布式架构的解决方案。

数字采矿协同平台（Wang et al.，2019）主要包括协同平台管理端、业务软件端和数据库设计3个部分。因此，在这3个部分中部署矿山服务及数据库，并采用服务结合数据库的方式搭建数字采矿协同平台，实现组件结合数据库共同部署的方式达到数据协同的效果。

数字采矿协同平台管理端如图3所示。管理端是协同平台的核心，综合管控矿山协同平台的基础数据、用户信息与权限、数据标准化、业务逻辑和业务流程等。管理端使用基础数据服务管理源数据，通过数据标准化服务将数据进行标准化处理。通过用户管理服务管理用户的注册信息、权限界限，使用自由协作服务实现不同的参与方跨部门、跨学科协同完成业务功能。业务流程服务对矿山生命周期所包含的地质、测量、采矿等各项业务流程进行创建、访问、发起、审批、提交和归档等管理。各个业务服务通过部署对应的数据库存储数据，如：基础数据数据库、用户信息与权限管理数据库、数据标准化数据库、业务协作管理数据库和业务流程管理数据库。

数字采矿协同平台业务软件端如图4所示。业务软件端是实现探矿设计（雷国才，2018）、地质编录（周智勇等，2013）、地质建模（武强等，2013）、储量计算（余璨等，2015）、出图设计和开采设计（谭正华，2010）6个方面的功能模块。其中，数据标准化数据库可划分为地质、测量和采矿3个模块的标准数据，并可进一步细分为钻孔设计数据、地质模型数据、储量估计数据、地形测量数据、井巷测量数据、空区测量数据、填充设计数据、爆破设计数据和开拓设计数据等。根据各业务服务可将标准化数据进行分类储存管理，来自不同厂商的业务数据可统一存储至服务对应的数据库中，从而实现真正意义上的数据协同，达到跨厂商数据的互联互通、高效管理的效果。

数字采矿协同平台架构如图5所示。该平台由源数据层、数据转化层、协同平台层、协同模块层和业务层构成。其中，源数据层用来存储不同厂商收集的矿山源数据，并将其分类存储；数据转化层是将各异构数据统一转化为标准化的JSON数据格式；协同平台层是在微服务架构下，以标准化的业务流程为准则，通过工具软件接口连接协同模块层中的软件处理业务流程中各业务。

JSON是一种轻量级的数据交换格式，它是独立于程序语言的文本格式，其语法规则包括数据命名规则、对象命名规则和数组命名规则。根据JSON结构的特点，通过循环嵌套JSON结构的方式来表述数据。JSON Schema是对JSON文档进行统一约束和规范，如对文档的命名规则和数据属性进行约束，经过约束后的文档才具备有效性。

微服务架构模式是一种组件化与服务化相结合的分布式模式，根据业务边界将整体模块划分为一组小的服务模式。该服务模式可以根据不同的业务单独部署服务和数据库，通过网络调用的方式完成服务之间的通信，使各服务之间相互协调、配合，并且独立运行。此外，微服务模式还具有较好的弹性需求，可对应用服务进行重组与扩展。

在完成不同业务部门基础数据的JSON格式标准化处理后，开始对整个矿山生命周期的标准化数据进行分类，将具有共同特性和关系的基本单元定义为要素。采用Spring Cloud框架管控平台部署矿山各业务服务和数据库，将海量矿山异构数据分类后，存储至对应的业务标准化数据库中，且各标准化数据库通过业务之间的通信功能实现数据的互联互通和高度共享。

数字采矿协同技术流程如图6所示。基本流程如下：

（1）采集地质、测量、采矿等业务所需的基础数据，将业务数据对象按要素组分类，再将要素组分解为要素类，要素类经过具体化形成要素，以要素为最小单元存储至数据库中。

（2）管控微服务的框架不仅需要为协同平台的分布式业务服务提供服务注册、服务发现、服务通信和部署服务等基础功能，而且还要提供实现模块扩展的功能，如API网关、负载均衡和容错机制等关键技术，因此需要选择管控协同平台的微服务框架。

（3）矿山数据的多源性导致异构数据的产生，而异构数据的集成是数据协同的基础，因此需要采用JSON格式标准化数据。

（4） 使用微服务架构模式部署协同平台管理端，管理端包含人员权限管理、业务流程管理和业务逻辑管理等服务及其对应的数据库。

（5）设计数字采矿协同平台管理端与软件端的接口，实现管理端与软件端之间的服务、服务与数据的相互访问。

（6）使用微服务架构模式部署协同平台软件端，软件端包含地质、测量和采矿等业务服务及其对应的数据库。

新疆阿舍勒铜矿在数字矿山建设中已采用三维矿业软件处理地质业务、测量业务、采矿业务和采掘计划业务等工作，但是在标准化业务流程指导下，出现业务软件协同程度不高、工作效率低下、海量数据难以管理和信息孤岛等问题，严重阻碍了矿山数字化、信息化与智能化进程。因此，迫切需要建设能够综合管控矿山地质、测量和采矿等业务的数字采矿协同平台。

基于异构数据标准化和数字矿山服务部署等研究工作，新疆阿舍勒铜矿数字采矿协同技术实现的主要步骤如下：采集业务基础数据并标准化、对文本进行约束形成规范化文档、使用微服务架构部署矿山服务与数据库、将数据存储至对应的数据库中、采用Spring Cloud框架管理微服务架构。在Windows平台下实现对新疆阿舍勒铜矿数字采矿协同平台的设计，得到阿舍勒铜矿后台管理端如图7所示。图7清晰地展示了平台以业务流程为驱动，在管理端将各业务软件调配后得到的采场的采掘进度情况，推进了矿山地质、测量和采矿等业务软件的协同工作。控制待办业务如图8所示，确定了业务人员、日期和业务类型等信息，通过审批、归档环节将各标准化数据按业务类别和形式存储至数据库中，保证了业务流程流转，提高了各参与方的合作能力。

通过对协同平台各业务分类后的基础数据进行标准化处理后，将数据存储至微服务架构部署的标准化数据库中，很好地解决了数字矿山所存在的数据转化困难、信息孤岛、数据管理困难和查询数据费时等问题。数据标准化保证了业务流程流转顺畅，提高了各部门跨学科的协作能力，实现了业务数据的高效协同，提高了矿山的工作效率。

（1）采用基于JSON的基础数据标准化处理以及基于微服务架构的业务服务与数据库部署，有效地解决了数字采矿协同平台的业务数据标准化、信息孤岛、海量数据管理困难、数据溯源困难和矿山软件业务协同度低等问题。从根本上降低了协同平台进行数据管理的工作量，同时提高了各部门人员跨学科、跨时空的协作能力，保证了业务流程流转通畅，提升了矿山企业的整体效率。

（2）微服务架构是部署数字采矿协同平台服务和数据库的核心。本文采用基于Spring Cloud框架的微服务架构，该架构提供了微服务构建所需的全部解决方案，具有可拆分整体业务、业务模块低耦合等特点，在满足业务软件开发的前提下，极大地降低了企业成本。

（3）微服务架构是分布式结构，是将整个平台拆分为组件化服务，但是如何将整体业务划分为独立的模块仍具有一定的难度。因此，下一步工作将重点对业务边界的划分进行研究。