1.本发明涉及大数据
技术领域：
：，具体涉及一种大数据边平台与方法。
背景技术：
：：2.数据标准体系是支持大数据发展和高级应用的重要基础，同时也是风(光伏)电场数据统计分析和管理的基础。通过开展数据标准化工作，建立公司数据标准体系，规范设备标准化、数据采集、传输及存储标准化及数据应用指标标准化，建立大数据边平台，全面提升数据质量，确保集控中心、应用平台、生产管理等系统数据真实有效，改善现阶段生产管理信息化建设过程中的数据问题。技术实现要素：3.为解决所述问题，本发明提供了一种大数据边平台和方法，有效避免了现有技术中无法确保集控中心、应用平台、生产管理等系统数据真实有效，无法改善现阶段生产管理信息化建设过程中的数据问题的缺陷。4.要克服现有技术中的不足，本发明提供了一种大数据边平台和方法的解决方案，具体如下：5.一种大数据边平台，包括：6.风力发电机组和与其通信连接的数据平台；7.数据平台和与其通信连接的集控系统；8.数据平台具有风电逻辑节点；风电逻辑节点包含：风电公用逻辑节点类、风电特殊逻辑节点类和逻辑设备类；9.在风力发电机组和数据平台之间还设置有采集网关。10.进一步的，所述大数据边平台，还包括：11.大数据边平台系统应能够接收物联网平台的时序、对象、业务等多源异构数据，针对不同格式、不同存储方式的数据，平台应能够提供多种数据接入通道，数据接入后经过内置的数据治理工具，应可实现数据标准化、去重、数据检查等清洗和治理步骤，依据数据分类及存储标准，应统一存储至大数据边平台系统，平台还应实现基于分布式架构上的并行查询、分析引擎，同时应能够实现海量数据的存储和计算，并应能够对外提供统一标准的api接口服务。12.进一步的，所述大数据边平台，还包括：13.用于新能源大数据特征的平台公共组件；其包含：分布式消息中间件、分布式文件系统、时序数据存储、流处理框架；14.进一步的，所述大数据边平台，还包括：15.可视化业务分析工具；16.所述可视化业务分析工具用于数据准备、自助式可视化数据分析、多种数据源整合以及可靠的分析性能；17.进一步的，所述大数据边平台，还包括：18.大数据边平台与集团云平台之间通过数据、管理、应用跨域协同的方式，实现云边之间的统一访问以及统一的数据、运营、运维管理；通过跨域协同，云平台可将边平台各类信息资源汇聚，形成合力进行集中的模型训练和应用研发；边平台可跨域共享云端的数据资源、各类自助式计算分析和研发组件资源、成熟模型和应用成果资源，云边之间按照统一的标准进行信息交互。19.进一步的，所述大数据边平台，还包括：20.大数据边平台数据协同接口包括数据协同服务接口、标准协同接口和数据模型协同接口；21.数据协同服务接口：数据协同服务主要负责数据跨域协同相关的功能，主要涵盖数据订阅接口、数据访问接口、数据集市接口、数据目录接口，这些接口主要支持云边协同下的数据资产管理；22.数据订阅接口：支持跨域的数据订阅协同请求；23.数据交换接口：支持云端和边端双向的数据交换；24.数据集市接口：支持协同模块之间跨域数据集市的浏览和集市相关的业务数据的获取；25.数据目录接口：负责协同模块之间关于标准目录相关的协调功能，包括标准目录的获取、目录内容的同步功能的集成。26.进一步的，所述大数据边平台，还包括：27.标准协同接口，标准协同服务主要负责数据标准跨域协同及数据质量管理的相关功能。28.一种大数据边平台的方法，包括：29.设备点位按以下三个层级划分：30.(1)基本点位；31.(2)故障预警及数据分析；32.(3)全量数据点；33.数据平台对不同机型的风机状态进行标准化处理，基于标准的风机状态进行过滤，所有设备数据在转发送到集控系统之前，需要对采集到的风机状态数据按照集控标准进行处理，再转发到集控系统中；34.事件标准化；35.告警功能应能够支持实现站端告警定义、计算并生成站端告警记录。包括但不限于遥测越限、异常告警、遥信变位告警等。并可通过配置模块对各遥测和遥信测点的告警规则，包括告警类型、告警级别、告警内容等，告警引擎对接收到的点根据告警引擎进行实时计算后对于满足条件的生成平台告警记录并存入告警实时库；36.数据采集、传输及存储标准化；37.信息模型构建：38.采用从上至下的抽象方法，将风电机组的具体功能层层分解和分类，抽象成最小功能单元的组合；39.分层的模型结构从上至下应分多个层次，包括但不限于逻辑设备、逻辑节点、数据类和数据属性。其中逻辑设备应是实体设备的功能抽象，由多个逻辑节点组成；逻辑节点应是风电机组内部最小功能单元的抽象，是相关数据类的集合；数据类应包含一套相关数据属性。40.进一步的，所述大数据边平台的方法，还包括：41.电场总体通讯模型，电场总体通讯模型规定了客户端和服务器之间信息交换所需要的内容；42.数据存储；43.数据应用指标标准化；44.数据应用指标标准化；45.数据采集与治理要求；46.数据采集；47.设备接入认证。48.进一步的，所述大数据边平台的方法，还包括：49.数据采集接入；50.进一步的，所述大数据边平台的方法，还包括：51.数据传输与转发：集控场站数据到大数据边平台系统的转发应包含数据传输、接收、存储、转发这样的环节，通过标准化数据链路各个环节，规定具体传输协议、接口技术、存储结构和机制；52.数据压缩加密：53.加密后的数据包中除了包括加密数据，还应该包括加密数据的校验数据；54.数据转发模式；55.数据传输节点状态监测；56.远程集中管理；57.通信调试。58.进一步的，所述大数据边平台的方法，还包括：59.数据标准化接入；60.数据治理；61.进一步的，所述大数据边平台的方法，还包括：62.业务计算功能，从而实现流处理服务、批处理和调度服务这样的功能；63.进一步的，所述大数据边平台的方法，还包括：64.平台管理；65.资源管理；66.业务监控；67.平台监控；68.用户管理；69.权限管理；70.配置管理；71.日志管理；72.告警管理；73.事件管理；74.安全管理。75.本发明的有益效果为：76.本发明集中台技术、数字功能、协同服务管理为一体，以分布式、微服务、容器云、devops及低代码开发等先进技术为支撑，将企业现有各种业务和数据能力进行融合，快速响应业务需求。有效避免了现有技术中无法确保集控中心、应用平台、生产管理等系统数据真实有效，无法改善现阶段生产管理信息化建设过程中的数据问题的缺陷。附图说明77.图1是本发明的一种电场总体通讯模型的原理图。78.图2是本发明的数据采集接入的流程图。79.图3是本发明的大数据边平台系统业务全景图。80.图4是本发明的平台总体架构规范图。具体实施方式81.下面将结合附图和实施例对本发明做优选地说明。82.标准和规范必须根据实际业务、需求情况而制订和修改，按照分类分级原则，对不同设备不同部件建立多级标准化规范，充分考虑后期点位扩展、技改等特殊情况，更新采集点标原则上不影响数据转发，这样才能使标准符合实际。标准的制订和修订要求准确实用，易于理解和执行，具有较强的可操作性。83.标准和规范的制订应继承和贯彻国家标准、行业标准，参考国际标准和国外先进标准。标准和规范的采用顺序是：先国家标准，后行业标准，最后是国际标准。84.由于大数据边平台系统建设是一个覆盖整个建投新能源生产管理业务的平台系统，相关业务都有其特点，同时需要考虑现有业务系统向新平台迁移的策略和措施，因此标准的制订和采用应具有前瞻性并成熟可用，满足易于扩展的需求，使之能满足新旧业务平台迁移，并适应建投新能源未来的发展变化。85.设备标准化应该包括但不限于：设备编码、设备点位、设备模型、设备状态、设备事件及报警处理等内容。投标方应提供不少于6种机型的数据标准化文档(至少包含设备点位、状态、事件)、升压站监控数据标准化(至少包含点位、状态、事件)文档、cms数据标准化文档。86.设备作为数据管理的基础，要实现数据规范化管理，必须建立标准的、统一的设备编码。87.设备点位标准化是指定义各种类型设备必须具有的点，如风机点位分遥测、遥信、遥脉、遥调、遥控5类。88.应按照设备类型(风机、光伏设备、升压站、箱变、测风塔等)和点类型(遥测、遥信、遥脉、遥调、遥控)来定义出设备点表标准化文档，在接入设备的时候，需要按照该标准点表来确定设备是否都具备了标准点表中的点位信息，如果有缺失，需要对风机plc进行解析或协调厂家开放标准中的点。89.设备点位标准化是公司当前已建和未来新建所有新能源场站的风电机组、光伏设备、箱变、升压站等设备的数据开放标准，制定点位标准化规范及标准化点表，夯实数据共享、整合基础，为数据深度应用提供必要支持，为后续新增设备的接入提供技术标准和指导，同时也是对设备设计原理的再研究，更加充分掌握设备状况，进一步保障设备可靠运行。90.标准点位在风机设备需要分为二类：直驱和双馈。91.如图1-图4所示，大数据边平台，包括：92.风力发电机组和与其通信连接的数据平台；93.数据平台和与其通信连接的集控系统；94.数据平台具有风电逻辑节点；风电逻辑节点应包含但不限于以下三部分：风电公用逻辑节点类、风电特殊逻辑节点类和逻辑设备类；95.风电公用逻辑节点类应包括物理设备所具有的所有公用信息和风能的独立信息。风电机组抽象出的各类信息都应该被封装在逻辑节点中，作为功能最小单元的逻辑节点构成了风电机组的功能组件。风电机组的高级功能应该由这些逻辑节点组合而成。96.风电场特殊逻辑节点应至少能够继承风电场公用逻辑节点的所有强制性信息。风电机组特殊逻辑节点除了能够包括风电机组必须的逻辑节点外，还应能够包括部分可选的逻辑节点来描述特定风电机组的功能特性。97.应能够根据风电场特殊的逻辑节点对风电场信息进行分类。原则上，风电场信息在不同逻辑节点上的分类是一个主观的过程，并且其建模方法也应该具有很大的灵活性。从标准化的角度来讲，采用清晰相同的建模方法则是更可取的。98.逻辑设备是风电机组子系统的抽象，应能够封装子系统中一组功能信息，并应能够将功能实体分解为最小功能单元(一组信息)以逻辑节点的形式存在。同时，逻辑设备还应该包含描述功能实体依附的物理设备实体的描述信息。因此，每个信息模型至少应包含一个逻辑设备，每个逻辑设备至少应包含两个必须的逻辑节点。99.在风力发电机组和数据平台之间还设置有采集网关。采集网关应具备以下主要作用和功能：100.(1)应能够通过标准规约采集设备数据。应能够支持目前主流规约(iec104、iec103、iec102、modbus-tcp、modbus-rtu、dnp3、opc-xml、opc-ua等)。101.(2)应能够通过非标准规约采集设备数据。在数据采集过程中会遇到部分设备的通讯规约是厂家自己定义的非标准规约，此时需要厂家提供数据采集方案，实现数据采集。102.(3)应能够实现信息模型标准化。103.(4)应能够支持其他系统模块或者第三方系统通过对标准化后的信息模型及信息交换模型进行数据交换。104.所述大数据边平台，还包括：105.大数据边平台系统应能够接收物联网平台的时序、对象、业务等多源异构数据，针对不同格式、不同存储方式的数据，平台应能够提供多种数据接入通道，以满足不同数据类型的个性化需求。数据接入后经过内置的数据治理工具，应可实现数据标准化、去重、数据检查等清洗和治理步骤，依据数据分类及存储标准，应统一存储至大数据边平台系统，平台还应实现基于分布式架构上的并行查询、分析引擎，同时应能够实现海量数据的存储和计算，并应能够对外提供统一标准的api接口服务。106.大数据边平台系统采应采用先进的大数据工具、技术框架，在满足系统高可靠、高可用、可扩展、安全稳定的前提下，应能够提供高负载和海量数据处理能力，支撑新能源行业对数据的抽取、转换、清洗、整合、分析、管理等各方面的需求。大数据边平台系统需建立数据门户，实现与应用平台系统、集控系统的单点登陆，在数据门户中方便快捷的实现数据总览、标准数据处理和服务等功能。107.平台应以数据集成为基础，以业务支撑为核心，通过数据探索和管理工具为用户提供服务，同时应将用户交互与后端处理业务隔离开来，降低各业务模块之间无关耦合。108.所述大数据边平台，还包括：109.用于新能源大数据特征的平台公共组件；其选型范围应包含但不限于：分布式消息中间件、分布式文件系统、时序数据存储、流处理框架；110.分布式消息中间件；111.消息队列中间件(简称消息中间件)是指利用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下起到应用异步通信、解耦、流量削峰、扩展性、冗余存储、可恢复性等等作用，其作为分布式系统架构中的一个重要组件，有着举足轻重的地位。112.平台应能够支持生产者-消费者模式、发布-订阅模式、api完备、支持多语言、大吞吐量、低延迟、高可用、理论上不会丢失，有配套运维工具、文档完备的消息中间件。113.分布式文件系统；114.平台应采用比较主流的分布式文件系统架构，并能够将广泛、稳定、部署简单、有图形化管理监控工具的分布式文件系统作为支撑。115.时序数据存储；116.时间序列数据(timeseriesdata，tsd，以下简称时序)从定义上来说，就是一串按时间维度索引的数据。用描述性的语言来解释什么是时序数据，简单的说，就是这类数据描述了某个被测量的主体在一个时间范围内的每个时间点上的测量值。它普遍存在于it基础设施、运维监控系统和物联网中。117.平台可选的时序数据库应包括但不限于influxdb、opentsdb、prometheus等。118.流处理框架；119.分布式流处理是对无边界数据集进行连续不断的处理、聚合和分析的过程，平台应采用主流的流计算框架如：sparkstreaming、storm、flink等。120.所述大数据边平台，还包括：121.可视化业务分析工具；122.大数据边平台系统应能够提供一个数据分析工具，通过可视化、易用性和创新性的方式让企业能够实现敏捷的业务智能分析。可视化数据分析工具应具备但不限于以下内容：123.所述可视化业务分析工具用于数据准备、自助式可视化数据分析、多种数据源整合以及可靠的分析性能；124.用户应能够通过界面的拖动的形式执行数据源的合并、取样、查重、语义矛盾等多种标准数据准备算法，同时应能够支持自定义规整算子的添加以及数据修改。125.自助式可视化数据分析应能够连接到一个或多个数据源，同时应支持单数据源的多表连接和多数据源的数据融合，可以轻松的对多源数据进行整合分析而无需任何编码基础。126.多种数据源整合应能够支持企业应用系统及数据仓库、数据集市的多数据源无缝整合，从而实现多个数据维度的交叉分析。业务分析工具还应能够满足多类数据源的接口，且不断补充与增加更多数据源接口，可以覆盖文件、关系型数据库、大数据等业内主流数据类型与数据源，支持的数据源种类应包括但不限于：关系型数据：oracle、postgresql、mysql、mongodb等；对象数据：olap、box等；文件数据：miscosoft文件、csv、pdf等；大数据边平台：hadoop、impala、spark等；sql文件：exasol、googlecloudsql等；编程文件：json、python、r等；数据抓取工具：apachedrill、tableau数据提取、progressopenedge等；127.分析组件的性能应能够满足数据量和分析效率的要求，同时应能够提供强大的性能调优工具，数据分析工具可以支持存储在平台中pb级数据可靠分析。128.可视化业务分析工具关键技术特性应包括但不限于：用户易用性、助式开发、数据的实时定时自动刷新、支持快速实现系统集成、支持订阅式邮件分发等。129.所述大数据边平台，还包括：130.大数据边平台与集团云平台之间通过数据、管理、应用跨域协同的方式，实现云边之间的统一访问以及统一的数据、运营、运维管理；通过跨域协同，云平台可将边平台各类信息资源汇聚，形成合力进行集中的模型训练和应用研发；边平台可跨域共享云端的数据资源、各类自助式计算分析和研发组件资源、成熟模型和应用成果资源，云边之间按照统一的标准进行信息交互，能够消除信息孤岛，助力集团数字化转型。131.跨域协同；132.数据协同：数据协同主要包括：标准规则、数据资产目录、数据资产三部分；其中，标准规则主要解决数据、元数据的标准和稽核规则的汇聚、审批、下发、执行；数据资产目录主要实现总部统一目录结构的跨域下发、汇总、访问等；数据资产跨域协同主要基于统一数据资产目录，实现数据资产的按需跨域申请及共享。133.应用协同：应用协同主要实现应用、模型、知识的跨域订阅、分发、接收和部署。134.管理协同：管理协同主要是实现跨域数据和应用的权限管理、节点管理、调度管理和运维管理。135.统一访问管理：集团内参与协同的各类数据、应用资产，由集团统一管理，提供统一的访问入口，并适用统一的资产访问安全控制。136.统一数据管理：对集团内全部云平台和边平台上的各类资产，包括数据资产、模型资产、应用资产，以统一的标准进行描述、共享。137.统一运营管理：对集团内全部云平台和边平台上的各类资产，提供统一的资产共享、交易系统及流程，以及协同任务调度管理。138.统一运维管理：对集团内全部云平台和边平台的运行状况进行统一监控，提供集团范围内各平台的远程维护、资源调度。139.通过数据标准集中制定跨域下发，数据目录分层汇聚统一管理，数据资产分布存储按需接入的方式，实现集团内外海量数据信息资源的统一汇聚，解决各级单位间信息资源无法共享与交互的问题和模型训练样本量不足的问题。通过对数据进行全流程的处理，搭建敏捷高效的开发环境，集中研发，统一运营、跨域部署，有效缩短应用研发周期，降低开发运维成本。整体架构遵循“四统一三协同”的规划要求，有利于于边平台建设的统一性、适配性、轻量性，同时也保留了边平台的扩展性，可以更好的满足业务需求。140.边平台需能够及时响应云平台提出的计算协同，任务协同及运维管理等业务要求，保证云平台对边平台的协同任务进行实时监控，有序调度及全面管理。通过管理协同，可实现模型在各个边平台的复用，保证各类跨域协同工作流统一管理和交互，实现云边统一运维管理，降低边平台研发和维护成本，提升管理效率。141.边平台需要具备模型的浏览、导入、编辑、导出、发布、评估的全流程管理能力，同时还能够及时响应云平台的相关调度任务。142.边平台需具备模型的导入/导出等模型管理能力，可基于图的形式查阅模型生成的全流程，支持模型的算法导入和文件形式的导出，保证模型能够在云边之间进行便捷的传输。143.边平台需支持模型发布：建立模型之后，可将模型发布到应用商店，供其他用户使用。其他用户在应用商店购买模型后，只需按照自身需求，对输入输出和模型参数进行配置后，即可使用。144.边平台需支持模型评估：在使用模型后，可用有标注的测试集对模型准确度进行评估，能够在评估结果中显示整体准确度、模型精确度、召回率等评估参数。145.边平台能够支持云平台对任务进行有效的调度管理，当出现多节点的协同任务时，需支持对各节点间的任务执行顺序，串/并发运行关系，调度计划等进行设置、编辑与修正。146.支持任务申请与提交，云平台根据任务类型，生成任务流程，存放在等待执行任务队列。147.支持边平台向云平台请求任务，云平台根据云平台节点组查找所属任务，向边平台下发任务，边平台根据任务流程进行具体步骤的匹配，并执行具体的任务，任务结束后，反馈给云平台。148.边平台需支持云平台对任务运行状态的统一监控与跟踪，包括但不限于：149.任务分解执行的位置。150.任务分解执行的进度。151.当前任务执行的状态。152.任务执行的历史记录。153.执行完毕时间。154.结果上传时间。155.边平台需支持任务执行完毕后的结果记录与回收，包括但不限于：156.手动执行：任务执行结束后，手动获取结果。157.自动返回：任务下发的目标平台，在运行结束后，主动提取回传结果到任务下发方平台。158.自动提取：下发任务的平台，根据下发任务的运行状态，在任务结束后，主动提取任务执行结果到本地。159.边平台需提供任务添加、任务队列管理的功能。可以添加实时任务、定时任务、cron任务、repeat任务、指定任务运行的执行端。任务队列管理功能提供了任务队列列表、任务编辑、暂停、任务删除的功能。160.边平台需具备任务的申请功能，能及时响应云平台发起的任务调度，并在任务执行过程中及时跟进完成进度，在任务节点进行催办提醒，能够让云平台监控到整个任务的执行过程。161.边平台在任务申请开始就要为任务发起方，任务接收方，以及集团侧云平台提供相关的任务信息，以便云平台进行任务跟踪，调度、控制与信息溯源。162.边平台数据任务的申请与执行：边平台能够访问云平台的数据资产目录，发起任务申请，待云平台审批通过后，执行任务。163.边平台需支持云平台的各种协同控制，包括：数据筛选条件、数据量、协同期限、数据安全措施、数据同步更新控制等。支持根据数据维度筛选，以及根据数据资产内部字段结构提供条件筛选。支持选择获取部分字段信息。164.边平台需为云平台提供基于数据筛选条件进行统计的功能，在发起协同请求前预先确认协同的效果。在协同申请阶段，不能查询实际数据。165.边平台在任务执行过程中，需支持任务催办提醒功能，包括但不限于：任务执行进度的提醒，标识当前执行状态和任务执行负责人，并能通过点击该项任务发送邮件提醒或进行手机短信提醒，还能通过任务的紧急程度点选不同任务提醒方式，电话，语言，邮件，短信等。166.边平台需提供基本的运维管理功能，包括但不限于操作系统/数据库/中间件监控，并提供相应的运维管理接口，与总部云平台的统一运维管理平台进行对接，支持总部对本地系统的相关信息监控。167.边平台需支持集团侧云平台对用户，组织机构，协同权限和节点拓扑信息的统一管理。并能与集团paas平台/大数据信息资源平台的统一权限认证功能进行对接。168.边平台应支持对本节点内的用户及角色进行授权和基础信息配置。169.边平台应支持集团云平台对边平台的用户，组织机构及协同权限的访问，查阅，控制，及授权管理，授权对象可以是个人也可以是组织。170.边平台需提供用户/组织机构信息同步功能，将已有的信息直接导入到协同用户，组织机构管理的模块中，并与数据库中的用户信息保持一致。只要进行跨域协同的用户/组织，就需要满足管理协同的同步要求。171.边平台权限任务的申请与执行：边平台用户可提交权限申请，包含数据协同权限，应用协同权限，管理协同权限，协同基础权限的申请，包含但不限于角色信息，申请内容等，并支持申请内容的添加，删除，编辑，基础信息管理等功能。172.边平台可支持云平台对权限申请的流程进行审批，查阅，与过程监控。173.边平台需支持云平台对本节点的使用权限进行管理与设置。174.边平台需具备节点注册/注销能力，并能自行测试节点是否连接成功。175.边平台需提供节点资源管理器，使云平台获知本节点的运行状态。支持shell和批处理的各种环境，适配于各种管理策略，支持交互、批处理、串行及并行的作业方式。176.边平台需具备对本节点的创建、修改、编辑能力，并进行相应的节点信息配置。177.边平台可支持云平台根据节点名称、节点层级关系绘制集群拓扑图。能够以拓扑方式显示节点之间的关联关系。178.边平台应支持和云平台之间的信息检测，显示节点通信状态，并能通过点击该节点进行监控信息的查阅，包括但不限于ip地址，角色，配置，分组，资源用量，执行时间及节点运行状态信息。179.边平台需能够接收并解析云平台下发的各类数据标准、目录标准及质量规则，同时，能够将本地的元数据信息、资产目录、数据质量稽核过程和报告、数据资产等内容同步至云平台。通过落实数据协同要求，在集团全域范围内共享一套数据资产目录和标准，有利于数据资产在集团内的共享流通，提升边平台数据质量，形成良性数据管理循环，降低数据管理工作强度，最终达到边平台数据资产价值的最大化。180.边平台应具备本地的标准管理能力，应能解析集团按照标准格式规范打包下发的数据标准成果，并支持标准浏览与应用。支持解析集团所下发的标准类别包括但不限于：181.字典类标准：字典类标准范围包含但不限于测点中文名称、测点缩略语、测点编码、测点分类、设备分类、标准业务维度等。字典类标准为结构化数据表。182.文件类标准：文件类标准格式包含但不限于doc、docx、pdf、xml。183.数据目录标准：数据目录标准包括标准目录的层级结构、数据资源实体标准元信息以及元数据字典等内容。数据目录标准为结构化数据表的形式。184.编码规则标准：编码规则标准为具有特定格式的描述文件，该文件中包含了码段组信息、码段信息、码段位数要求、码段取值规则表达式等信息。包括但不限于设备编码规则、测点编码规则等。185.边平台应能将本地数据资源按照集团标准组织成目录并上传至集团和创新中心侧。同时，边平台应能解析其他节点跨域协同的数据资源，并纳入本地的数据目录。186.边平台侧应具备数据资产目录管理功能，用于建立本地目录并上传至集团；包含但不限于目录标准引用、本地目录构建、资产元信息配置、目录浏览与查询等能力。187.边平台侧应能引用集团所下发的数据目录标准，并以标准的目录层级作为分类基准，将本地的数据资源，配置到标准目录层次相应的类目中；也可将标准目录层次作为标签，配置到每个数据资源的元信息中，并根据标准化标签解析目录层级结构。集团所下发的标准目录层次包含多个视角，包括但不限于业务板块、业务域、数据来源、所属组织等；数据资源的类型需支持但不限于结构化数据、时序数据、小文件、文件等。188.边平台侧应根据集团所下发的标准，将数据资产元信息配置完整，信息包括但不限于数据类型、数据标识、安全属性、数据加工处理过程记录等；同时，边平台应能记录数据溯源信息，并能将溯源信息作为元数据协同至云平台，用于在云平台侧生成全集团的数据地图，展现所有数据的血缘关系。189.边平台需要支持结构化数据及时序数据的质量稽核，用以控制跨域数据传输中的数据合法性。能力包括但不限于：190.边平台应能接收总部下发的各类校验规则及质量稽核模型，并解析执行，对本平台内纳管的数据进行质量稽核。191.边平台应能生成质量评估报告，报告中应提供各项数据的质量处理过程及质量评估结果，使云平台能够追溯数据的演化过程。192.质量报告应为结构化形式，支持云平台侧按照标准格式规范进行解析。193.边平台应用协同要求主要是为了满足云边协同的应用协同，重点是针对从应用商店下载或下发的应用提出的协同要求。194.通过应用协同，边平台可以充分利用应用商店的已有应用来满足业务需求，降低新开发应用所需的资金投入、人力投入，减少资源依赖和接口协调，降低运维门槛，实现从关注平台到关注业务，提升边平台应用价值，产生更大的经济效益和社会效益。195.在满足应用部署要求的前提下，通过应用协同可以将一个独立应用，同步到多个不同的云、边平台运行；将一个组合应用，配置到不同边平台运行，可通过调度策略，在本地按照跨域调度策略执行，将结果返回，并可按照组合应用进行统一跟踪管理。196.边平台应用至少支持以容器化方式部署，也可以选择容器包模版和saas应用等形式进行接入。197.边平台可支持容器化技术及微服务架构。平台功能组件及开发成果可支持容器化部署，以便为租户快速部署环境，将应用在租户间进行快速推广。边平台的服务支持以微服务方式提供，用户可以基于边平台开发新的微服务；边平台可选择提供容器编排和微服务治理能力。198.应用模型从云平台下装到边平台时，边平台必须遵循预先定义好的运行规范和部署规范。运行规范包括具备云边协同框架预先定义好的基础技术架构，包括操作系统、基础数据平台、环境设置等信息，以及对应的版本要求。部署规范包括应用模型的描述、应用模型打包规范等。199.边平台可选择支持容器包应用模版部署；提供一键部署能力，可以配置相应的部署策略，提供边平台升级必须遵循的运行规范和部署规范，后端预先有响应的运行集群环境。200.根据需求选用saas服务方式运行的应用系统进行对接。边平台提供接口可以支持第三方应用的接入，普通用户统一将第三方应用的相关信息录入到边平台，录入成功后，提交发布，由云平台的管理员审核，审核通过后相关应用信息直接可在云平台的应用商店中预览，可进行订阅，收藏的功能。201.用户购买应用后，在权限范围内，能够自主选择应用部署位置。202.所述大数据边平台，还包括：203.大数据边平台数据协同必备要求的接口，包括数据协同服务接口、标准协同接口和数据模型协同接口；204.数据协同服务接口：数据协同服务主要负责数据跨域协同相关的功能，主要涵盖数据订阅接口、数据访问接口、数据集市接口、数据目录接口，这些接口主要支持云边协同下的数据资产管理；205.数据订阅接口：支持跨域的数据订阅协同请求；206.数据交换接口：支持云端和边端双向的数据交换；207.数据集市接口：支持协同模块之间跨域数据集市的浏览和集市相关的业务数据的获取；208.数据目录接口：负责协同模块之间关于标准目录相关的协调功能，包括标准目录的获取、目录内容的同步功能的集成。209.所述大数据边平台，还包括：210.标准协同接口，标准协同服务主要负责数据标准跨域协同及数据质量管理的相关功能。主要集成接口如下：211.标准发布接口：当有新的规范标准发布，或者已有规范有更新时，云平台通过此接口通知边平台，边平台能够接收相关标准并进行在本站点内的发布，自动成为标准的最新版本；212.数据模型协同接口：213.数据模型协同服务主要负责业务数据模型的跨域交换，边平台需要支持数据模型发布接口，通过此接口云平台能够把已经发布的数据模型同步到指定的边平台，边平台能够接收相关数据模型并进行在平台内发布，自动成为相关的数据模型的最新版本。214.管理协同服务必须满足任务协同接口及协同基础接口的要求，以满足国家电投云边管理协同的要求，同时对应用形成的结果数据按照数据协同接口进行跨域协同。215.任务协同接口：任务协同服务主要负责跨域任务协同相关的功能，需要注意的是此功能基于协同基础模块上实现，需要同步全集团统一的用户和组织机构，来实现管理协同中的任务协同要求，主要集成接口如下：216.申请任务接口。217.任务跟踪接口：支持提交的跨域协作申请状态的跟踪，并支持提醒和催办的功能。218.协同基础接口：协同基础接口主要负责跨域场景中，各个协作节点中协同相关的配置，服务的监控以及服务的管理和运维，安全基础信息的集成等，通过标准化的协同基础接口，实现统一跨域节点的集成和管控，来实现管理协同的基础信息管理要求，主要集成接口如下：219.拓扑同步接口：支持云平台推送整个集团的平台拓扑信息到各个边平台。220.协同监控接口：支持各种跨域服务的健康状态监控，服务请求负载监控，数据流量监控等，以统一的运维接口提供给统一运维平台。接口说明，见附录a.2.3协同监控接口部分说明。221.用户和组织机构同步接口：支持大数据信息资源平台中的用户，组织机构信息的同步，确保身份认证的统一。222.一种大数据边平台的方法，包括：223.设备点位按以下三个层级划分：224.(1)基本点位：作为监控系统的最基本的点位，应包括实现基本信息监视及控制、能量管理、指标计算及分析功能；225.(2)故障预警及数据分析：应满足应用平台现有的故障预警、分析及公司目前分析业务需求；226.(3)全量数据点：包括但不限制于1和2的数据点，智能设备时代，具有更多的传感器，采集传输更多的设备点位，未来大数据及ai智能时代，数据产生更多的价值；227.点位属性应包括但不限于以下内容：228.(1)iec路径名称229.(2)编码230.(3)中文名称231.(4)英文名称232.(5)值类型233.(6)单位234.(7)上限235.(8)下限236.(9)计算公式237.(10)位置238.(11)是否保存239.(12)是否要有1秒数据240.(13)是否要有10分钟量241.采集的传感器(主要为大部件或重要安全传感器)应包括但不限于：温度传感器、振动传感器、电流电压传感器、转速传感器等。传感器采集标准除点位标准外还应包含以下内容：242.必要属性：243.(1)位置244.(2)分类245.(3)传感器名称246.(4)测点247.(5)数量248.非必要属性：249.(1)采样间隔250.(2)采样时长251.(3)数据形式252.(4)对外传输253.(5)传感器分辨率254.(6)传感器量程255.设备模型256.设备模型是指设备的组织架构形式，设备应包括风机、升压站、测风塔、箱变、逆变器、汇流箱等等。257.例如风机设备，需要设置该风机设备所属线路、线路所属的电场、电场所属的区域、区域所属集团等树形组织架构模型。258.设备需要设定是否是标杆、是否是虚拟设备、是否属于多个电场。259.同一个设备可能归属到不同的电场，同一个电场在调度和业主方叫不同的名称，需要在设备模型中灵活配置设备与风电场，方便集控归集不同的设备。260.在报表、统计分析中需要根据设备组织模型区分设备归属，计算相应数据及出统计分析数据。261.设备模型具备继承功能。262.设备状态263.状态标准化：应按设备类型定义设备状态标准化，如风机状态，目前系统将风机状态分为两大类，只要具有状态的设备，都需要定义该类设备的状态标准。数据平台对不同机型的风机状态进行标准化处理，基于标准的风机状态进行过滤，所有设备数据在转发送到集控系统之前，需要对采集到的风机状态数据按照集控标准进行处理，再转发到集控系统中；264.事件标准化：应制定统一的事件处理标准和统一的事件划分类别。应将事件划分为故障、警告和提示三种级别，并定义事件所属设备；265.事件码应该统一定义，一个事件码应该表示的是一个明确的事件(例如：风机设备的10001事件码表示塔底温度高，事件类别为警告)。266.告警功能应能够支持实现站端告警定义、计算并生成站端告警记录。包括但不限于遥测越限、异常告警、遥信变位告警等。并可通过配置模块对各遥测和遥信测点的告警规则，包括告警类型、告警级别、告警内容等，告警引擎对接收到的点根据告警引擎进行实时计算后对于满足条件的生成平台告警记录并存入告警实时库；267.每条告警信息应包含但不限于以下内容268.(1)场站269.(2)设备270.(3)等级271.(4)类型272.(5)告警代码273.(6)告警内容274.(7)开始时间275.(8)结束时间276.数据采集、传输及存储标准化；277.数据采集规约标准化，是指约定设备厂家以特定的规约传输设备原始数据，保证数据稳定高效传输。对比目前主流的电力行业规约(cdt、iec101、iec104、modbustcp和dnp3)。278.信息模型构建：目前国际上比较通用的方案为cim模型(通用信息模型)和iec61400-25(风电)iec61850(变电站)的信息模型。由于iec61400-25是专为风电做的国际标准，推荐在系统中使用该信息模型，方便多厂家(国内、国外)和多系统(不同的业务系统)数据通讯及系统整合。以上所列信息模型仅供参考，应该依据现场实际提供详细的信息模型以及标准化的信息模型标准文档。279.信息交换机制依赖标准化的风电信息模型。这些信息模型以及模型化方法是内部信息接入、处理及传输的核心。信息模型应能够标准模拟实际部件的信息，并定义所有可以同其他部件进行交换的可用信息。此模型应能够为风电场自动化系统提供一个真实世界(如叶轮、偏航系统、发电机等)的映像。280.信息模型内部规约的方法应该是将功能分解为交换信息的最小实体。一台风力发电机(ied)的部件多少由风电机组配置决定。这些部件被称作逻辑节点(例如风轮部件可以虚拟表示为标准化类名wrot)，它可以通过概念性应用层面来模拟和定义。逻辑节点应集中在诸如代表完整风力发电机组这样的逻辑设备之中。281.根据风电通信业务的流向，通信业务大致可分为本地通信和远程通信。风力发电机组由多个功能系统组成，包括风机系统、发电系统、并网系统、气象系统等。每个系统包含多种内部功能和外部关联。如风机系统包括了变桨功能、偏航功能，其中变桨功能又存在与发电系统主轴力矩、气象系统风速、并网系统功率控制的外部关联。总体而言风电机组是由模块化的子系统和子系统间分布式实现的功能组成。282.针对这样的系统结构，应该采用从上至下的抽象方法，将风电机组的具体功能层层分解和分类，抽象成最小功能单元的组合，功能的实现应能够依附于具体的物理设备但不应局限于单台物理设备或系统；这样的抽象方式能够使得风电机组成为了逻辑功能而不是具体设备的组合，逻辑功能的高内聚、低耦合特性能够使得系统运行的交互性和适应性得到了提升。283.分层的模型结构从上至下应分多个层次，包括但不限于逻辑设备、逻辑节点、数据类和数据属性。其中逻辑设备应是实体设备的功能抽象，由多个逻辑节点组成；逻辑节点应是风电机组内部最小功能单元的抽象，是相关数据类的集合；数据类应包含一套相关数据属性。284.所述大数据边平台的方法，还包括：285.电场总体通讯模型，电场总体通讯模型规定了客户端和服务器之间信息交换所需要的内容；通过该框架服务器可以处理风电场提供的用于外部监控的所有数据，并将这些数据处理为相关的标准语义信息，准予客户端以部件导向的方法访问这些数据。设备的多样性，与设备的通讯方式多样性，设备所使用的规约也具有多样性，同一种规约还有不同的变种，比如南瑞103和四方103；因此应采用国际标准的统一的设备信息模型、信息交换模型和规约映射。286.不同厂家不同规约的设备接入系统后，应根据如cim、iec61850、iec61400-25等的信息模型，将设备统一模型化，然后通过信息交换模型将信息交换映射到国际标准规约(101、104、dnp3)与其他系统系统交换信息，方便其他系统或者第三方系统接入。287.数据存储；288.数据存储标准是指对存储在存储介质中数据的存储与交换方法，数据存储的需求及其定义方法、数据格式要求和存储实现技术等进行标准化定义。存储标准的确定及规范化有利于数据的管理、存储、分类和提取。289.系统应能够存储三个类别的数据：毫秒级数据(风机故障录波数据)、1秒级数据、5秒级数据，其中1秒级数据应能够存储1个月，5秒级数据应能够长期存储，毫秒级数据以投标厂家scada是否支持为准。290.系统可设置归档策略，热数据、冷数据的设置可灵活配置。291.系统能够通过将原始运行数据按照周期进行数学计算，形成相应的汇总数据并存储，运行时再通过周期数据生成日数据、月数据、年数据，以及各种定制化周期的统计数据，用于统计报表和数据分析。292.数据应用指标标准化；293.系统应能够综合各项生产指标，建立基础数据应用标准，基础数据应用是指依据设备原有数据，进行简单逻辑计算和处理后得出的数据，如功率曲线、故障时间、风机发电量等等。这些数据对设备(风机、光伏设备等)运行分析有着重要作用，数据来源分为三部分——风机plc计算、风机scada计算、应用系统计算等，基础数据应用标准化是对目前所用的经过逻辑计算后的数据进行梳理，重新定义并明确算法公式、取点位置、逻辑处理标准，进而制定公司级指标统计标准，为上层应用提供直接的数据与指标展示。294.指标：应包含但不限于标准空密平均风速(m/s)、等效小时数、pba(能量可利用率)、tba(时间可利用率)、mtbf(平均无故障运行时间)、mttr(平均故障修复时间)、发电量、上网电量、不可用损失电量、故障损失电量、限电时间、限电损失电量、理论功率等。并应按照统一原则分风电场分设备类型而制定个性化标准。295.数据应用指标标准化；296.系统应能够综合各项生产指标，建立基础数据应用标准，基础数据应用是指依据设备原有数据，进行简单逻辑计算和处理后得出的数据，如功率曲线、故障时间、风机发电量等等。这些数据对设备(风机、光伏设备等)运行分析有着重要作用，数据来源分为三部分——风机plc计算、风机scada计算、应用系统计算等，基础数据应用标准化是对目前所用的经过逻辑计算后的数据进行梳理，重新定义并明确算法公式、取点位置、逻辑处理标准，进而制定公司级指标统计标准，为上层应用提供直接的数据与指标展示。297.指标：应包含但不限于标准空密平均风速(m/s)、等效小时数、pba(能量可利用率)、tba(时间可利用率)、mtbf(平均无故障运行时间)、mttr(平均故障修复时间)、发电量、上网电量、不可用损失电量、故障损失电量、限电时间、限电损失电量、理论功率等。并应按照统一原则分风电场分设备类型而制定个性化标准。298.数据采集与治理要求；299.现场能够通过标准化点表，以统一和规范的数据采集规约和协议，接入现场数据采集网关，同时能够在集控中心为原先的集控系统提供统一的数据，并且通过正向隔离转发到三区的数据平台。300.大数据边平台系统应能够实现公司下属所有集控数据接收、数据存储、数据评价及数据治理。依据中间层数据接收、存储规范及公司现有应用系统特性，制定大数据边平台系统相应的标准。大数据边平台系统通过打通系统各个环节和各个业务的交互，实现数据统一的管理和数据之间的共享；为集控中心、应用平台、生产管理等系统提供高质量的数据。投标方应在投标阶段提供总体架构图给招标方。301.对于现场数据，应采用厂家数据转发方式。数据接入之前，应对厂家开放点位的数量、质量以及厂家数据接口的稳定性进行评估。302.数据采集；303.数据采集内容：大数据边平台系统数据采集范围应包括但不限于：升压站、风机(含监控和能量管理)、箱变、光伏设备、agc、avc、故障录波、功率预测、cms、测风塔、环境监测仪、电计量等。304.设备接入认证；305.设备接入需要进行接入认证，认证项目包括但不限于以下内容：306.(1)设备上电联网后，需要一个认证激活过程；307.(2)设备向采集网关申请激活，包括相应的激活信息；308.(3)采集网关判断并通过激活，根据诸多信息生成全局唯一的设备编码，如果是重复激活，需要根据唯一编码查到上一次分配给该设备的设备编码；309.(4)采集网关告知设备激活成功，并下发设备编码，设备永久保存设备编码；310.(5)设备多次激活，编码不变；311.(6)设备激活以后，每一次连接采集网关，必须提交设备编码，防被拦截窃取；312.(7)在注册设备时，用户自定义或系统自动生成的设备标识；313.(8)为设备创建私钥，并将私钥存放至一个安全地库；314.(9)每个设备都必须拥有唯一的公钥和私钥；315.(10)由系统认证的密钥不能用于其他目的或通过其他协议进行通信；316.(11)当设备被重置时，密钥必须被撤回。317.所述大数据边平台的方法，还包括：318.数据采集接入；数据采集性能保障包括：数据采集网关必须提供高效的数据转发、可靠的告警上送、完整的数据转存、高可用的服务支撑等功能，同时支持安全数据上送通道。并且保证数据采集的高效性、可靠性、完整性和安全性能要求。319.所述大数据边平台的方法，还包括：320.数据传输与转发：集控场站数据到大数据边平台系统的转发应包含数据传输、接收、存储、转发这样的环节，通过标准化数据链路各个环节，规定具体传输协议、接口技术、存储结构和机制，确保数据结构合理并提供通用型数据转发接口，为后续大数据边平台系统建设提供数据保障；321.数据压缩加密：数据在传输过程中不能使用明码，需要对数据通讯进行加密和验证，对其安全性进行保障。322.加密后的数据包中除了包括加密数据，还应该包括加密数据的校验数据，防止其在传输中被篡改；在加密包中，有些非关键数据可以不进行加密，方便其在转发时可快速进行数据的识别而无需解密，能够提高传输效率。323.数据传输过程中还应该支持压缩传输，提高传输效率，避免带宽不足的情况对系统的使用产生影响。324.在数据的采集和传输过程中，因为设备、通讯等方面的原因，可能会造成数据丢失、失真，对最终的数据统计、分析造成较大影响。所以在数据使用前，首先需要对数据进行质量检查和统计，提交给系统，必要时通知相关人员，帮助其进行相应的处理，提高数据的质量。325.数据质量的检查算法应包括但不限于阀值范围检查、数据丢失检查、离散数据检查、增量值域(跳变)检查。各检查之间相互独立，互不影响，数据应可以同时被赋予多种检查属性。326.数据质量的统计算法包括数据完整率、及时率、有效率统计等。327.数据转发模式；328.大数据边平台系统应能够提供统一、通用的数据转发接口及标准，各系统依据自身需求，应能够自由选择数据接入标准。大数据边平台系统应配置多个接口，避免硬件重复建设，满足数据转储要求。要求可以转发至国家电投云平台，确保让云平台识别并使用。329.数据传输节点状态监测；330.大数据边平台系统应部署传输节点监测。在数据传输过程中，平台对通道是否可用具备监测功能。协议内部规约也应具备对于数据包完整性、连续性的检验，对数据包是否完整进行校验。校验失败后，平台应再次请求数据上送。331.在一、二区监控界面中，应能够调用数据传输节点监测模块，对传输节点的可用性和数据质量指标进行展示。332.远程集中管理；333.系统应能够提供基于web的集中配置中心，实现远程通讯配置，数据调试，设备接入；在保证相应网络和端口畅通的前提下修改配置参数等操作；平台自动同步。334.通信调试。335.系统应能够通过登录配置管理中心web页面，实现远程设备接入通讯调试。通讯调试模块应基于web页面提供丰富调试功能，满足各种设备接入时的数据调试需求。336.主要功能应包括但不限于：337.(1)原始数据、计算数据实时查看；338.(2)对接入测点进行人工模拟置数；339.(3)规约通讯报文实时查看，下载；340.(4)通讯日志实时查看，分析；341.(5)连接网络测试，包括网络通讯测试，端口测试，tcp连接查看等。342.所述大数据边平台的方法，还包括：343.数据标准化接入；344.数据接入是数据可用性的基础，系统应能够实时接入的实现结构化和非结构化的数据。系统应能够将物联网平台采集的时序数据，如光伏组件监测数据、风力发电机组监测数据、升压站监测数据等，接入到数据服务平台的时序数据存储中。时序数据的采集和接收，要求单机吞吐高，每条记录不丢不重，在单点故障发生的情况下，不应该影响时序数据的持续接入。同时，由于工业数据质量普遍存在问题，要求数据质量治理应能够在采集和接收“前端”完成，逐条核查时序数据的质量，避免“垃圾进－垃圾出”，采集到对于分析挖掘质量不合格的数据。根据用户使用的场景，数据服务平台应能够对时序数据提供至少以下三种接入方式：实时接入、批量接入和定时批量接入。系统应能够将传输过来的对象数据，如视频监控数据、日志文本数据等，接入到数据服务平台的对象数据存储中。应能够在平台中接入关系数据，对于支撑实际业务需求，实现异构数据间的关联分析具有现实意义，将物联网平台传输过来的业务数据接入到数据服务平台。投标方应在投标阶段提供详细的关系数据接入步骤。规则引擎应能够帮助用户灵活地转发和处理设备消息，用户可通过sql的形式设定规则，对消息数据筛选、变型、转发，应能够根据不同场景将数据无缝转发至不同的数据目的地，如时序数据库、物接入主题、机器学习、流式处理、对象存储和关系型存储等。平台应能够实现模型管理、资产树管理、告警等功能。345.数据治理；346.系统的数据治理工作，应能够对数据进行存储、插补、清洗、计算，并统一标准和口径，形成标准数据，建立基础模型、融合模型和挖掘模型，实现数据异常规则设定、异常监控告警、数据日志记录等，并且进行数据质量评价，形成数据质量报告，实现跨领域数据融合。现场数据到大数据边平台系统后，平台应能够同时存储原始数据及标准化数据，一是确保集控中心等实时监控系统与现场保持一致，二是给其他应用分析系统提供标准化数据；对于其他应用系统数据，大数据边平台系统应能够利用数据汇聚工具，抽取必要数据，一是可以对重要数据进行异地备份，二是可以进行数据的综合分析。347.数据治理至少应能够达到以下具体效果：348.(1)数据缺陷随时掌握,及时发现；349.(2)缺陷数据能够得到及时修正；350.(3)数据流过程具有详细的日志记录，历史数据可追溯；351.(4)数据修正过程进行标记，实现修正过程可追溯恢复；352.(5)数据实现多版本管理，解决统计口径问题；353.(6)方便分析数据缺陷原因，定时提供数据缺陷报告，提出解决方案；354.(7)数据治理完成后数据采集平台可用率达到99％以上。355.所述大数据边平台的方法，还包括：356.业务计算功能，从而实现流处理服务、批处理和调度服务这样的功能；357.(1)流处理服务：358.流处理服务应能够充分满足处理设备和资产的实时数据，以及经离线消息通道集成的数据的需求。359.应能够基于大规模分布式集群的实时处理能力，并应能够集成可视化的流数据处理任务设计、调试、部署及监控工具。大数据边平台系统应可以沉淀一系列通用及领域相关的流计算算子，覆盖多领域核心场景需求。数据开发工程师应能够快速组合出不同的数据处理方案，降低数据开发障碍、缩短数据研发周期。360.数据处理服务还应能够实现规则和配置加载、提供相关支持工具等功能。361.(2)批处理&调度服务：362.批处理又称批计算，是指对平台中离线批量数据的并行计算，过程中会调用数据清洗、聚合、专用算法等平台计算算子，实现数据标准、数据挖掘、应用服务等数据批量处理的功能。363.大数据边平台应能够提供批处理框架，应包概括但不限于mapreduce和spark，从而能够分别响应不同的批处理场景。364.批计算服务应能够配合调度服务，实现用户的可用性需求。其中，作业是批计算的调度服务的主体，是调度服务中被执行任务的统称。平台提供的调度服务应能够覆盖作业的全生命周期管理，包括但不限于作业的定义、运行监督、结果查询等。365.所述大数据边平台的方法，还包括：366.平台管理；367.平台管理功能应主要包括但不限于资源管理、业务监控、平台监控、平台用户管理、权限管理、配置管理、日志管理等。368.资源管理：用户在创建时会被赋予默认的资源量以满足基本操作，如需扩展或调整集群的能力，应能够在线进行资源的申请，扩容，管理等操作；369.业务监控：应包括监控平台上的业务应用运行情况、平台上的数据云图、数据质量等；370.平台监控：应能够对集群进行管理，如添加、删除节点等操作；应能够监控集群的健康情况，对设置的各种指标和系统运行情况进行全面监控；应能够对大数据的多组件进行整合；还应能够对集群出现的问题进行诊断，对出现的问题给出建议解决方案；371.用户管理：平台管理的用户分为两大类，一类是平台运维人员，一类是平台之上的应用。平台应能够指定用户的有效期、是否禁用；如果是应用用户应能够限定应用的mac地址。平台还应提供用户的查询、增加、修改、删除等操作；372.权限管理：平台权限管理应能够支持对管理工具的权限管理和对平台数据(包括元数据和业务数据)的权限管理；373.配置管理：应能够实现大数据边平台的各种组件(flume、kafka、hive、hbase、hdfs、spark、yarn、zookeeper等)及应用(流计算规则引擎规则配置、预警模型参数配置、调度模块配置、应用告警规则配置、平台监控指标配置、绩效分析指标配置等)的配置项的增加、修改、删除以及查看；374.日志管理：系统应能够提供日志记录功能；应能够采集组件接口的日志记录、日志查询等；当应用已部署至某环境时，还应能够通过点击各服务的查看日志按钮查看服务日志详情；375.告警管理：系统应能够提供告警功能；376.事件管理：即告警服务模块。应能够接收设备上送的事件类信息，能够提供事件的存储，查询，订阅，推送等服务，同时也应支持对接入到平台的实时数据定义产生事件的规则，以满足实时告警，故障分析等业务需求；377.安全管理。378.系统应能够提供安全管理功能，包括但不限于：用户认证、设备认证、应用鉴权、授权管理、账户生命周期管理(账户创建，编辑和删除)、多组织用户管理(组织用户都作为一个组织单位进行管理)等内容。379.大数据边平台特殊要求380.大数据边平台可通过跨域协同的方式和国家电投集团云平台实现跨域协同的方式，构建成完整的云边协同工业大数据边平台。381.以上以用实施例说明的方式对本发明作了描述，本领域的技术人员显而易见的是，本公开不限于以上描述的实施例，在不偏离本发明的范围的状态下，能够做出各种变动、改变和替换。当前第1页12当前第1页12
技术领域：
：，具体涉及一种大数据边平台与方法。
背景技术：
：：2.数据标准体系是支持大数据发展和高级应用的重要基础，同时也是风(光伏)电场数据统计分析和管理的基础。通过开展数据标准化工作，建立公司数据标准体系，规范设备标准化、数据采集、传输及存储标准化及数据应用指标标准化，建立大数据边平台，全面提升数据质量，确保集控中心、应用平台、生产管理等系统数据真实有效，改善现阶段生产管理信息化建设过程中的数据问题。技术实现要素：3.为解决所述问题，本发明提供了一种大数据边平台和方法，有效避免了现有技术中无法确保集控中心、应用平台、生产管理等系统数据真实有效，无法改善现阶段生产管理信息化建设过程中的数据问题的缺陷。4.要克服现有技术中的不足，本发明提供了一种大数据边平台和方法的解决方案，具体如下：5.一种大数据边平台，包括：6.风力发电机组和与其通信连接的数据平台；7.数据平台和与其通信连接的集控系统；8.数据平台具有风电逻辑节点；风电逻辑节点包含：风电公用逻辑节点类、风电特殊逻辑节点类和逻辑设备类；9.在风力发电机组和数据平台之间还设置有采集网关。10.进一步的，所述大数据边平台，还包括：11.大数据边平台系统应能够接收物联网平台的时序、对象、业务等多源异构数据，针对不同格式、不同存储方式的数据，平台应能够提供多种数据接入通道，数据接入后经过内置的数据治理工具，应可实现数据标准化、去重、数据检查等清洗和治理步骤，依据数据分类及存储标准，应统一存储至大数据边平台系统，平台还应实现基于分布式架构上的并行查询、分析引擎，同时应能够实现海量数据的存储和计算，并应能够对外提供统一标准的api接口服务。12.进一步的，所述大数据边平台，还包括：13.用于新能源大数据特征的平台公共组件；其包含：分布式消息中间件、分布式文件系统、时序数据存储、流处理框架；14.进一步的，所述大数据边平台，还包括：15.可视化业务分析工具；16.所述可视化业务分析工具用于数据准备、自助式可视化数据分析、多种数据源整合以及可靠的分析性能；17.进一步的，所述大数据边平台，还包括：18.大数据边平台与集团云平台之间通过数据、管理、应用跨域协同的方式，实现云边之间的统一访问以及统一的数据、运营、运维管理；通过跨域协同，云平台可将边平台各类信息资源汇聚，形成合力进行集中的模型训练和应用研发；边平台可跨域共享云端的数据资源、各类自助式计算分析和研发组件资源、成熟模型和应用成果资源，云边之间按照统一的标准进行信息交互。19.进一步的，所述大数据边平台，还包括：20.大数据边平台数据协同接口包括数据协同服务接口、标准协同接口和数据模型协同接口；21.数据协同服务接口：数据协同服务主要负责数据跨域协同相关的功能，主要涵盖数据订阅接口、数据访问接口、数据集市接口、数据目录接口，这些接口主要支持云边协同下的数据资产管理；22.数据订阅接口：支持跨域的数据订阅协同请求；23.数据交换接口：支持云端和边端双向的数据交换；24.数据集市接口：支持协同模块之间跨域数据集市的浏览和集市相关的业务数据的获取；25.数据目录接口：负责协同模块之间关于标准目录相关的协调功能，包括标准目录的获取、目录内容的同步功能的集成。26.进一步的，所述大数据边平台，还包括：27.标准协同接口，标准协同服务主要负责数据标准跨域协同及数据质量管理的相关功能。28.一种大数据边平台的方法，包括：29.设备点位按以下三个层级划分：30.(1)基本点位；31.(2)故障预警及数据分析；32.(3)全量数据点；33.数据平台对不同机型的风机状态进行标准化处理，基于标准的风机状态进行过滤，所有设备数据在转发送到集控系统之前，需要对采集到的风机状态数据按照集控标准进行处理，再转发到集控系统中；34.事件标准化；35.告警功能应能够支持实现站端告警定义、计算并生成站端告警记录。包括但不限于遥测越限、异常告警、遥信变位告警等。并可通过配置模块对各遥测和遥信测点的告警规则，包括告警类型、告警级别、告警内容等，告警引擎对接收到的点根据告警引擎进行实时计算后对于满足条件的生成平台告警记录并存入告警实时库；36.数据采集、传输及存储标准化；37.信息模型构建：38.采用从上至下的抽象方法，将风电机组的具体功能层层分解和分类，抽象成最小功能单元的组合；39.分层的模型结构从上至下应分多个层次，包括但不限于逻辑设备、逻辑节点、数据类和数据属性。其中逻辑设备应是实体设备的功能抽象，由多个逻辑节点组成；逻辑节点应是风电机组内部最小功能单元的抽象，是相关数据类的集合；数据类应包含一套相关数据属性。40.进一步的，所述大数据边平台的方法，还包括：41.电场总体通讯模型，电场总体通讯模型规定了客户端和服务器之间信息交换所需要的内容；42.数据存储；43.数据应用指标标准化；44.数据应用指标标准化；45.数据采集与治理要求；46.数据采集；47.设备接入认证。48.进一步的，所述大数据边平台的方法，还包括：49.数据采集接入；50.进一步的，所述大数据边平台的方法，还包括：51.数据传输与转发：集控场站数据到大数据边平台系统的转发应包含数据传输、接收、存储、转发这样的环节，通过标准化数据链路各个环节，规定具体传输协议、接口技术、存储结构和机制；52.数据压缩加密：53.加密后的数据包中除了包括加密数据，还应该包括加密数据的校验数据；54.数据转发模式；55.数据传输节点状态监测；56.远程集中管理；57.通信调试。58.进一步的，所述大数据边平台的方法，还包括：59.数据标准化接入；60.数据治理；61.进一步的，所述大数据边平台的方法，还包括：62.业务计算功能，从而实现流处理服务、批处理和调度服务这样的功能；63.进一步的，所述大数据边平台的方法，还包括：64.平台管理；65.资源管理；66.业务监控；67.平台监控；68.用户管理；69.权限管理；70.配置管理；71.日志管理；72.告警管理；73.事件管理；74.安全管理。75.本发明的有益效果为：76.本发明集中台技术、数字功能、协同服务管理为一体，以分布式、微服务、容器云、devops及低代码开发等先进技术为支撑，将企业现有各种业务和数据能力进行融合，快速响应业务需求。有效避免了现有技术中无法确保集控中心、应用平台、生产管理等系统数据真实有效，无法改善现阶段生产管理信息化建设过程中的数据问题的缺陷。附图说明77.图1是本发明的一种电场总体通讯模型的原理图。78.图2是本发明的数据采集接入的流程图。79.图3是本发明的大数据边平台系统业务全景图。80.图4是本发明的平台总体架构规范图。具体实施方式81.下面将结合附图和实施例对本发明做优选地说明。82.标准和规范必须根据实际业务、需求情况而制订和修改，按照分类分级原则，对不同设备不同部件建立多级标准化规范，充分考虑后期点位扩展、技改等特殊情况，更新采集点标原则上不影响数据转发，这样才能使标准符合实际。标准的制订和修订要求准确实用，易于理解和执行，具有较强的可操作性。83.标准和规范的制订应继承和贯彻国家标准、行业标准，参考国际标准和国外先进标准。标准和规范的采用顺序是：先国家标准，后行业标准，最后是国际标准。84.由于大数据边平台系统建设是一个覆盖整个建投新能源生产管理业务的平台系统，相关业务都有其特点，同时需要考虑现有业务系统向新平台迁移的策略和措施，因此标准的制订和采用应具有前瞻性并成熟可用，满足易于扩展的需求，使之能满足新旧业务平台迁移，并适应建投新能源未来的发展变化。85.设备标准化应该包括但不限于：设备编码、设备点位、设备模型、设备状态、设备事件及报警处理等内容。投标方应提供不少于6种机型的数据标准化文档(至少包含设备点位、状态、事件)、升压站监控数据标准化(至少包含点位、状态、事件)文档、cms数据标准化文档。86.设备作为数据管理的基础，要实现数据规范化管理，必须建立标准的、统一的设备编码。87.设备点位标准化是指定义各种类型设备必须具有的点，如风机点位分遥测、遥信、遥脉、遥调、遥控5类。88.应按照设备类型(风机、光伏设备、升压站、箱变、测风塔等)和点类型(遥测、遥信、遥脉、遥调、遥控)来定义出设备点表标准化文档，在接入设备的时候，需要按照该标准点表来确定设备是否都具备了标准点表中的点位信息，如果有缺失，需要对风机plc进行解析或协调厂家开放标准中的点。89.设备点位标准化是公司当前已建和未来新建所有新能源场站的风电机组、光伏设备、箱变、升压站等设备的数据开放标准，制定点位标准化规范及标准化点表，夯实数据共享、整合基础，为数据深度应用提供必要支持，为后续新增设备的接入提供技术标准和指导，同时也是对设备设计原理的再研究，更加充分掌握设备状况，进一步保障设备可靠运行。90.标准点位在风机设备需要分为二类：直驱和双馈。91.如图1-图4所示，大数据边平台，包括：92.风力发电机组和与其通信连接的数据平台；93.数据平台和与其通信连接的集控系统；94.数据平台具有风电逻辑节点；风电逻辑节点应包含但不限于以下三部分：风电公用逻辑节点类、风电特殊逻辑节点类和逻辑设备类；95.风电公用逻辑节点类应包括物理设备所具有的所有公用信息和风能的独立信息。风电机组抽象出的各类信息都应该被封装在逻辑节点中，作为功能最小单元的逻辑节点构成了风电机组的功能组件。风电机组的高级功能应该由这些逻辑节点组合而成。96.风电场特殊逻辑节点应至少能够继承风电场公用逻辑节点的所有强制性信息。风电机组特殊逻辑节点除了能够包括风电机组必须的逻辑节点外，还应能够包括部分可选的逻辑节点来描述特定风电机组的功能特性。97.应能够根据风电场特殊的逻辑节点对风电场信息进行分类。原则上，风电场信息在不同逻辑节点上的分类是一个主观的过程，并且其建模方法也应该具有很大的灵活性。从标准化的角度来讲，采用清晰相同的建模方法则是更可取的。98.逻辑设备是风电机组子系统的抽象，应能够封装子系统中一组功能信息，并应能够将功能实体分解为最小功能单元(一组信息)以逻辑节点的形式存在。同时，逻辑设备还应该包含描述功能实体依附的物理设备实体的描述信息。因此，每个信息模型至少应包含一个逻辑设备，每个逻辑设备至少应包含两个必须的逻辑节点。99.在风力发电机组和数据平台之间还设置有采集网关。采集网关应具备以下主要作用和功能：100.(1)应能够通过标准规约采集设备数据。应能够支持目前主流规约(iec104、iec103、iec102、modbus-tcp、modbus-rtu、dnp3、opc-xml、opc-ua等)。101.(2)应能够通过非标准规约采集设备数据。在数据采集过程中会遇到部分设备的通讯规约是厂家自己定义的非标准规约，此时需要厂家提供数据采集方案，实现数据采集。102.(3)应能够实现信息模型标准化。103.(4)应能够支持其他系统模块或者第三方系统通过对标准化后的信息模型及信息交换模型进行数据交换。104.所述大数据边平台，还包括：105.大数据边平台系统应能够接收物联网平台的时序、对象、业务等多源异构数据，针对不同格式、不同存储方式的数据，平台应能够提供多种数据接入通道，以满足不同数据类型的个性化需求。数据接入后经过内置的数据治理工具，应可实现数据标准化、去重、数据检查等清洗和治理步骤，依据数据分类及存储标准，应统一存储至大数据边平台系统，平台还应实现基于分布式架构上的并行查询、分析引擎，同时应能够实现海量数据的存储和计算，并应能够对外提供统一标准的api接口服务。106.大数据边平台系统采应采用先进的大数据工具、技术框架，在满足系统高可靠、高可用、可扩展、安全稳定的前提下，应能够提供高负载和海量数据处理能力，支撑新能源行业对数据的抽取、转换、清洗、整合、分析、管理等各方面的需求。大数据边平台系统需建立数据门户，实现与应用平台系统、集控系统的单点登陆，在数据门户中方便快捷的实现数据总览、标准数据处理和服务等功能。107.平台应以数据集成为基础，以业务支撑为核心，通过数据探索和管理工具为用户提供服务，同时应将用户交互与后端处理业务隔离开来，降低各业务模块之间无关耦合。108.所述大数据边平台，还包括：109.用于新能源大数据特征的平台公共组件；其选型范围应包含但不限于：分布式消息中间件、分布式文件系统、时序数据存储、流处理框架；110.分布式消息中间件；111.消息队列中间件(简称消息中间件)是指利用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下起到应用异步通信、解耦、流量削峰、扩展性、冗余存储、可恢复性等等作用，其作为分布式系统架构中的一个重要组件，有着举足轻重的地位。112.平台应能够支持生产者-消费者模式、发布-订阅模式、api完备、支持多语言、大吞吐量、低延迟、高可用、理论上不会丢失，有配套运维工具、文档完备的消息中间件。113.分布式文件系统；114.平台应采用比较主流的分布式文件系统架构，并能够将广泛、稳定、部署简单、有图形化管理监控工具的分布式文件系统作为支撑。115.时序数据存储；116.时间序列数据(timeseriesdata，tsd，以下简称时序)从定义上来说，就是一串按时间维度索引的数据。用描述性的语言来解释什么是时序数据，简单的说，就是这类数据描述了某个被测量的主体在一个时间范围内的每个时间点上的测量值。它普遍存在于it基础设施、运维监控系统和物联网中。117.平台可选的时序数据库应包括但不限于influxdb、opentsdb、prometheus等。118.流处理框架；119.分布式流处理是对无边界数据集进行连续不断的处理、聚合和分析的过程，平台应采用主流的流计算框架如：sparkstreaming、storm、flink等。120.所述大数据边平台，还包括：121.可视化业务分析工具；122.大数据边平台系统应能够提供一个数据分析工具，通过可视化、易用性和创新性的方式让企业能够实现敏捷的业务智能分析。可视化数据分析工具应具备但不限于以下内容：123.所述可视化业务分析工具用于数据准备、自助式可视化数据分析、多种数据源整合以及可靠的分析性能；124.用户应能够通过界面的拖动的形式执行数据源的合并、取样、查重、语义矛盾等多种标准数据准备算法，同时应能够支持自定义规整算子的添加以及数据修改。125.自助式可视化数据分析应能够连接到一个或多个数据源，同时应支持单数据源的多表连接和多数据源的数据融合，可以轻松的对多源数据进行整合分析而无需任何编码基础。126.多种数据源整合应能够支持企业应用系统及数据仓库、数据集市的多数据源无缝整合，从而实现多个数据维度的交叉分析。业务分析工具还应能够满足多类数据源的接口，且不断补充与增加更多数据源接口，可以覆盖文件、关系型数据库、大数据等业内主流数据类型与数据源，支持的数据源种类应包括但不限于：关系型数据：oracle、postgresql、mysql、mongodb等；对象数据：olap、box等；文件数据：miscosoft文件、csv、pdf等；大数据边平台：hadoop、impala、spark等；sql文件：exasol、googlecloudsql等；编程文件：json、python、r等；数据抓取工具：apachedrill、tableau数据提取、progressopenedge等；127.分析组件的性能应能够满足数据量和分析效率的要求，同时应能够提供强大的性能调优工具，数据分析工具可以支持存储在平台中pb级数据可靠分析。128.可视化业务分析工具关键技术特性应包括但不限于：用户易用性、助式开发、数据的实时定时自动刷新、支持快速实现系统集成、支持订阅式邮件分发等。129.所述大数据边平台，还包括：130.大数据边平台与集团云平台之间通过数据、管理、应用跨域协同的方式，实现云边之间的统一访问以及统一的数据、运营、运维管理；通过跨域协同，云平台可将边平台各类信息资源汇聚，形成合力进行集中的模型训练和应用研发；边平台可跨域共享云端的数据资源、各类自助式计算分析和研发组件资源、成熟模型和应用成果资源，云边之间按照统一的标准进行信息交互，能够消除信息孤岛，助力集团数字化转型。131.跨域协同；132.数据协同：数据协同主要包括：标准规则、数据资产目录、数据资产三部分；其中，标准规则主要解决数据、元数据的标准和稽核规则的汇聚、审批、下发、执行；数据资产目录主要实现总部统一目录结构的跨域下发、汇总、访问等；数据资产跨域协同主要基于统一数据资产目录，实现数据资产的按需跨域申请及共享。133.应用协同：应用协同主要实现应用、模型、知识的跨域订阅、分发、接收和部署。134.管理协同：管理协同主要是实现跨域数据和应用的权限管理、节点管理、调度管理和运维管理。135.统一访问管理：集团内参与协同的各类数据、应用资产，由集团统一管理，提供统一的访问入口，并适用统一的资产访问安全控制。136.统一数据管理：对集团内全部云平台和边平台上的各类资产，包括数据资产、模型资产、应用资产，以统一的标准进行描述、共享。137.统一运营管理：对集团内全部云平台和边平台上的各类资产，提供统一的资产共享、交易系统及流程，以及协同任务调度管理。138.统一运维管理：对集团内全部云平台和边平台的运行状况进行统一监控，提供集团范围内各平台的远程维护、资源调度。139.通过数据标准集中制定跨域下发，数据目录分层汇聚统一管理，数据资产分布存储按需接入的方式，实现集团内外海量数据信息资源的统一汇聚，解决各级单位间信息资源无法共享与交互的问题和模型训练样本量不足的问题。通过对数据进行全流程的处理，搭建敏捷高效的开发环境，集中研发，统一运营、跨域部署，有效缩短应用研发周期，降低开发运维成本。整体架构遵循“四统一三协同”的规划要求，有利于于边平台建设的统一性、适配性、轻量性，同时也保留了边平台的扩展性，可以更好的满足业务需求。140.边平台需能够及时响应云平台提出的计算协同，任务协同及运维管理等业务要求，保证云平台对边平台的协同任务进行实时监控，有序调度及全面管理。通过管理协同，可实现模型在各个边平台的复用，保证各类跨域协同工作流统一管理和交互，实现云边统一运维管理，降低边平台研发和维护成本，提升管理效率。141.边平台需要具备模型的浏览、导入、编辑、导出、发布、评估的全流程管理能力，同时还能够及时响应云平台的相关调度任务。142.边平台需具备模型的导入/导出等模型管理能力，可基于图的形式查阅模型生成的全流程，支持模型的算法导入和文件形式的导出，保证模型能够在云边之间进行便捷的传输。143.边平台需支持模型发布：建立模型之后，可将模型发布到应用商店，供其他用户使用。其他用户在应用商店购买模型后，只需按照自身需求，对输入输出和模型参数进行配置后，即可使用。144.边平台需支持模型评估：在使用模型后，可用有标注的测试集对模型准确度进行评估，能够在评估结果中显示整体准确度、模型精确度、召回率等评估参数。145.边平台能够支持云平台对任务进行有效的调度管理，当出现多节点的协同任务时，需支持对各节点间的任务执行顺序，串/并发运行关系，调度计划等进行设置、编辑与修正。146.支持任务申请与提交，云平台根据任务类型，生成任务流程，存放在等待执行任务队列。147.支持边平台向云平台请求任务，云平台根据云平台节点组查找所属任务，向边平台下发任务，边平台根据任务流程进行具体步骤的匹配，并执行具体的任务，任务结束后，反馈给云平台。148.边平台需支持云平台对任务运行状态的统一监控与跟踪，包括但不限于：149.任务分解执行的位置。150.任务分解执行的进度。151.当前任务执行的状态。152.任务执行的历史记录。153.执行完毕时间。154.结果上传时间。155.边平台需支持任务执行完毕后的结果记录与回收，包括但不限于：156.手动执行：任务执行结束后，手动获取结果。157.自动返回：任务下发的目标平台，在运行结束后，主动提取回传结果到任务下发方平台。158.自动提取：下发任务的平台，根据下发任务的运行状态，在任务结束后，主动提取任务执行结果到本地。159.边平台需提供任务添加、任务队列管理的功能。可以添加实时任务、定时任务、cron任务、repeat任务、指定任务运行的执行端。任务队列管理功能提供了任务队列列表、任务编辑、暂停、任务删除的功能。160.边平台需具备任务的申请功能，能及时响应云平台发起的任务调度，并在任务执行过程中及时跟进完成进度，在任务节点进行催办提醒，能够让云平台监控到整个任务的执行过程。161.边平台在任务申请开始就要为任务发起方，任务接收方，以及集团侧云平台提供相关的任务信息，以便云平台进行任务跟踪，调度、控制与信息溯源。162.边平台数据任务的申请与执行：边平台能够访问云平台的数据资产目录，发起任务申请，待云平台审批通过后，执行任务。163.边平台需支持云平台的各种协同控制，包括：数据筛选条件、数据量、协同期限、数据安全措施、数据同步更新控制等。支持根据数据维度筛选，以及根据数据资产内部字段结构提供条件筛选。支持选择获取部分字段信息。164.边平台需为云平台提供基于数据筛选条件进行统计的功能，在发起协同请求前预先确认协同的效果。在协同申请阶段，不能查询实际数据。165.边平台在任务执行过程中，需支持任务催办提醒功能，包括但不限于：任务执行进度的提醒，标识当前执行状态和任务执行负责人，并能通过点击该项任务发送邮件提醒或进行手机短信提醒，还能通过任务的紧急程度点选不同任务提醒方式，电话，语言，邮件，短信等。166.边平台需提供基本的运维管理功能，包括但不限于操作系统/数据库/中间件监控，并提供相应的运维管理接口，与总部云平台的统一运维管理平台进行对接，支持总部对本地系统的相关信息监控。167.边平台需支持集团侧云平台对用户，组织机构，协同权限和节点拓扑信息的统一管理。并能与集团paas平台/大数据信息资源平台的统一权限认证功能进行对接。168.边平台应支持对本节点内的用户及角色进行授权和基础信息配置。169.边平台应支持集团云平台对边平台的用户，组织机构及协同权限的访问，查阅，控制，及授权管理，授权对象可以是个人也可以是组织。170.边平台需提供用户/组织机构信息同步功能，将已有的信息直接导入到协同用户，组织机构管理的模块中，并与数据库中的用户信息保持一致。只要进行跨域协同的用户/组织，就需要满足管理协同的同步要求。171.边平台权限任务的申请与执行：边平台用户可提交权限申请，包含数据协同权限，应用协同权限，管理协同权限，协同基础权限的申请，包含但不限于角色信息，申请内容等，并支持申请内容的添加，删除，编辑，基础信息管理等功能。172.边平台可支持云平台对权限申请的流程进行审批，查阅，与过程监控。173.边平台需支持云平台对本节点的使用权限进行管理与设置。174.边平台需具备节点注册/注销能力，并能自行测试节点是否连接成功。175.边平台需提供节点资源管理器，使云平台获知本节点的运行状态。支持shell和批处理的各种环境，适配于各种管理策略，支持交互、批处理、串行及并行的作业方式。176.边平台需具备对本节点的创建、修改、编辑能力，并进行相应的节点信息配置。177.边平台可支持云平台根据节点名称、节点层级关系绘制集群拓扑图。能够以拓扑方式显示节点之间的关联关系。178.边平台应支持和云平台之间的信息检测，显示节点通信状态，并能通过点击该节点进行监控信息的查阅，包括但不限于ip地址，角色，配置，分组，资源用量，执行时间及节点运行状态信息。179.边平台需能够接收并解析云平台下发的各类数据标准、目录标准及质量规则，同时，能够将本地的元数据信息、资产目录、数据质量稽核过程和报告、数据资产等内容同步至云平台。通过落实数据协同要求，在集团全域范围内共享一套数据资产目录和标准，有利于数据资产在集团内的共享流通，提升边平台数据质量，形成良性数据管理循环，降低数据管理工作强度，最终达到边平台数据资产价值的最大化。180.边平台应具备本地的标准管理能力，应能解析集团按照标准格式规范打包下发的数据标准成果，并支持标准浏览与应用。支持解析集团所下发的标准类别包括但不限于：181.字典类标准：字典类标准范围包含但不限于测点中文名称、测点缩略语、测点编码、测点分类、设备分类、标准业务维度等。字典类标准为结构化数据表。182.文件类标准：文件类标准格式包含但不限于doc、docx、pdf、xml。183.数据目录标准：数据目录标准包括标准目录的层级结构、数据资源实体标准元信息以及元数据字典等内容。数据目录标准为结构化数据表的形式。184.编码规则标准：编码规则标准为具有特定格式的描述文件，该文件中包含了码段组信息、码段信息、码段位数要求、码段取值规则表达式等信息。包括但不限于设备编码规则、测点编码规则等。185.边平台应能将本地数据资源按照集团标准组织成目录并上传至集团和创新中心侧。同时，边平台应能解析其他节点跨域协同的数据资源，并纳入本地的数据目录。186.边平台侧应具备数据资产目录管理功能，用于建立本地目录并上传至集团；包含但不限于目录标准引用、本地目录构建、资产元信息配置、目录浏览与查询等能力。187.边平台侧应能引用集团所下发的数据目录标准，并以标准的目录层级作为分类基准，将本地的数据资源，配置到标准目录层次相应的类目中；也可将标准目录层次作为标签，配置到每个数据资源的元信息中，并根据标准化标签解析目录层级结构。集团所下发的标准目录层次包含多个视角，包括但不限于业务板块、业务域、数据来源、所属组织等；数据资源的类型需支持但不限于结构化数据、时序数据、小文件、文件等。188.边平台侧应根据集团所下发的标准，将数据资产元信息配置完整，信息包括但不限于数据类型、数据标识、安全属性、数据加工处理过程记录等；同时，边平台应能记录数据溯源信息，并能将溯源信息作为元数据协同至云平台，用于在云平台侧生成全集团的数据地图，展现所有数据的血缘关系。189.边平台需要支持结构化数据及时序数据的质量稽核，用以控制跨域数据传输中的数据合法性。能力包括但不限于：190.边平台应能接收总部下发的各类校验规则及质量稽核模型，并解析执行，对本平台内纳管的数据进行质量稽核。191.边平台应能生成质量评估报告，报告中应提供各项数据的质量处理过程及质量评估结果，使云平台能够追溯数据的演化过程。192.质量报告应为结构化形式，支持云平台侧按照标准格式规范进行解析。193.边平台应用协同要求主要是为了满足云边协同的应用协同，重点是针对从应用商店下载或下发的应用提出的协同要求。194.通过应用协同，边平台可以充分利用应用商店的已有应用来满足业务需求，降低新开发应用所需的资金投入、人力投入，减少资源依赖和接口协调，降低运维门槛，实现从关注平台到关注业务，提升边平台应用价值，产生更大的经济效益和社会效益。195.在满足应用部署要求的前提下，通过应用协同可以将一个独立应用，同步到多个不同的云、边平台运行；将一个组合应用，配置到不同边平台运行，可通过调度策略，在本地按照跨域调度策略执行，将结果返回，并可按照组合应用进行统一跟踪管理。196.边平台应用至少支持以容器化方式部署，也可以选择容器包模版和saas应用等形式进行接入。197.边平台可支持容器化技术及微服务架构。平台功能组件及开发成果可支持容器化部署，以便为租户快速部署环境，将应用在租户间进行快速推广。边平台的服务支持以微服务方式提供，用户可以基于边平台开发新的微服务；边平台可选择提供容器编排和微服务治理能力。198.应用模型从云平台下装到边平台时，边平台必须遵循预先定义好的运行规范和部署规范。运行规范包括具备云边协同框架预先定义好的基础技术架构，包括操作系统、基础数据平台、环境设置等信息，以及对应的版本要求。部署规范包括应用模型的描述、应用模型打包规范等。199.边平台可选择支持容器包应用模版部署；提供一键部署能力，可以配置相应的部署策略，提供边平台升级必须遵循的运行规范和部署规范，后端预先有响应的运行集群环境。200.根据需求选用saas服务方式运行的应用系统进行对接。边平台提供接口可以支持第三方应用的接入，普通用户统一将第三方应用的相关信息录入到边平台，录入成功后，提交发布，由云平台的管理员审核，审核通过后相关应用信息直接可在云平台的应用商店中预览，可进行订阅，收藏的功能。201.用户购买应用后，在权限范围内，能够自主选择应用部署位置。202.所述大数据边平台，还包括：203.大数据边平台数据协同必备要求的接口，包括数据协同服务接口、标准协同接口和数据模型协同接口；204.数据协同服务接口：数据协同服务主要负责数据跨域协同相关的功能，主要涵盖数据订阅接口、数据访问接口、数据集市接口、数据目录接口，这些接口主要支持云边协同下的数据资产管理；205.数据订阅接口：支持跨域的数据订阅协同请求；206.数据交换接口：支持云端和边端双向的数据交换；207.数据集市接口：支持协同模块之间跨域数据集市的浏览和集市相关的业务数据的获取；208.数据目录接口：负责协同模块之间关于标准目录相关的协调功能，包括标准目录的获取、目录内容的同步功能的集成。209.所述大数据边平台，还包括：210.标准协同接口，标准协同服务主要负责数据标准跨域协同及数据质量管理的相关功能。主要集成接口如下：211.标准发布接口：当有新的规范标准发布，或者已有规范有更新时，云平台通过此接口通知边平台，边平台能够接收相关标准并进行在本站点内的发布，自动成为标准的最新版本；212.数据模型协同接口：213.数据模型协同服务主要负责业务数据模型的跨域交换，边平台需要支持数据模型发布接口，通过此接口云平台能够把已经发布的数据模型同步到指定的边平台，边平台能够接收相关数据模型并进行在平台内发布，自动成为相关的数据模型的最新版本。214.管理协同服务必须满足任务协同接口及协同基础接口的要求，以满足国家电投云边管理协同的要求，同时对应用形成的结果数据按照数据协同接口进行跨域协同。215.任务协同接口：任务协同服务主要负责跨域任务协同相关的功能，需要注意的是此功能基于协同基础模块上实现，需要同步全集团统一的用户和组织机构，来实现管理协同中的任务协同要求，主要集成接口如下：216.申请任务接口。217.任务跟踪接口：支持提交的跨域协作申请状态的跟踪，并支持提醒和催办的功能。218.协同基础接口：协同基础接口主要负责跨域场景中，各个协作节点中协同相关的配置，服务的监控以及服务的管理和运维，安全基础信息的集成等，通过标准化的协同基础接口，实现统一跨域节点的集成和管控，来实现管理协同的基础信息管理要求，主要集成接口如下：219.拓扑同步接口：支持云平台推送整个集团的平台拓扑信息到各个边平台。220.协同监控接口：支持各种跨域服务的健康状态监控，服务请求负载监控，数据流量监控等，以统一的运维接口提供给统一运维平台。接口说明，见附录a.2.3协同监控接口部分说明。221.用户和组织机构同步接口：支持大数据信息资源平台中的用户，组织机构信息的同步，确保身份认证的统一。222.一种大数据边平台的方法，包括：223.设备点位按以下三个层级划分：224.(1)基本点位：作为监控系统的最基本的点位，应包括实现基本信息监视及控制、能量管理、指标计算及分析功能；225.(2)故障预警及数据分析：应满足应用平台现有的故障预警、分析及公司目前分析业务需求；226.(3)全量数据点：包括但不限制于1和2的数据点，智能设备时代，具有更多的传感器，采集传输更多的设备点位，未来大数据及ai智能时代，数据产生更多的价值；227.点位属性应包括但不限于以下内容：228.(1)iec路径名称229.(2)编码230.(3)中文名称231.(4)英文名称232.(5)值类型233.(6)单位234.(7)上限235.(8)下限236.(9)计算公式237.(10)位置238.(11)是否保存239.(12)是否要有1秒数据240.(13)是否要有10分钟量241.采集的传感器(主要为大部件或重要安全传感器)应包括但不限于：温度传感器、振动传感器、电流电压传感器、转速传感器等。传感器采集标准除点位标准外还应包含以下内容：242.必要属性：243.(1)位置244.(2)分类245.(3)传感器名称246.(4)测点247.(5)数量248.非必要属性：249.(1)采样间隔250.(2)采样时长251.(3)数据形式252.(4)对外传输253.(5)传感器分辨率254.(6)传感器量程255.设备模型256.设备模型是指设备的组织架构形式，设备应包括风机、升压站、测风塔、箱变、逆变器、汇流箱等等。257.例如风机设备，需要设置该风机设备所属线路、线路所属的电场、电场所属的区域、区域所属集团等树形组织架构模型。258.设备需要设定是否是标杆、是否是虚拟设备、是否属于多个电场。259.同一个设备可能归属到不同的电场，同一个电场在调度和业主方叫不同的名称，需要在设备模型中灵活配置设备与风电场，方便集控归集不同的设备。260.在报表、统计分析中需要根据设备组织模型区分设备归属，计算相应数据及出统计分析数据。261.设备模型具备继承功能。262.设备状态263.状态标准化：应按设备类型定义设备状态标准化，如风机状态，目前系统将风机状态分为两大类，只要具有状态的设备，都需要定义该类设备的状态标准。数据平台对不同机型的风机状态进行标准化处理，基于标准的风机状态进行过滤，所有设备数据在转发送到集控系统之前，需要对采集到的风机状态数据按照集控标准进行处理，再转发到集控系统中；264.事件标准化：应制定统一的事件处理标准和统一的事件划分类别。应将事件划分为故障、警告和提示三种级别，并定义事件所属设备；265.事件码应该统一定义，一个事件码应该表示的是一个明确的事件(例如：风机设备的10001事件码表示塔底温度高，事件类别为警告)。266.告警功能应能够支持实现站端告警定义、计算并生成站端告警记录。包括但不限于遥测越限、异常告警、遥信变位告警等。并可通过配置模块对各遥测和遥信测点的告警规则，包括告警类型、告警级别、告警内容等，告警引擎对接收到的点根据告警引擎进行实时计算后对于满足条件的生成平台告警记录并存入告警实时库；267.每条告警信息应包含但不限于以下内容268.(1)场站269.(2)设备270.(3)等级271.(4)类型272.(5)告警代码273.(6)告警内容274.(7)开始时间275.(8)结束时间276.数据采集、传输及存储标准化；277.数据采集规约标准化，是指约定设备厂家以特定的规约传输设备原始数据，保证数据稳定高效传输。对比目前主流的电力行业规约(cdt、iec101、iec104、modbustcp和dnp3)。278.信息模型构建：目前国际上比较通用的方案为cim模型(通用信息模型)和iec61400-25(风电)iec61850(变电站)的信息模型。由于iec61400-25是专为风电做的国际标准，推荐在系统中使用该信息模型，方便多厂家(国内、国外)和多系统(不同的业务系统)数据通讯及系统整合。以上所列信息模型仅供参考，应该依据现场实际提供详细的信息模型以及标准化的信息模型标准文档。279.信息交换机制依赖标准化的风电信息模型。这些信息模型以及模型化方法是内部信息接入、处理及传输的核心。信息模型应能够标准模拟实际部件的信息，并定义所有可以同其他部件进行交换的可用信息。此模型应能够为风电场自动化系统提供一个真实世界(如叶轮、偏航系统、发电机等)的映像。280.信息模型内部规约的方法应该是将功能分解为交换信息的最小实体。一台风力发电机(ied)的部件多少由风电机组配置决定。这些部件被称作逻辑节点(例如风轮部件可以虚拟表示为标准化类名wrot)，它可以通过概念性应用层面来模拟和定义。逻辑节点应集中在诸如代表完整风力发电机组这样的逻辑设备之中。281.根据风电通信业务的流向，通信业务大致可分为本地通信和远程通信。风力发电机组由多个功能系统组成，包括风机系统、发电系统、并网系统、气象系统等。每个系统包含多种内部功能和外部关联。如风机系统包括了变桨功能、偏航功能，其中变桨功能又存在与发电系统主轴力矩、气象系统风速、并网系统功率控制的外部关联。总体而言风电机组是由模块化的子系统和子系统间分布式实现的功能组成。282.针对这样的系统结构，应该采用从上至下的抽象方法，将风电机组的具体功能层层分解和分类，抽象成最小功能单元的组合，功能的实现应能够依附于具体的物理设备但不应局限于单台物理设备或系统；这样的抽象方式能够使得风电机组成为了逻辑功能而不是具体设备的组合，逻辑功能的高内聚、低耦合特性能够使得系统运行的交互性和适应性得到了提升。283.分层的模型结构从上至下应分多个层次，包括但不限于逻辑设备、逻辑节点、数据类和数据属性。其中逻辑设备应是实体设备的功能抽象，由多个逻辑节点组成；逻辑节点应是风电机组内部最小功能单元的抽象，是相关数据类的集合；数据类应包含一套相关数据属性。284.所述大数据边平台的方法，还包括：285.电场总体通讯模型，电场总体通讯模型规定了客户端和服务器之间信息交换所需要的内容；通过该框架服务器可以处理风电场提供的用于外部监控的所有数据，并将这些数据处理为相关的标准语义信息，准予客户端以部件导向的方法访问这些数据。设备的多样性，与设备的通讯方式多样性，设备所使用的规约也具有多样性，同一种规约还有不同的变种，比如南瑞103和四方103；因此应采用国际标准的统一的设备信息模型、信息交换模型和规约映射。286.不同厂家不同规约的设备接入系统后，应根据如cim、iec61850、iec61400-25等的信息模型，将设备统一模型化，然后通过信息交换模型将信息交换映射到国际标准规约(101、104、dnp3)与其他系统系统交换信息，方便其他系统或者第三方系统接入。287.数据存储；288.数据存储标准是指对存储在存储介质中数据的存储与交换方法，数据存储的需求及其定义方法、数据格式要求和存储实现技术等进行标准化定义。存储标准的确定及规范化有利于数据的管理、存储、分类和提取。289.系统应能够存储三个类别的数据：毫秒级数据(风机故障录波数据)、1秒级数据、5秒级数据，其中1秒级数据应能够存储1个月，5秒级数据应能够长期存储，毫秒级数据以投标厂家scada是否支持为准。290.系统可设置归档策略，热数据、冷数据的设置可灵活配置。291.系统能够通过将原始运行数据按照周期进行数学计算，形成相应的汇总数据并存储，运行时再通过周期数据生成日数据、月数据、年数据，以及各种定制化周期的统计数据，用于统计报表和数据分析。292.数据应用指标标准化；293.系统应能够综合各项生产指标，建立基础数据应用标准，基础数据应用是指依据设备原有数据，进行简单逻辑计算和处理后得出的数据，如功率曲线、故障时间、风机发电量等等。这些数据对设备(风机、光伏设备等)运行分析有着重要作用，数据来源分为三部分——风机plc计算、风机scada计算、应用系统计算等，基础数据应用标准化是对目前所用的经过逻辑计算后的数据进行梳理，重新定义并明确算法公式、取点位置、逻辑处理标准，进而制定公司级指标统计标准，为上层应用提供直接的数据与指标展示。294.指标：应包含但不限于标准空密平均风速(m/s)、等效小时数、pba(能量可利用率)、tba(时间可利用率)、mtbf(平均无故障运行时间)、mttr(平均故障修复时间)、发电量、上网电量、不可用损失电量、故障损失电量、限电时间、限电损失电量、理论功率等。并应按照统一原则分风电场分设备类型而制定个性化标准。295.数据应用指标标准化；296.系统应能够综合各项生产指标，建立基础数据应用标准，基础数据应用是指依据设备原有数据，进行简单逻辑计算和处理后得出的数据，如功率曲线、故障时间、风机发电量等等。这些数据对设备(风机、光伏设备等)运行分析有着重要作用，数据来源分为三部分——风机plc计算、风机scada计算、应用系统计算等，基础数据应用标准化是对目前所用的经过逻辑计算后的数据进行梳理，重新定义并明确算法公式、取点位置、逻辑处理标准，进而制定公司级指标统计标准，为上层应用提供直接的数据与指标展示。297.指标：应包含但不限于标准空密平均风速(m/s)、等效小时数、pba(能量可利用率)、tba(时间可利用率)、mtbf(平均无故障运行时间)、mttr(平均故障修复时间)、发电量、上网电量、不可用损失电量、故障损失电量、限电时间、限电损失电量、理论功率等。并应按照统一原则分风电场分设备类型而制定个性化标准。298.数据采集与治理要求；299.现场能够通过标准化点表，以统一和规范的数据采集规约和协议，接入现场数据采集网关，同时能够在集控中心为原先的集控系统提供统一的数据，并且通过正向隔离转发到三区的数据平台。300.大数据边平台系统应能够实现公司下属所有集控数据接收、数据存储、数据评价及数据治理。依据中间层数据接收、存储规范及公司现有应用系统特性，制定大数据边平台系统相应的标准。大数据边平台系统通过打通系统各个环节和各个业务的交互，实现数据统一的管理和数据之间的共享；为集控中心、应用平台、生产管理等系统提供高质量的数据。投标方应在投标阶段提供总体架构图给招标方。301.对于现场数据，应采用厂家数据转发方式。数据接入之前，应对厂家开放点位的数量、质量以及厂家数据接口的稳定性进行评估。302.数据采集；303.数据采集内容：大数据边平台系统数据采集范围应包括但不限于：升压站、风机(含监控和能量管理)、箱变、光伏设备、agc、avc、故障录波、功率预测、cms、测风塔、环境监测仪、电计量等。304.设备接入认证；305.设备接入需要进行接入认证，认证项目包括但不限于以下内容：306.(1)设备上电联网后，需要一个认证激活过程；307.(2)设备向采集网关申请激活，包括相应的激活信息；308.(3)采集网关判断并通过激活，根据诸多信息生成全局唯一的设备编码，如果是重复激活，需要根据唯一编码查到上一次分配给该设备的设备编码；309.(4)采集网关告知设备激活成功，并下发设备编码，设备永久保存设备编码；310.(5)设备多次激活，编码不变；311.(6)设备激活以后，每一次连接采集网关，必须提交设备编码，防被拦截窃取；312.(7)在注册设备时，用户自定义或系统自动生成的设备标识；313.(8)为设备创建私钥，并将私钥存放至一个安全地库；314.(9)每个设备都必须拥有唯一的公钥和私钥；315.(10)由系统认证的密钥不能用于其他目的或通过其他协议进行通信；316.(11)当设备被重置时，密钥必须被撤回。317.所述大数据边平台的方法，还包括：318.数据采集接入；数据采集性能保障包括：数据采集网关必须提供高效的数据转发、可靠的告警上送、完整的数据转存、高可用的服务支撑等功能，同时支持安全数据上送通道。并且保证数据采集的高效性、可靠性、完整性和安全性能要求。319.所述大数据边平台的方法，还包括：320.数据传输与转发：集控场站数据到大数据边平台系统的转发应包含数据传输、接收、存储、转发这样的环节，通过标准化数据链路各个环节，规定具体传输协议、接口技术、存储结构和机制，确保数据结构合理并提供通用型数据转发接口，为后续大数据边平台系统建设提供数据保障；321.数据压缩加密：数据在传输过程中不能使用明码，需要对数据通讯进行加密和验证，对其安全性进行保障。322.加密后的数据包中除了包括加密数据，还应该包括加密数据的校验数据，防止其在传输中被篡改；在加密包中，有些非关键数据可以不进行加密，方便其在转发时可快速进行数据的识别而无需解密，能够提高传输效率。323.数据传输过程中还应该支持压缩传输，提高传输效率，避免带宽不足的情况对系统的使用产生影响。324.在数据的采集和传输过程中，因为设备、通讯等方面的原因，可能会造成数据丢失、失真，对最终的数据统计、分析造成较大影响。所以在数据使用前，首先需要对数据进行质量检查和统计，提交给系统，必要时通知相关人员，帮助其进行相应的处理，提高数据的质量。325.数据质量的检查算法应包括但不限于阀值范围检查、数据丢失检查、离散数据检查、增量值域(跳变)检查。各检查之间相互独立，互不影响，数据应可以同时被赋予多种检查属性。326.数据质量的统计算法包括数据完整率、及时率、有效率统计等。327.数据转发模式；328.大数据边平台系统应能够提供统一、通用的数据转发接口及标准，各系统依据自身需求，应能够自由选择数据接入标准。大数据边平台系统应配置多个接口，避免硬件重复建设，满足数据转储要求。要求可以转发至国家电投云平台，确保让云平台识别并使用。329.数据传输节点状态监测；330.大数据边平台系统应部署传输节点监测。在数据传输过程中，平台对通道是否可用具备监测功能。协议内部规约也应具备对于数据包完整性、连续性的检验，对数据包是否完整进行校验。校验失败后，平台应再次请求数据上送。331.在一、二区监控界面中，应能够调用数据传输节点监测模块，对传输节点的可用性和数据质量指标进行展示。332.远程集中管理；333.系统应能够提供基于web的集中配置中心，实现远程通讯配置，数据调试，设备接入；在保证相应网络和端口畅通的前提下修改配置参数等操作；平台自动同步。334.通信调试。335.系统应能够通过登录配置管理中心web页面，实现远程设备接入通讯调试。通讯调试模块应基于web页面提供丰富调试功能，满足各种设备接入时的数据调试需求。336.主要功能应包括但不限于：337.(1)原始数据、计算数据实时查看；338.(2)对接入测点进行人工模拟置数；339.(3)规约通讯报文实时查看，下载；340.(4)通讯日志实时查看，分析；341.(5)连接网络测试，包括网络通讯测试，端口测试，tcp连接查看等。342.所述大数据边平台的方法，还包括：343.数据标准化接入；344.数据接入是数据可用性的基础，系统应能够实时接入的实现结构化和非结构化的数据。系统应能够将物联网平台采集的时序数据，如光伏组件监测数据、风力发电机组监测数据、升压站监测数据等，接入到数据服务平台的时序数据存储中。时序数据的采集和接收，要求单机吞吐高，每条记录不丢不重，在单点故障发生的情况下，不应该影响时序数据的持续接入。同时，由于工业数据质量普遍存在问题，要求数据质量治理应能够在采集和接收“前端”完成，逐条核查时序数据的质量，避免“垃圾进－垃圾出”，采集到对于分析挖掘质量不合格的数据。根据用户使用的场景，数据服务平台应能够对时序数据提供至少以下三种接入方式：实时接入、批量接入和定时批量接入。系统应能够将传输过来的对象数据，如视频监控数据、日志文本数据等，接入到数据服务平台的对象数据存储中。应能够在平台中接入关系数据，对于支撑实际业务需求，实现异构数据间的关联分析具有现实意义，将物联网平台传输过来的业务数据接入到数据服务平台。投标方应在投标阶段提供详细的关系数据接入步骤。规则引擎应能够帮助用户灵活地转发和处理设备消息，用户可通过sql的形式设定规则，对消息数据筛选、变型、转发，应能够根据不同场景将数据无缝转发至不同的数据目的地，如时序数据库、物接入主题、机器学习、流式处理、对象存储和关系型存储等。平台应能够实现模型管理、资产树管理、告警等功能。345.数据治理；346.系统的数据治理工作，应能够对数据进行存储、插补、清洗、计算，并统一标准和口径，形成标准数据，建立基础模型、融合模型和挖掘模型，实现数据异常规则设定、异常监控告警、数据日志记录等，并且进行数据质量评价，形成数据质量报告，实现跨领域数据融合。现场数据到大数据边平台系统后，平台应能够同时存储原始数据及标准化数据，一是确保集控中心等实时监控系统与现场保持一致，二是给其他应用分析系统提供标准化数据；对于其他应用系统数据，大数据边平台系统应能够利用数据汇聚工具，抽取必要数据，一是可以对重要数据进行异地备份，二是可以进行数据的综合分析。347.数据治理至少应能够达到以下具体效果：348.(1)数据缺陷随时掌握,及时发现；349.(2)缺陷数据能够得到及时修正；350.(3)数据流过程具有详细的日志记录，历史数据可追溯；351.(4)数据修正过程进行标记，实现修正过程可追溯恢复；352.(5)数据实现多版本管理，解决统计口径问题；353.(6)方便分析数据缺陷原因，定时提供数据缺陷报告，提出解决方案；354.(7)数据治理完成后数据采集平台可用率达到99％以上。355.所述大数据边平台的方法，还包括：356.业务计算功能，从而实现流处理服务、批处理和调度服务这样的功能；357.(1)流处理服务：358.流处理服务应能够充分满足处理设备和资产的实时数据，以及经离线消息通道集成的数据的需求。359.应能够基于大规模分布式集群的实时处理能力，并应能够集成可视化的流数据处理任务设计、调试、部署及监控工具。大数据边平台系统应可以沉淀一系列通用及领域相关的流计算算子，覆盖多领域核心场景需求。数据开发工程师应能够快速组合出不同的数据处理方案，降低数据开发障碍、缩短数据研发周期。360.数据处理服务还应能够实现规则和配置加载、提供相关支持工具等功能。361.(2)批处理&调度服务：362.批处理又称批计算，是指对平台中离线批量数据的并行计算，过程中会调用数据清洗、聚合、专用算法等平台计算算子，实现数据标准、数据挖掘、应用服务等数据批量处理的功能。363.大数据边平台应能够提供批处理框架，应包概括但不限于mapreduce和spark，从而能够分别响应不同的批处理场景。364.批计算服务应能够配合调度服务，实现用户的可用性需求。其中，作业是批计算的调度服务的主体，是调度服务中被执行任务的统称。平台提供的调度服务应能够覆盖作业的全生命周期管理，包括但不限于作业的定义、运行监督、结果查询等。365.所述大数据边平台的方法，还包括：366.平台管理；367.平台管理功能应主要包括但不限于资源管理、业务监控、平台监控、平台用户管理、权限管理、配置管理、日志管理等。368.资源管理：用户在创建时会被赋予默认的资源量以满足基本操作，如需扩展或调整集群的能力，应能够在线进行资源的申请，扩容，管理等操作；369.业务监控：应包括监控平台上的业务应用运行情况、平台上的数据云图、数据质量等；370.平台监控：应能够对集群进行管理，如添加、删除节点等操作；应能够监控集群的健康情况，对设置的各种指标和系统运行情况进行全面监控；应能够对大数据的多组件进行整合；还应能够对集群出现的问题进行诊断，对出现的问题给出建议解决方案；371.用户管理：平台管理的用户分为两大类，一类是平台运维人员，一类是平台之上的应用。平台应能够指定用户的有效期、是否禁用；如果是应用用户应能够限定应用的mac地址。平台还应提供用户的查询、增加、修改、删除等操作；372.权限管理：平台权限管理应能够支持对管理工具的权限管理和对平台数据(包括元数据和业务数据)的权限管理；373.配置管理：应能够实现大数据边平台的各种组件(flume、kafka、hive、hbase、hdfs、spark、yarn、zookeeper等)及应用(流计算规则引擎规则配置、预警模型参数配置、调度模块配置、应用告警规则配置、平台监控指标配置、绩效分析指标配置等)的配置项的增加、修改、删除以及查看；374.日志管理：系统应能够提供日志记录功能；应能够采集组件接口的日志记录、日志查询等；当应用已部署至某环境时，还应能够通过点击各服务的查看日志按钮查看服务日志详情；375.告警管理：系统应能够提供告警功能；376.事件管理：即告警服务模块。应能够接收设备上送的事件类信息，能够提供事件的存储，查询，订阅，推送等服务，同时也应支持对接入到平台的实时数据定义产生事件的规则，以满足实时告警，故障分析等业务需求；377.安全管理。378.系统应能够提供安全管理功能，包括但不限于：用户认证、设备认证、应用鉴权、授权管理、账户生命周期管理(账户创建，编辑和删除)、多组织用户管理(组织用户都作为一个组织单位进行管理)等内容。379.大数据边平台特殊要求380.大数据边平台可通过跨域协同的方式和国家电投集团云平台实现跨域协同的方式，构建成完整的云边协同工业大数据边平台。381.以上以用实施例说明的方式对本发明作了描述，本领域的技术人员显而易见的是，本公开不限于以上描述的实施例，在不偏离本发明的范围的状态下，能够做出各种变动、改变和替换。当前第1页12当前第1页12
再多了解一些
本文用于企业家、创业者技术爱好者查询，结果仅供参考。
