init: 导入团队知识库内容
This commit is contained in:
yueqian-ai
@@ -0,0 +1,697 @@
|
||||
MXXD
|
||||
|
||||
建设方案
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
共1册 第1册 共 88 页
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
沈阳顺义科技股份有限公司
|
||||
2026年4月
|
||||
|
||||
|
||||
|
||||
MXXD
|
||||
建设方案
|
||||
|
||||
签署页
|
||||
|
||||
|
||||
编制：
|
||||
校对：
|
||||
审核：
|
||||
标审：
|
||||
会签：
|
||||
批准： 日期：
|
||||
日期：
|
||||
日期：
|
||||
日期：
|
||||
日期：
|
||||
日期：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
文件更改记录表
|
||||
序号 版本号 页 次 标 记 处 数 更改文件号 更改者 日 期
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
目 次[1、缺少边端数据处理协同内容，软件设计章节专门功能章节补充；
|
||||
2、补充“二次开发支持”章节内容，可作为单独文件或者附件详细列出，特别是对算法/模型软件模块的适配开发内容需详细给出；]
|
||||
|
||||
1. 项目理解 1
|
||||
1.1 建设背景 1
|
||||
1.2 建设原则 2
|
||||
1.3 建设目标 3
|
||||
2. 总体设计 5
|
||||
2.1 设计原则 5
|
||||
2.1.1 标准化先行 6
|
||||
2.1.2 数据驱动决策 6
|
||||
2.1.3 安全可控底线 7
|
||||
2.1.4 弹性扩展适配 7
|
||||
2.1.5 微服务化设计 8
|
||||
2.2 架构设计 9
|
||||
2.2.1 感知接入层：多源异构数据统一接入 9
|
||||
2.2.2 边缘协同层：协议融合与实时预处理 9
|
||||
2.2.3 平台核心层：数据中枢与任务调度 9
|
||||
2.2.4 应用服务层：面向上层应用的智能支撑 10
|
||||
2.3 技术路线 10
|
||||
2.4 总体设计方案 19
|
||||
2.4.1 总体架构 19
|
||||
2.4.2 业务架构 22
|
||||
2.4.3 技术架构 26
|
||||
2.4.4 云边端工作协同 30
|
||||
2.5 建设思路 32
|
||||
3. 软件功能设计 37
|
||||
3.1 系统管理 38
|
||||
3.1.1 用户管理 38
|
||||
3.1.2 组织架构管理 38
|
||||
3.1.3 角色权限管理 39
|
||||
3.1.4 数据字典 39
|
||||
3.2 服务器监控 40
|
||||
3.2.1 硬件监控 41
|
||||
3.2.2 服务监控 42
|
||||
3.2.3 趋势分析 42
|
||||
3.3 日志管理 43
|
||||
3.3.1 操作日志 44
|
||||
3.3.2 系统日志 45
|
||||
3.3.3 日志配置 46
|
||||
3.4 备份与恢复 47
|
||||
3.4.1 数据备份 47
|
||||
3.4.2 备份恢复 51
|
||||
3.4.3 备份校验 51
|
||||
3.4.4 异地存储 52
|
||||
3.5 系统自检 53
|
||||
3.5.1 服务自检 53
|
||||
3.5.2 链路自检 54
|
||||
3.5.3 自检报告 55
|
||||
3.6 监测大屏 55
|
||||
3.6.1 波形实时展示 56
|
||||
3.6.2 通道状态展示 57
|
||||
3.6.3 采集数据展示 57
|
||||
3.7 配置管理 58
|
||||
3.7.1 设备管理 58
|
||||
3.7.2 通道管理 58
|
||||
3.7.3 采集配置 59
|
||||
3.8 数据溯源 60
|
||||
3.8.1 状态数据 60
|
||||
3.8.2 故障数据 61
|
||||
3.9 模型管理 63
|
||||
3.10 任务管理 65
|
||||
3.10.1 用户数据管理接口 66
|
||||
3.10.2 任务编排 67
|
||||
3.10.3 定时任务配置 67
|
||||
3.10.4 第三方接口调用配置 67
|
||||
3.11 数据驾驶舱 68
|
||||
3.12 数据服务 69
|
||||
3.12.1 数据资源管理 70
|
||||
3.12.2 数据治理管理 74
|
||||
3.12.3 数据开发管理 77
|
||||
3.12.4 数据服务管理 79
|
||||
4. 程序版本与硬件要求 83
|
||||
4.1 端设备参数系统要求 83
|
||||
4.2 边设备参数系统要求 83
|
||||
4.3 云设备参数系统要求 83
|
||||
4.4 软件版本详细情况 84
|
||||
|
||||
|
||||
1.项目理解
|
||||
1.1建设背景
|
||||
新一轮信息技术革命加速数字经济时代到来。习近平总书记强调发展数字经济，释放数据要素价值。2026年《十五五规划纲要》要求推进数字中国建设，促进云边端协同与智算供给，健全数据全生命周期管理。推动多源异构数据标准化汇聚、治理与可信存储，将海量健康数据转化为标准化资产，支撑数字孪生健康与全生命周期管理，为故障预测与健康管理平台指明方向。
|
||||
某平台包含实时故障预测系统、数字孪生驱动的某系统健康管理可视化系统、典型设备故障预测与健康管理系统等多子系统。各个子系统由不同应用系统组成，各自采集终端数据，数据被重复采集。同一设备上存在不同系统的采集设备，资源消耗过大，重复工作过多，效率低下。在规定的同一时间内各个子系统采集的数据，由于采集数据的时间依据不统一，可能导致数据不一致，可能获取脏数据并存在数据孤岛。各子系统自定义数据获取、查看、管理等权限导致业务应用程序工作权限不一致，存在业务操作范围过大，数据管理权限混乱等风险。每个子系统各自运行，平台内数据不一致性导致业务产出结果没有标准依据，无法为业务及领导提供决策支撑同时平台内的数据无法形成标准化、健康的、可行的业务资产。
|
||||
鉴于上述内容，现决定建设系统故障预测与健康管理数据应用平台，通过构建数据“接入-治理-存储-加工-服务”一体化闭环，实现数据统一汇聚、标准治理、合规存储、智能加工、服务化输出，从根源上解决数据碎片化、孤岛化问题，为数字孪生提供持续稳定的数据供给。向下统一接入各类感知终端与异构系统，向上为数字孪生引擎、业务应用、决策平台提供标准化数据服务，承担 “数据中枢、数据服务[ 1、不过分夸大功能效果；][已修改]、业务服务”作用。推进数字化建设，提升业务水平。
|
||||
1.2建设原则
|
||||
在“统一规划、统一标准、统一建设、统一管理”的“四统一”总体原则指导下，“避免重复建设、避免职能交叉、避免信息孤岛”[ 1、重新编写改章节内容，按工程技术类风格实事求是写；][已修改]。具体规划设计工作遵循以下原则。
|
||||
（一）统一规划，业务驱动
|
||||
立足业务实际需求，以实际业务为导向，明确数据中台的建设范围、技术架构、实施步骤、资源配置、阶段性目标及验收标准，确保规划方案贴合建设实际，能够有效指导后续建设工作，避免因规划脱节、规划混乱导致的工程返工、资源浪费等问题，为整个数据中台工程建设奠定坚实的规划基础。
|
||||
（二）一套标准，全局应用
|
||||
结合现有系统技术标准及业务数据特点，统一制定数据标准、接口标准、安全标准及运维标准。其中，数据标准明确数据编码、数据格式、数据口径等核心要求，避免数据混乱、数据不一致；接口标准规范数据交互方式，保障数据与各业务系统、外部系统的顺畅对接；安全标准和运维标准明确安全防护要求、运维流程及责任分工，保障系统长期稳定运行。所有标准的制定均立足业务需求，不照搬照抄，确保标准的实用性和可操作性，为工程建设提供统一的技术依据。
|
||||
（三）统筹建设，安全可靠
|
||||
协调配合各建设环节、各业务系统，统一实施数据采集、数据治理、数据存储、数据服务等核心模块的建设，统一调配人力、物力、财力等工程资源，确保建设过程规范有序、协同高效。组织关键里程碑系统协同调试，确保数据中台各模块衔接顺畅、功能适配，避免因分散建设导致的工程质量参差不齐、系统兼容性差等问题，保障工程建设的整体性和系统性。
|
||||
（四）统一管理，稳定明确
|
||||
建设完成后，保障系统长期稳定运行、发挥工程价值的关键。建立统一的管理体系，涵盖数据管理、系统运维、安全管理、人员管理等各个方面。数据管理明确数据全生命周期的管理流程，确保数据质量持续可控；系统运维建立统一的监控、巡检、故障处理机制，及时发现并解决系统运行中的问题；安全管理落实分级防护、权限管控等要求，保障数据和系统安全。
|
||||
1.3建设目标
|
||||
本项目引入数据治理、分布式计算、容器化部署与国产化适配等关键技术，基于统一数据应用管理平台开展研究，覆盖“数据采集、数据治理、数据存储、数据处理、数据服务、算法管理、运维管理、系统管理”的完整技术体系，能够进一步丰富和完善某系统故障预测与健康管理技术体系,提高系统的数据治理能力、智能化程度和业务支撑水平,为上层应用的持续创新和可靠运行提供坚实保障。
|
||||
（一）顶层设计行业数智化管理体系，支撑行业高质量发展
|
||||
实现数据从“分散杂乱”向“统一规范”转变、从“资源消耗”向“资产增值”转变、从“被动响应”向“主动支撑”转变，构建起适配边缘资源、支撑数字孪生、赋能业务应用的数据底座，为数字孪生驱动的某系统提供稳定、高效、可信的数据支撑，同时降低系统运维成本、提升业务创新能力，助力系统实现健康管理智能化、数据利用高效化、业务运行敏捷化。
|
||||
（二）建设数智化云应用，实现业务与数据大协同
|
||||
建设实施数据治理、数据管理、算法管理、数据采集、运维管理与系统安全等业务应用，遵照“云-边-端”IoT协同架构理念，采用微服务与完全容器化（Docker）部署形态，实现平台内各子系统业务上下协同、数据共享。
|
||||
（三）实现数据全周期管理，提升核心竞争力
|
||||
构建数据“接入-治理-存储-加工-服务”一体化闭环，通过建设跨系统运行状态参数统一监测服务、算法资源管理服务、任务配置服务、计算任务管理服务、服务器自动运维服务等服务，实现各子系统高效协同，促进子系统管理提质增效。
|
||||
本次实施工作主要包括需求分析及方案设计、数据收集及处理、系统部署及配置、系统测试、培训、上线准备及切换、上线试运行支持等。
|
||||
1.4建设思路[ 1、思路统一放到前面去讲，这里主要讲具体设计与实现；][已修改]
|
||||
本平台建设以“统一接收、集中管理、按需服务、支撑应用”为总体思路，围绕故障诊断、虚拟仿真、数字孪生和实时监测大屏等业务系统的数据使用需求，建设一套统一的数据资源管理与数据服务支撑平台。以及各业务系统产生的文件数据、模型数据、仿真结果数据和分析结果数据，在平台侧完成数据校验、分类存储、资源组织、接口发布、数据集管理、算法任务管理和大屏数据支撑。
|
||||
平台建设的核心目标，是解决多系统数据来源分散、数据格式不统一、数据重复存储、数据难以查询复用、模型侧取数不规范、大屏展示数据项维护成本高等问题。通过建设统一数据服务平台，将现场采集数据、故障诊断数据、虚拟仿真数据、数字孪生数据、音视频资料、文档资料、模型文件和分析结果统一纳入平台管理，形成面向业务系统的数据支撑底座。
|
||||
（1）以统一数据服务平台为中心开展建设
|
||||
平台建设围绕统一数据服务平台展开，平台作为数据资源的集中管理入口和统一服务出口。向下承接前端数据网关、业务系统、模型系统和文件资源，向上支撑故障诊断系统、虚拟仿真系统、数字孪生系统、实时监测大屏、故障诊断大屏和数据管理门户。
|
||||
（2）以标准化数据接收为平台入口
|
||||
平台首先建设标准化数据接收能力，对接前端数据网关输出的数据、业务系统接口数据、模型分析结果和文件类数据。前端数据网关输出的状态数据、监测参数、波形数据进入平台后，由平台进行格式校验、字段完整性校验、测点编号校验、时间戳校验和数据质量记录。
|
||||
对于故障波形、特征数据、工况数据、仿真模型、仿真结果、音视频、文档资料和分析报告等文件类数据，平台提供文件上传、批量导入和接口接入能力。文件进入平台后，系统记录文件名称、文件类型、文件大小、所属任务、时间范围、业务标签和存储位置，保证文件能够被查询、下载、预览和复用。
|
||||
（3）以分类型存储支撑不同数据特征
|
||||
平台根据不同数据类型采用不同存储方式，避免所有数据进入单一数据库造成性能和维护问题。
|
||||
状态数据、运行参数、实时监测指标和历史趋势数据进入时序数据库，用于支撑实时曲线、历史趋势、状态回放和大屏刷新。设备信息、测点信息、接口配置、用户权限、数据集信息、算法任务信息和大屏数据项配置进入关系型数据库，用于支撑平台业务管理和元数据维护。音视频、仿真结果、模型文件和文档资料进入对象存储，用于支撑大容量文件归档和复用。数据标签、故障类型、工况类型、任务编号、文件说明和关键字信息进入检索服务，用于提升数据查询和资源定位效率。热点数据、实时状态、任务状态和临时查询结果进入缓存服务，用于提升平台响应速度。
|
||||
通过时序数据库、关系型数据库、对象存储、检索服务和缓存服务组合，平台形成既能支撑实时数据访问，又能支撑文件归档、历史追溯和快速检索的数据存储体系。
|
||||
（4）以数据资源组织提升数据可用性
|
||||
平台建设数据目录、数据标签、数据质量和数据使用记录能力，将接入后的数据转化为可管理、可查询、可复用的数据资源。平台按照设备对象、测点对象、数据类型、业务系统、任务过程、工况条件、故障类型、仿真场景和时间范围等维度组织数据，形成统一的数据资源视图。
|
||||
每条数据、每个文件、每个结果都记录其来源、时间、关联对象、处理状态、质量状态、存储位置和使用情况。用户能够在平台中按照设备、测点、时间、任务、工况、故障类型和数据类型进行组合查询，快速定位所需数据。通过数据资源组织，平台将分散的数据变成可查、可看、可用、可追溯的数据资产。
|
||||
（5）以数据集管理支撑模型和仿真应用
|
||||
平台面向故障诊断、状态评估、故障预测、虚拟仿真和数字孪生等应用，建设数据集管理能力。用户可从历史监测数据、状态数据、波形数据、特征数据、故障结果、工况数据、仿真结果和文档资料中按条件抽取样本，形成不同用途的数据集。
|
||||
数据集支持创建、查询、样本查看、数据标注、标签维护、版本管理、导入导出和使用记录管理。每个数据集记录数据来源、样本范围、样本数量、标注状态、创建人员、创建时间、版本信息和适用场景。数据集被模型训练、算法验证或仿真分析调用后，平台记录其使用情况和输出结果，保证数据集来源清晰、版本可控、使用可追溯。[ 1、初步看，这块内容与前面有很多类似重复，全文认真梳理；][已修改，此处放在建设方案最前端，统一表述该部分内容的作用，以后不再复述]
|
||||
（6）以统一接口服务支撑业务系统调用
|
||||
平台对外提供统一数据服务接口，各业务系统不直接访问底层数据库、对象存储或文件目录，而是通过平台接口获取所需数据。普通业务数据通过 RESTful API 提供查询、维护和调用能力，实时状态数据、告警数据和任务状态通过 WebSocket 或消息订阅方式推送，音视频、模型文件、仿真结果和文档资料通过文件服务完成上传、下载、预览和归档。
|
||||
平台对接口进行统一管理，记录接口名称、接口地址、请求方式、入参说明、返回字段、调用系统、调用权限、调用日志和异常信息。通过统一接口服务，降低各业务系统对接成本，避免系统之间直接访问数据库造成耦合和安全风险。
|
||||
（7）以模型侧支撑形成数据分析闭环
|
||||
平台为故障诊断、状态评估、故障预测、特征提取和仿真分析等模型侧应用提供数据支撑。模型侧系统通过平台获取标准化后的状态数据、波形数据、特征数据、工况数据、历史数据、数据集和质量标识，基于统一设备编号、测点编号、时间范围和数据质量信息开展模型推理和算法分析。
|
||||
模型运行完成后，将诊断结果、故障类型、故障等级、故障位置、置信度、预测结果、诊断建议和分析报告回写至平台。平台将模型输出结果与输入数据、设备对象、测点对象、算法版本、任务记录和数据集建立关联，形成从数据输入、模型分析、结果回写到结果归档的闭环管理。
|
||||
（8）以大屏数据项管理提升展示开发效率
|
||||
平台为实时监测大屏、故障诊断大屏和虚拟仿真大屏提供统一数据支撑。大屏所需数据项由平台统一维护，包括数据项名称、数据来源、调用地址、刷新周期、统计口径、返回字段、展示类型和启停状态。
|
||||
实时监测大屏可通过平台获取系统运行状态、设备状态、关键运行参数、告警信息和服务健康状态。故障诊断大屏可获取故障统计、波形数据、特征数据、模型运行状态和诊断结果。虚拟仿真大屏可获取工况数据、仿真模型、仿真任务、仿真结果和分析报告。通过大屏数据项配置化管理，减少大屏前端与底层接口的强绑定，提高后续指标调整和页面维护效率。
|
||||
（9）以微服务架构保障平台扩展能力
|
||||
平台后端采用 Spring Cloud 微服务架构，将数据接收服务、数据资源服务、数据集服务、文件服务、算法任务服务、大屏数据项服务、接口服务、权限认证服务和运行监控服务进行模块化拆分。各服务职责清晰，能够独立开发、独立部署和独立扩展。
|
||||
平台前端采用 Vue3、Element Plus 和 ECharts 建设数据管理门户、大屏配置页面、数据集管理页面、算法任务页面、历史数据查询页面和可视化展示页面。平台通过统一网关对外发布接口，并结合权限控制、日志审计、接口监控和异常告警能力，保证系统稳定运行。
|
||||
（10）以安全运维体系保障长期运行
|
||||
平台建设统一认证、角色权限、接口权限、数据权限、日志审计、服务监控、接口监控、任务监控、数据质量监控和异常告警能力。用户访问平台功能和数据资源时，系统根据角色和权限进行控制。数据查询、文件下载、接口调用、数据导入、数据标注、算法上传、任务执行和配置修改等操作均记录审计日志。
|
||||
平台对数据接收状态、接口调用状态、任务执行状态、服务运行状态、存储容量和异常信息进行持续监控，发现异常后进行告警提示和日志追溯，保障平台具备可运行、可维护、可追踪和可扩展能力。
|
||||
2.总体设计
|
||||
2.1设计遵循准则
|
||||
系统故障预测与健康管理数据应用平台，按照“统筹组织、顶层设计、分期实施、兼顾差异”的推进思路，各研发人员密切配合，从总体布局上做好顶层设计。
|
||||
总体系统架构按照服务的技术框架（云平台+微服务）和灵活的业务架构设计。业务架构参考“业务中台”的设计思路，沉淀公共的服务和数据，如跨系统运行状态和参数统一监测、数据监管、服务器运行监测分析等核心能力。
|
||||
为保证总体架构设计的先进性、成熟性和可实施性，在总体架构设计过程中，遵循“业务驱动”的原则，采用业务架构分析、应用架构设计到系统架构设计的三步设计方法。
|
||||
结合国内物联网 “标准化、集约化、安全化” 的建设要求，以及文档中平台的设计理念，遵循以下准则：
|
||||
2.1.1标准化先行
|
||||
以标准领先、建设规范、持续改进、争创一流为标准化指导方针，以前瞻性、适用性、渐进性为工作原则，以业务需求为导向，以系统设计为指导思想，基于统一的云平台进行规划设计，建设统一的数智化平台技术标准规范，规范业务流程标准、数据交换规范、业务协同方式等，形成统一的标准化常态运维机制，有效提升平台建设质量。
|
||||
统一设备接入标准：规范设备通信协议、接口规范与数据格式，打通多源异构数据接入壁垒，实现不同厂家、类型采集装置无缝对接，消除多源异构数据带来的设备互联与数据孤岛问题。统一数据模型：依据平台数据治理要求，建立覆盖故障数据、工况数据、监测指标、故障波形、报警规则、可视化数据项的标准化数据模型，统一业务语义，确保数据一致性、可信性与可复用性，构建标准化业务数据资产。
|
||||
2.1.2数据驱动决策
|
||||
围绕核心需求，立足边缘侧资源受限场景，构建承上启下的边缘智能化健康管理数据底座，打通数据全链路闭环，实现数据统一管理、高效复用、智能调度，为数字孪生系统及上层应用提供标准化、可信化、敏捷化的数据支撑。
|
||||
全生命周期管理：构建数据接入 — 数据治理 — 数据存储 — 数据加工 — 数据服务闭环管理体系，通过全流程数据处理，形成故障数据集、工况数据集、故障监测指标等可信可复用数据资产，避免上层应用重复加工，实现数据能力高效复用。云边协同处理：采用云边协同分布式处理架构，依据算力需求、数据量与实时性要求，协同调度数据抽取、特征计算、故障预测等任务在各层级设备运行，优化资源利用，提升整体数据处理效率。
|
||||
2.1.3安全可控底线
|
||||
全链路安全防护：围绕标准化、可信、可追溯、高可用核心目标，构建设备接入、数据传输、存储加工、应用访问全链路安全机制，结合权限管控、操作审计、备份恢复、系统自检，保障平台稳定运行与数据安全可信。
|
||||
2.1.4弹性扩展适配
|
||||
架构可扩展：采用松耦合、分布式、高可用设计，支持横向扩展，动态适配设备接入规模、数据流量与业务场景增长。接口开放兼容：管理原始数据与上层应用数据项关联关系，向上提供语义明确、封装完善的数据服务，屏蔽底层异构复杂性，降低应用接入与运维成本，为故障诊断、虚拟仿真、数字孪生等上层应用提供敏捷支撑。
|
||||
2.1.5微服务化设计
|
||||
通过微服务化设计，实现系统内部松耦合、高内聚，提高系统性能与可扩展性。
|
||||
通过流程分析和流程分解抽取出业务组件，并对业务微服务之间的交互进行描述，详细说明交互点和交互场景。随后细化进入到一个业务微服务内部，对系统用例之间的相互调用进行描述。架构分层后，将各个业务微服务拆分为多个技术微服务，包括展示层微服务，应用层微服务，逻辑层微服务等。再根据业务交互、用例交互，分析微服务之间的调用关系，通过业务和流程分析的方法来定义微服务间的接口。微服务之间的调用只能通过接口，经过封装的微服务内部逻辑对外呈完全黑盒。
|
||||
构建的微服务需要定义规范的接口，才能正确“安装”到系统中。微服务因各自接口不同而相互差异，微服务可以重新构建，但必须严格按照原有设计规范定义接口，否则会造成整个系统出现异常。规范的接口定义，使得模块之间界限明确，系统更加松耦合。同时微服务的复用能够使系统高内聚，方便了后期的维护与再开发。
|
||||
微服务化设计使得系统开发过程中可以“即插即用”地快速构造应用软件。不仅可以节省时间和经费，提高工作效率，而且可以产生更加规范、更加可靠的应用软件。
|
||||
系统内部松耦合、高内聚除可提高系统的可扩展性外，更重要的是可以充分利用云计算技术所带来的优势，即资源的弹性伸缩能力与自动化运维能力，大幅提高系统的性能和用户体验。
|
||||
2.2总体设计方案
|
||||
2.2.1总体架构[ 1、前面已有“架构设计”章节，又需要“总体架构”？把各层级“架构”细化描述清晰；][已修改]
|
||||
根据项目建设内容，遵循数智化系统建设架构体系，打造1个平台、2层服务N个应用的“1+2+N”模式的某系统故障预测与健康管理平台，进行总体规划、统一设计开发和实施应用。
|
||||
|
||||
图 1系统架构图
|
||||
“ 1”个平台，是支撑整个系统的统一技术平台底座，承载业务应用子系统，为各子系统提供基础技术与数据的支撑与服务。
|
||||
“2”层服务+“N”个应用，是云平台本身的N个应用，主要为了业务灵活调整数据服务为服务层应用提供数据，同时，服务应用层为各个子系统独自建立的业务应用满足平台不变，业务自建，持续服务，自由扩展。
|
||||
平台是一个统一的整体，以平台建设理念为基础，根据行业当前管理需要，总体规划、统一设计开发和分批分期实施应用，遵循行业系统建设标准、规范体系和安全保障体系。
|
||||
2.2.1.1.终端设备资源管理
|
||||
平台具备多类型终端设备统一资源管理能力，可全面适配现场各类采集终端、传感设备、边缘网关等异构设备，实现终端资源集约化、标准化、可视化管控。平台支持多协议兼容接入，可适配各类终端的通信适配需求，有效匹配前端ZeroMQ、MQTT双协议的数据传输架构，实现高低频数据终端的全覆盖接入。
|
||||
系统可对所有接入终端进行统一台账管理，自动录入设备编号、类型、点位信息、部署位置、运行参数等基础信息，形成完整的设备资源档案。平台支持终端权限管控、参数远程配置、状态运维及生命周期全流程管理，有效规避设备接入混乱、资源闲置、运维滞后等问题，保障海量终端稳定、有序、协同运行，为平台数据精准采集、高并发接入提供可靠的终端资源支撑。
|
||||
2.2.1.2.数据处理与存储
|
||||
平台按数据特征实行分类型采集、差异化存储架构：通过边缘采集终端统一采集现场时序数据与业务结构化数据。
|
||||
设备测点等高频采样时序数据，具备采集频率高、数据量大、时序连续性强的特点，实时接入后经清洗、去重、补点预处理，写入涛思时序数据库，依托其高吞吐、压缩率高、时序查询高效的优势，支撑实时监控、趋势分析、历史回溯与秒级聚合统计。
|
||||
系统管理、日志管理、配置管理、模型管理、任务管理等业务结构化数据，关联性强、变更频次低、需强事务一致性，经数据规整校验后统一存储到数据库[ 1、哪里来的设计输入？][已修改]，保障数据完整性、权限管控与复杂关联事务查询。
|
||||
两类数据按业务逻辑解耦存储，兼顾时序数据写入查询性能与业务数据安全可靠、事务可控，适配平台整体数据治理与业务应用需求。
|
||||
2.2.1.3.业务数据高并发接入
|
||||
平台采用ZeroMQ+MQTT双协议消息队列架构，实现业务数据高并发、低延迟、稳定可靠的接入能力，有效适配高低频数据差异化传输需求。
|
||||
针对高频时序数据，采用ZeroMQ进行发布-订阅传输，依托其高性能、低时延、高吞吐特性，支撑百万级传感器测点并发采样与实时推送，无需中间代理即可实现端到端高速数据传输，保障高频数据毫秒级上报，满足实时采集、连续传输与高并发写入需求。
|
||||
针对低频业务数据，采用MQTT轻量级协议接入，适配终端多、连接分散、带宽有限场景，支持海量设备异步连接、消息持久化与断点续传，保障低频业务数据稳定可靠接入，降低连接资源消耗。
|
||||
整体接入层实现“协议隔离、流量削峰、负载均衡”，有效应对高并发、大流量冲击，确保高低频数据有序分发、不丢包、不拥堵，为后端涛思数据库提供稳定、高效的数据输入支撑，满足平台高并发接入与长期稳定运行需求。
|
||||
2.2.2业务架构
|
||||
业务架构遵循1+3横向设计规范，统一个安全体系、统一的标准体系、统一的运维体系三个“统一”体系覆盖一个平台。业务架构图如下：
|
||||
|
||||
图 2 业务架构图[ 1、图按照黑白灰色为主重构，提供Visio可编辑版本，这个配色过于复杂；下述图片类同修改；]
|
||||
层级 说明
|
||||
表现层 PC端大屏展示，用户交互媒介
|
||||
应用层 提供业务服务（用户管理、硬件监控、系统日志、系统自检、模型管理、历史数据、文档数据、监测大屏、配置管理、备份恢复、数据溯源等）
|
||||
支撑层 数据接入、清洗、转换、存储的基础服务
|
||||
数据采集层 采集数据服务（高频板卡数据采集、低频板卡数据采集）
|
||||
数据网关层 数据交换、数据安全等保障措施
|
||||
设施层 网络硬件等基础资源
|
||||
|
||||
2.2.2.1.数据统一管理
|
||||
统一数据服务平台作为数据资源的集中接收和管理入口，。现场采集数据由前端采集链路和数据网关完成接入、解析和标准化封装后，输出至统一数据服务平台。平台侧负责接收已经标准化的数据对象，并按照平台数据规范进行校验、入库和后续管理。
|
||||
除实时采集数据外，平台同时接收故障波形文件、特征数据文件、工况数据文件、仿真模型文件、仿真结果文件、音视频资料、文档资料和模型分析结果等数据资源。对于接口类数据，平台通过标准API或消息通道进行接收；对于文件类数据，平台通过文件上传、导入或系统接口方式进行接收；对于结果类数据，平台通过模型侧或业务系统回写接口进行接收。
|
||||
2.2.2.2.业务数据存储
|
||||
平台采用分类型存储方式建设数据资源存储体系，不将所有数据简单存入单一数据库，而是根据数据特征选择合适的存储方式。
|
||||
存储类型 数据内容 技术选型 国产化支持
|
||||
时序数据库 状态数据、实时监测数据、历史趋势数据 涛思TDengine/KaiWuDB ?
|
||||
关系型数据库 设备信息、测点信息、用户权限、接口配置、数据集信息 主流数据库 ?
|
||||
对象存储 故障波形文件、特征数据文件、仿真模型、音视频资料、文档资料 MinIO
|
||||
缓存服务 高频访问的实时快照提供极速查询支撑 Redis
|
||||
|
||||
2.2.2.3.API开放
|
||||
平台内置标准化API开放接口体系，面向第三方系统、上层业务平台及应用终端提供安全、稳定、通用的数据交互与业务调用服务，实现跨系统的数据互通与能力共享。平台接口适配性强，可对接各类异构业务系统，支持时序数据、设备资源数据、业务台账数据的查询与推送，覆盖数据查询、设备管控、状态获取、业务同步等核心场景。
|
||||
接口遵循通用开发规范，支持权限校验、身份认证、请求限流与日志记录，有效防范非法访问与高频请求冲击，保障接口调用安全稳定。同时支持灵活的接口适配、拓展与调试，可根据业务需求自定义调用规则，适配不同场景的集成需求。通过标准化API接口，可快速实现平台与外部系统的无缝对接，打破数据孤岛，充分释放平台采集、存储、设备管理的数据价值，大幅提升系统整体的开放性、兼容性与可扩展性。
|
||||
2.2.2.4.国产化适配
|
||||
平台具备完善的软硬件国产化适配与跨环境兼容能力，全面适配主流运行环境与国产信创生态体系，可满足各类国产化部署与安全替代应用场景。硬件层面全面兼容X86、ARM两大主流硬件架构，适配不同服务器与终端硬件部署环境，具备极强的硬件通用性与扩展性。操作系统层面同时支持Windows、Linux通用主流系统，深度适配麒麟国产操作系统，完成系统内核、运行组件、服务调度的全维度兼容适配，可稳定运行于国产化终端与服务器设备。
|
||||
数据库生态高度适配国产数据库体系，有效兼容达梦、涛思、庚顿、KaiWuDB等国产主流数据库，可实现业务结构化数据、时序数据的稳定读写、存储与调用。平台通过全方位的国产化适配改造与兼容性优化，解决了软硬件异构适配难题，摆脱对国外生态的依赖，保障系统部署、运行、数据存储的自主可控，充分满足信创建设要求，适配政企国产化替代与安全合规部署需求。
|
||||
2.2.3技术架构
|
||||
|
||||
本平台采用 Spring Cloud 微服务架构进行建设，以统一数据服务平台为核心，将系统能力拆分为一组职责清晰、边界明确、可独立部署、可独立扩展的服务单元。各微服务通过统一网关、服务注册发现、标准API、统一认证和内部服务调用机制进行协同，共同支撑数据接收、资源管理、数据集管理、文件管理、算法任务管理、大屏数据项管理、接口服务、权限控制、日志审计和运行监控等平台能力。
|
||||
通过微服务架构，平台能够避免传统单体系统功能耦合度高、部署复杂、扩展困难的问题，实现业务模块解耦、基础能力复用、服务弹性扩展和数据能力统一输出。平台在建设过程中结合缓存、对象存储、分类型数据库、消息订阅、接口网关和容器化部署等技术手段，提升系统在多业务系统接入、高并发访问、大文件管理、实时数据服务和大屏展示场景下的运行能力。
|
||||
2.2.3.1.服务拆分与业务解耦
|
||||
平台按照业务职责和数据边界进行服务拆分，形成数据接收服务、数据资源服务、数据集服务、文件资源服务、算法任务服务、大屏数据项服务、接口服务、权限认证服务、日志审计服务和运行监控服务等核心微服务模块。各服务只负责自身业务范围内的功能处理，通过标准接口与其他服务协同。
|
||||
这种拆分方式使各模块能够独立开发、独立测试、独立发布和独立扩容。当某一服务访问压力较大时，可单独增加该服务实例，而不影响其他服务运行，从而提升平台整体弹性和维护效率。
|
||||
2.2.3.2.统一网关与接口治理
|
||||
平台通过API网关作为统一服务入口，对外提供统一访问地址、统一路由转发、统一认证鉴权、统一接口限流和统一日志记录。外部业务系统、前端页面和第三方应用不直接访问后端微服务，而是通过网关调用平台能力。
|
||||
通过统一网关，平台能够集中管理接口访问路径、调用权限、接口版本、请求转发和异常响应，降低系统对接复杂度，提升接口安全性和可维护性。
|
||||
2.2.3.3.服务注册发现与集中配置
|
||||
平台采用服务注册与发现机制实现服务实例动态管理。各微服务启动后自动注册到注册中心，调用方通过服务名称发现目标服务实例。当服务实例扩容、下线、迁移或异常时，平台能够通过注册发现机制动态感知，保证服务调用链路稳定。
|
||||
平台同时建立统一配置管理机制，将服务参数、接口地址、开关配置、运行配置和环境配置进行集中维护。不同环境下的服务配置可统一管理和动态调整，避免配置分散在各服务内部造成维护困难。
|
||||
2.2.3.4.高并发访问与性能支撑
|
||||
平台通过缓存、对象存储、分类型数据库、接口聚合和异步处理等方式提升高并发访问能力。对于热点数据、实时状态、任务状态、大屏指标和常用配置，平台使用 Redis 缓存降低数据库访问压力。对于波形文件、音视频、模型文件、仿真结果和文档资料，平台使用 MinIO 对象存储进行统一管理，避免大文件直接占用业务数据库资源。
|
||||
对于结构化业务数据、时序监测数据、检索数据和文件数据，平台分别采用关系型数据库、时序数据库、检索服务和对象存储承载，使不同类型数据进入合适的数据组件，提高查询效率和系统稳定性。
|
||||
2.2.3.5.消息分发与系统解耦
|
||||
平台通过消息订阅和异步分发机制支撑跨系统数据调用。对于实时状态、任务消息、模型结果、大屏刷新数据和系统通知类数据，可通过消息队列或订阅机制进行分发，避免业务系统之间直接强耦合。
|
||||
通过异步消息机制，平台能够削减瞬时访问压力，提高数据分发效率，并增强系统在多业务系统并发调用场景下的稳定性。
|
||||
2.2.3.6.基础能力复用
|
||||
平台将用户管理、角色权限、接口管理、文件管理、日志审计、数据目录、数据标签、数据质量、数据集管理、算法任务管理和大屏数据项管理等通用能力进行统一封装，形成可复用的基础服务组件。
|
||||
上层故障诊断、虚拟仿真、数字孪生、实时监测大屏和数据管理门户等应用可按需调用平台能力，不再重复建设相同的基础功能，从而提高系统建设效率，降低后续扩展和维护成本。
|
||||
2.2.3.7.微服务运行治理
|
||||
平台建立完整的微服务运行治理机制，包括服务健康检查、接口限流、熔断降级、异常处理、运行日志、链路追踪和告警监控。系统持续监测各微服务运行状态、接口调用情况、任务执行情况和资源使用情况。
|
||||
当服务异常、接口超时、任务失败或资源占用过高时，平台能够记录异常信息并触发告警，便于运维人员快速定位和处理问题，保障系统长期稳定运行。
|
||||
2.2.3.8.容器化部署与扩展演进
|
||||
平台采用容器化方式进行服务交付和运行管理。各微服务可独立打包、独立部署、独立升级，前端应用、后端服务、缓存服务、对象存储、检索服务和监控组件可统一纳入部署环境管理。
|
||||
当前阶段可采用 Docker 或 Docker Compose 完成服务部署和运行管理，满足现阶段建设需求。随着后续业务规模扩大、服务数量增加和并发压力提升，平台可进一步扩展为 Kubernetes 编排部署模式，实现服务自动调度、弹性伸缩、滚动升级和故障恢复。
|
||||
2.2.3.9.统一数据服务能力输出
|
||||
平台通过微服务体系形成完整的数据能力输出链路。数据接收服务承接标准化数据和文件资源，数据资源服务负责数据目录、标签、质量和检索管理，数据集服务负责样本抽取、标注和版本管理，文件服务负责对象存储文件的上传、下载和预览，算法任务服务负责算法资源和运行任务管理，大屏数据项服务负责展示指标配置和数据输出，接口服务负责统一对外发布数据能力。
|
||||
各服务协同运行，形成从数据接收、分类存储、资源组织、数据集构建、模型调用、结果回写到大屏展示的完整数据服务闭环。
|
||||
2.2.4云边端工作协同[ 1、云边端协同的具体技术途径及功能需补充；]
|
||||
|
||||
|
||||
图 3 云边端协同图
|
||||
采用端 - 边 - 云协同 + 分层解耦的技术架构，以数据全生命周期管理为核心，构建了从设备数据采集、预处理、接入校验、分层存储到业务计算、应用展示与运维管控的完整闭环，实现了数据从原始采集到业务价值挖掘的高效转化，同时兼顾高性能、高可靠、高安全与可扩展性，为工业场景的数字化、智能化升级提供了坚实的技术底座。
|
||||
（一）端侧采集层
|
||||
高频数据采集模块：基于 C++ 开发，利用其高性能、低延迟的特性，适配毫秒级采样的传感器数据、设备实时运行参数等高频率时序数据采集，通过 ZeroMQ 低延迟消息队列协议传输，保障数据采集的实时性与完整性，避免高频数据的丢失或延迟，满足工业设备实时监控的核心需求。
|
||||
低频数据采集模块：基于 Java 开发，利用其跨平台、易集成的优势，适配设备配置信息、日志数据、批量状态数据等非实时低频数据的周期性采集，通过 MQTT 轻量级物联网协议传输，适配低带宽、弱网络环境，降低采集开发成本与传输带宽占用。两种采集方式互补，实现了对端侧设备数据的全面覆盖，同时为不同类型数据选择了最优的传输协议，实现了采集效率与传输成本的平衡。
|
||||
（二）边侧数据网关
|
||||
接收端侧采集层传来的异构数据，将不同协议、不同格式的原始数据进行标准化处理。对时序数据进行时间戳对齐、格式规整，解决端侧数据时间不同步、格式不统一的问题；对不同设备的私有协议进行转换，统一为云端可识别的标准协议；同时根据数据类型与业务需求，对数据进行初步路由分发。
|
||||
（三）云端接入层
|
||||
接收边侧网关上传的标准化数据，通过接入校验机制对数据的完整性、合法性、安全性进行验证，过滤恶意数据、错误数据与非法接入请求；同时通过权限控制机制，对不同来源、不同业务场景的数据进行权限划分，保障数据的安全隔离与合规访问并为上层提供日志管理、用户权限管理、监测等业务服务。
|
||||
2.2.5技术路线
|
||||
本项目以统一数据服务平台为中心，围绕故障诊断、虚拟仿真、数字孪生和综合监测大屏等应用的数据支撑需求，建设覆盖标准化数据接收、数据集中存储、数据资源管理、数据集构建、模型侧数据支撑、统一接口服务和大屏展示支撑的技术体系。平台不重复建设前端采集和数据网关能力，而是在已有数据网关输出的标准化数据基础上，完成数据接收、校验、入库、管理、检索、分发和服务发布，形成面向多业务系统的统一数据服务能力。
|
||||
整体技术路线按照“标准化数据接收、平台集中存储、资源统一管理、模型按需调用、接口统一服务、大屏集中展示”的思路开展建设。通过统一数据服务平台，将现场采集数据、故障诊断数据、仿真数据、音视频数据、文档数据、模型数据和分析结果数据纳入同一管理体系，避免各业务系统重复建设数据存储、数据查询和数据服务能力，提高数据复用效率和系统集成效率。
|
||||
|
||||
|
||||
图 1平台技术路线
|
||||
|
||||
(1)构建平台数据接收通道
|
||||
统一数据服务平台作为数据资源的集中接收和管理入口，对接前端数据网关、故障诊断系统、虚拟仿真系统、数字孪生系统以及相关文件资源。现场采集数据由前端采集链路和数据网关完成接入、解析和标准化封装后，输出至统一数据服务平台。平台侧负责接收已经标准化的数据对象，并按照平台数据规范进行校验、入库和后续管理。
|
||||
除实时采集数据外，平台同时接收故障波形文件、特征数据文件、工况数据文件、仿真模型文件、仿真结果文件、音视频资料、文档资料和模型分析结果等数据资源。对于接口类数据，平台通过标准API或消息通道进行接收；对于文件类数据，平台通过文件上传、批量导入或系统接口方式进行接收；对于结果类数据，平台通过模型侧或业务系统回写接口进行接收。
|
||||
通过平台数据接收通道，各类数据进入平台后统一纳入数据资源管理体系，为后续数据查询、历史追溯、数据集构建、模型调用和大屏展示提供基础。
|
||||
(2)标准化数据接收与校验
|
||||
平台在接收数据时，对数据格式、设备编号、测点编号、采集时间、数据类型、数据来源、质量标识、业务字段和文件属性进行检查。对于状态数据和监测参数，平台重点校验时间戳、测点编码、数据值、单位信息和质量状态；对于波形文件、特征文件、仿真结果、模型文件、音视频和文档资料，平台重点校验文件类型、文件大小、文件完整性、关联设备、关联任务、时间范围和元数据信息；对于模型分析结果，平台重点校验输入数据范围、算法版本、结果类型、结果编号和关联对象。
|
||||
对于符合要求的数据，平台按照数据类型进入后续存储和管理流程。对于字段缺失、格式异常、时间异常、编码不匹配或质量状态异常的数据，平台记录异常接收日志，并形成数据质量记录，便于后续问题追溯和数据修正。通过接收校验机制，保证进入平台的数据能够满足统一存储、统一检索和统一服务要求。
|
||||
(3)形成平台集中存储管理体系
|
||||
平台采用分类型存储方式建设数据资源存储体系，不将所有数据简单存入单一数据库，而是根据数据特征选择合适的存储方式。
|
||||
状态数据、运行参数、实时监测指标和历史趋势数据进入时序数据库，用于支撑实时曲线、历史趋势、状态回放、工况分析和大屏刷新。设备信息、测点信息、通道映射关系、用户权限、接口配置、数据集信息、算法任务信息、大屏数据项配置和业务管理数据进入关系型数据库，用于支撑平台基础管理和业务配置。故障波形文件、特征数据文件、工况文件、仿真模型、仿真结果、音视频资料、模型文件和文档资料进入对象存储，用于支撑大容量文件归档、下载、预览和复用。数据标签、文件说明、故障类型、工况类型、任务编号、设备编号、测点编号和关键字信息进入检索服务，用于支撑数据快速查询和组合检索。热点数据、实时状态、接口令牌、任务状态和临时查询结果进入缓存服务，用于提升平台访问效率和实时展示性能。
|
||||
通过关系型数据库、时序数据库、对象存储、检索服务和缓存服务组合，平台形成轻量化、可扩展、易维护的数据存储管理体系，满足当前项目的数据接入、历史存储、文件归档、快速检索和业务服务需求。
|
||||
(4)建立数据资源组织能力
|
||||
平台对接入后的数据进行统一资源化管理，按照设备对象、测点对象、数据类型、业务系统、任务过程、工况条件、故障类型、仿真场景和时间范围等维度建立数据目录和分类体系。
|
||||
每类数据均记录数据来源、接收时间、采集时间、处理状态、存储位置、质量状态、标签信息、关联设备、关联任务、使用记录和权限范围。用户能够在平台内按照设备、测点、时间、任务、工况、故障类型、数据类型等条件查询数据，能够查看实时数据、历史数据、波形文件、特征数据、仿真结果、模型结果和文档资料。
|
||||
平台通过数据目录和数据标签，使分散在采集链路、故障诊断系统、虚拟仿真系统、数字孪生系统和文件资料中的数据形成统一的数据资源视图。数据不再只是单独的文件或记录，而是具备来源、属性、标签、关联关系和使用记录的数据资源，便于后续查询、复用、分析和追溯。
|
||||
(5)建设数据集管理能力
|
||||
平台面向故障诊断、状态评估、故障预测、虚拟仿真和数字孪生等应用，建设数据集管理能力。平台支持从历史监测数据、状态数据、波形数据、特征数据、故障结果、工况数据、仿真结果和文档资料中按条件抽取样本，形成面向不同业务用途的数据集。
|
||||
数据集管理包括数据集创建、样本抽取、样本查看、数据标注、标签维护、版本管理、导入导出、使用记录和关联结果管理。每个数据集记录数据集名称、数据集编号、数据来源、样本范围、样本数量、标签信息、创建人员、创建时间、版本信息、适用场景和关联任务。
|
||||
平台通过数据集管理，将平台内存储的历史数据和文件资源转化为可用于模型训练、算法验证、仿真分析和结果复核的数据基础。数据集被模型或任务调用后，平台记录其使用过程和输出结果，保证数据集来源清晰、版本可控、使用可追溯。
|
||||
(6)实现模型侧数据支撑
|
||||
平台为故障诊断、状态评估、故障预测、特征提取和仿真分析等模型侧应用提供标准化数据支撑。模型侧系统不直接访问底层采集链路和原始数据格式，而是通过平台获取标准化后的状态数据、波形数据、特征数据、工况数据、历史数据、数据集和质量标识。
|
||||
平台根据模型侧需求，提供实时数据调用、历史数据查询、波形文件获取、特征数据获取、数据集调用和结果回写能力。模型侧基于统一设备编号、测点编号、时间范围、工况标识和数据质量信息进行模型推理和算法分析，输出故障类型、故障等级、故障位置、置信度、预测结果、诊断建议和分析报告。
|
||||
模型运行完成后，诊断结果、评估结果、预测结果和分析报告回写至平台。平台将模型输出结果与输入数据、设备对象、测点对象、时间范围、算法版本、任务记录和数据集建立关联，形成从数据输入、模型分析、结果回写到结果归档的闭环。
|
||||
(7)建设统一数据服务接口
|
||||
平台对外提供统一数据服务接口，支撑故障诊断系统、虚拟仿真系统、数字孪生系统和各类大屏应用调用平台数据。各业务系统不直接访问底层数据库、对象存储或文件目录，而是通过平台发布的标准接口获取所需数据。
|
||||
普通业务数据通过API提供查询、维护和调用能力，包括设备数据、测点数据、历史数据、数据集数据、任务数据、模型结果数据和配置数据。实时状态数据、告警数据、任务状态和关键指标通过 WebSocket 或消息订阅方式提供推送能力。波形文件、音视频文件、仿真结果、模型文件和文档资料通过文件服务完成上传、下载、预览和归档。标签数据、文件资源、历史记录和业务结果通过检索服务实现快速查询。
|
||||
平台对所有接口进行统一管理，记录接口名称、接口地址、请求方式、入参说明、返回字段、调用系统、调用权限、调用日志和异常信息。通过统一接口服务，平台降低各业务系统集成复杂度，提高数据调用的一致性和可维护性。
|
||||
(8)支撑算法任务统一管理
|
||||
平台建设算法资源管理和计算任务管理能力，对故障诊断算法、特征提取算法、状态评估算法、故障预测算法和仿真分析算法进行统一登记、配置、运行和结果管理。
|
||||
算法资源管理包括算法上传、算法登记、算法版本管理、输入输出参数维护、运行环境说明、适用场景说明和算法文件归档。算法文件、模型文件和依赖文件存储在对象存储中，算法名称、算法版本、算法类型、输入参数、输出格式、运行环境和适用范围等信息存储在平台业务库中。
|
||||
计算任务管理包括任务创建、任务配置、任务启动、任务暂停、任务终止、任务状态跟踪、运行日志查看、异常信息记录和结果归档。用户能够基于平台中的数据集和算法资源创建计算任务，配置输入数据、运行参数、输出路径和执行方式。任务执行完成后，平台将输出结果归档，并与输入数据、算法版本、任务参数和业务对象建立关联，实现算法运行过程可监控、结果可追溯、数据可复用。
|
||||
(9)实现大屏集中展示支撑
|
||||
平台为实时监测大屏、故障诊断大屏和虚拟仿真大屏提供统一数据支撑。平台通过大屏数据项管理功能，维护各类展示指标的数据来源、调用地址、刷新周期、统计口径、返回字段、展示类型和启停状态。
|
||||
实时监测大屏展示系统运行状态、设备状态、关键运行参数、告警信息、接口状态和服务健康状态。故障诊断大屏展示故障统计、波形数据、特征数据、模型运行状态、诊断结果和告警趋势。虚拟仿真大屏展示工况数据、仿真模型、仿真任务、仿真结果和分析报告。
|
||||
大屏前端通过数据项编码调用平台接口获取展示数据，不直接绑定底层数据库和原始接口。后续新增展示指标、调整接口地址、修改统计口径或变更展示字段时，通过平台数据项配置完成维护，提高大屏开发效率和后续维护灵活性。
|
||||
(10)形成运维与安全保障能力
|
||||
平台建设统一运维与安全管理能力，包括用户认证、角色权限、接口权限、数据权限、日志审计、服务监控、接口监控、任务监控、数据质量监控和异常告警。
|
||||
用户访问平台功能和数据资源时，系统根据角色和权限进行控制。数据查询、文件下载、接口调用、数据导入、数据标注、算法上传、任务执行和配置修改等操作均记录审计日志。平台对服务运行状态、接口调用状态、任务执行状态、数据接收状态、存储容量和异常信息进行监控，发现异常后进行告警提示和日志追溯。
|
||||
通过运维与安全保障能力，平台能够支撑长期稳定运行，保证数据访问可控、接口调用可查、任务执行可追踪、异常问题可定位。
|
||||
(11)形成平台数据服务闭环
|
||||
通过上述技术路线，项目形成以统一数据服务平台为中心的数据服务闭环。前端数据网关完成现场数据接入和标准化封装后，将标准化数据输出至平台；平台对数据进行接收校验、集中存储、资源组织、数据集管理和统一服务发布；模型侧系统通过平台获取标准化数据和数据集，完成故障诊断、状态评估、故障预测和仿真分析，并将分析结果回写平台；大屏系统通过平台数据项服务获取展示数据，实现跨系统运行状态和关键参数的集中展示。
|
||||
3.软件功能设计
|
||||
按照架构体系的云服务平台，基于采集数据、系统数据等数据集建立应用系统，其中包括但不限于：用户管理、角色管理、权限管理、日志管理、数据服务管理、模型管理等，保证自有业务完整闭环，同时，通过业务情况自定义调整平台信息并为其他子应用提供数据支撑。
|
||||
|
||||
图 4软件功能设计图
|
||||
3.1系统管理
|
||||
提供平台基础权限与配置管控能力，实现多用户、多组织、多角色的精细化安全管理。
|
||||
3.1.1用户管理
|
||||
展示用户信息并支持系统管理员可以在此进行用户的管理和维护，包含用户编号、用户名称、所属部门、用户角色等。可按照部门名称、用户名称等进行查询。支持用户的新增、修改、删除、导入、导出、切换用户状态等操作。
|
||||
3.1.2组织架构管理
|
||||
部门职责即业务职能所具备的权限范围，关联用户到所属部门呈现完整组织架构及所有用户名称信息便于管理信息。支持对组织架构的添加、修改、删除及关联用户信息等操作，支持批量导入、导出、删除操作。
|
||||
3.1.3角色权限管理
|
||||
角色是相同岗位所拥有的一组权限的统称，在系统中体现为一些相关的职责，以及数据权限的范围。用户通过扮演不同的角色来完成权限的控制。角色分为业务类角色和管理类角色，管理类角色只能分配管理类职责，业务类角色只能分配业务类职责。通过角色互斥系统管理员不做业务或业务人员不参与系统管理的情况下设置。支持角色创建、修改、权限分配等操作。
|
||||
|
||||
图 5 角色权限示意图
|
||||
3.1.4数据字典
|
||||
数据字典作为平台元数据管控核心模块，主要实现全系统数据项、数据结构、业务编码及接口字段的集中定义、统一维护与规范引用，明确数据元信息与业务语义，建立完整数据血缘关系，支持对数据字典的定义、修改、删除、启动、停用等操作。
|
||||
3.2服务器监控
|
||||
服务器监控包含基础硬件（内存、CPU、磁盘）等基础信息监测、服务监控（API调用监控、服务在线状态）等及基本日志与链路信息自检等，平台采用Docker部署，基于上述需求与基本条件采用以下技术完成其要求。
|
||||
|
||||
图 6 服务器监控架构图[ 1、所有花花绿绿的图都用黑白灰颜色展示；]
|
||||
集成Node Exporter组件，配置指标采集频率，开发指标数据解析模块，将采集到的原始硬件数据进行清洗、格式化处理，筛选出核心监控指标，同时开发异常监测逻辑，设置CPU、内存、磁盘等指标的阈值，当指标超出阈值时触发初步告警提示。Docker容器监控模块研发中，部署cAdvisor组件，实现对Docker容器的实时监控，开发容器状态解析模块，获取容器的运行状态、资源消耗数据，同时关联服务器硬件指标，实现容器与硬件资源的联动监控，便于定位容器资源消耗异常的根源。
|
||||
在Spring Cloud各微服务中集成Actuator与Micrometer组件，暴露服务健康状态、API调用、JVM运行等相关端点，配置指标采集规则，将微服务指标推送至数据库。同时，开发服务在线状态监测模块，通过心跳检测机制实时判断微服务是否正常运行，当服务下线或响应异常时，及时记录并触发告警。此外，开发API调用监控模块，统计API调用QPS、响应时间、错误率等指标，支持按服务、按接口维度进行数据统计与展示，便于排查慢接口与异常接口。日志与链路追踪模块研发中，部署Filebeat组件采集各微服务及监控组件的日志数据，配置日志收集规则，将日志数据推送至Elasticsearch进行存储，开发日志检索模块，支持按服务、按时间、按日志级别进行日志检索与筛选；同时部署SkyWalking组件，集成Spring Cloud微服务，实现服务间调用链路的自动追踪，开发链路分析模块，展示调用拓扑、各环节耗时，支持慢链路、异常链路的定位与分析
|
||||
所有组件均采用Docker容器化部署，确保与整体平台部署架构一致，同时降低部署与维护成本。
|
||||
3.2.1硬件监控
|
||||
(1)CPU 监控：实时采集 CPU 使用率、核心负载、进程占用率，支持单核心 / 总负载统计。适用：高频数据接入、实时计算、网关转发、容器密集型场景，用于定位计算瓶颈与过载风险。
|
||||
(2)内存监控：实时监控物理内存、缓存占用，识别内存泄漏与资源耗尽风险。适用：时序数据缓存、大流量数据处理、微服务长期运行场景，可提前预警 OOM 风险。
|
||||
(3)磁盘监控：监控磁盘使用率、读写 IOPS、吞吐量、读写延迟，保障时序数据库高速写入性能。适用：数据库高并发写入、长周期数据存储、大文件备份场景。
|
||||
(4)网络监控：实时采集网络带宽、进出流量、丢包率、延迟，保障 100 路高频数据传输稳定。适用：端 - 边 - 云高速数据传输、高频推送、大规模接入、大屏实时刷新场景。
|
||||
3.2.2服务监控
|
||||
(1)微服务监控：监控网关、数据服务、任务调度等微服务在线状态、启动时长、进程存活。适用：Docker 容器化微服务架构、多实例集群、高频接口调用场景。
|
||||
(2)数据库监控：监控数据库连接数、查询响应、写入吞吐量、缓存命中率。适用：海量时序数据写入、高频查询、长周期数据溯源、多业务并发访问场景。
|
||||
3.2.3趋势分析
|
||||
按小时 / 天 / 月生成资源使用趋势曲线。
|
||||
按多时间维度生成资源使用趋势曲线，支撑容量规划与性能优化。
|
||||
小时级趋势：按小时统计资源使用率，定位小时级负载波动规律。适用：实时调度、短时峰值预警、高频采集任务负载分析。
|
||||
日级趋势：按天统计 CPU / 内存 / 磁盘 / 网络峰值、谷值、平均值，识别日常负载特征。适用：日常运维巡检、负载规律分析、异常日对比排查。
|
||||
月级趋势：按月生成资源增长趋势，支撑数据周期存储与扩容规划。适用：数据增长预测、硬件扩容、存储规划、长期运维投入分析。
|
||||
3.3日志管理
|
||||
日志管理模块统一管理系统日志、操作日志及配置日志，支持按需设定定期备份规则（如按时间间隔、固定周期）。模块自动将历史日志归档至指定存储位置，避免数据堆积影响性能。确保日志数据的完整性与可追溯性，满足审计、排障及合规要求。
|
||||
|
||||
图 7 日志管理流程图
|
||||
3.3.1操作日志
|
||||
操作日志主要用于记录用户在系统中的各类关键行为，涵盖用户登录认证、配置修改、数据导出、设备控制等核心操作，核心目的是为系统安全审计工作提供可靠依据，同时便于后续出现问题时快速追溯根源、界定责任，保障系统安全稳定运行，防范数据泄露、操作异常等风险。采集范围重点聚焦与系统安全、数据安全及业务正常运转密切相关的关键操作，确保采集无遗漏、重点不偏差。具体采集范围包括：用户登录操作，需同时记录登录成功与登录失败两种场景，全面掌握用户登录动态；用户角色权限变更操作，涵盖角色分配、权限调整、权限回收等所有涉及权限变动的操作；系统黑白名单规则修改操作，包括名单新增、删除、编辑等相关操作；各类数据导出操作等。
|
||||
每一条日志记录需完整包含各类核心信息，确保内容详实、准确。具体记录内容包括但不限于：操作人账号、操作时间、客户端IP、操作模块名称、操作类型（登录、修改、导出、控制）等、请求参数、执行结果等。
|
||||
操作日志统一存入数据库，结合业务实际需求优化存储结构，提升日志存储的规范性和实用性。数据库需支持按操作时间、操作人账号、操作模块等关键维度进行快速检索，便于工作人员在开展安全审计、排查问题时，能够快速定位相关日志记录，提升工作效率。同时，建立完善的日志备份机制，定期对日志数据进行备份，确保日志数据长期留存、不丢失，满足安全审计和合规管理的相关要求，为系统安全运行筑牢数据保障。
|
||||
支持按照多条件组合检索（用户、时间范围、模块、操作类型、结果状态）等检索，结果支持导出为指定格式。
|
||||
3.3.2系统日志
|
||||
系统日志主要用于采集服务运行过程中的各类关键事件，重点涵盖服务启动停止、异常报错、接口调用性能等核心运行数据，其核心作用是为系统日常监控提供数据支撑，同时在系统出现故障时，能够快速定位问题根源、排查故障原因，保障服务稳定、高效运行，降低系统故障对业务开展的影响。采集内容为服务运行状态事件，涵盖服务启动、停止、重启的全过程，全面掌握服务运行生命周期；数据库连接池状态，实时采集连接池的连接数量、空闲连接、占用连接等关键指标，及时发现数据库连接异常；Redis连接状态，监控Redis连接的建立、断开及连接稳定性，防范缓存服务异常；接口调用相关数据，记录所有接口调用的耗时情况及执行结果，精准掌握接口性能表现；定时任务执行记录，完整采集定时任务的启动时间、执行时长、执行结果等信息，确保定时任务正常运行。
|
||||
日志显示信息包含但不限于：发生时间、服务名称、实例ID、日志级别、线程ID、类名方法名、日志消息、异常堆栈。
|
||||
支持按照多条件组合检索（时间范围、服务名称、级别，方法名称）等检索，结果支持导出为指定格式。
|
||||
3.3.3日志配置
|
||||
采用Spring Scheduler实现定时任务调度，结合Spring Cloud Config实现日志配置集中管理，配合MinIO作为对象存储介质，实现各类型日志的差异化处理，确保方案的可行性和可扩展性。
|
||||
用户针对不同类型日志输入策略执行周期，制定差异化清理策略，适配各日志的核心需求：操作日志采用“周期归档+超时删除”模式，通过Spring Scheduler配置定时任务，按预设周期（如30天）对操作日志进行归档，归档完成后，自动删除超出设定周期（如90天）的日志数据，既保留必要追溯数据，又避免无效占用存储；系统日志采用“在线保留+压缩归档+超时删除”三级处理，保留预设周期（如15天）的在线数据，超过该周期的日志上传至MinIO对象存储，对象存储中保留周期（如180天）届满后，自动执行删除操作。
|
||||
自动归档功能通过Spring Scheduler配置每日凌晨00:00执行定时任务，任务执行存入专用归档记录表，便于后续校验日志完整性、追溯归档过程，避免归档数据丢失或篡改。
|
||||
此外，通过Spring Cloud Config动态配置各周期参数、优先级规则，无需重启服务即可调整日志配置，提升方案的灵活性和可维护性。
|
||||
3.4备份与恢复
|
||||
备份与恢复模块提供数据与配置的高可用保障，结合实际业务应用场景满足数据溯源要求[ 1、核实需求；][已修改，虽然之前表述按照合同规范写的，但应按照业务实际场景及未来扩展性来考虑]。支持时序库增量备份、关系库全量备份，提供手动与自动备份策略；支持单表/全库恢复及指定时间点回滚；具备备份文件完整性校验、备份失败告警及异地存储能力，全面提升系统灾备等级。
|
||||
3.4.1数据备份
|
||||
针对不同类型数据库采用差异化备份策略，在保障数据一致性的前提下兼顾存储效率。
|
||||
|
||||
图 8 数据备份流程图
|
||||
时序库，采用增量备份结合时间分区快照的策略，贴合时序数据按时间有序存储的特性。依托Spring Scheduler配置每日凌晨定时任务，执行备份操作前，自动调用时序库原生接口完成数据压实与合并，清除冗余数据、减少备份体积，提升存储效率；随后生成完整的时间分区快照，同时捕获自上次备份以来的变化数据，执行增量备份。系统自动维护增量备份链，当增量备份超出预设保留周期（如30天），自动将该周期内的所有增量备份合并至全量归档，既保留完整的数据追溯链路，又避免增量备份过多占用存储资源，备份过程中通过Spring Cloud Task监控执行状态，确保数据一致性。
|
||||
关系库，采用每日凌晨逻辑备份策略，导出完整 SQL 文件。针对超千万行大表，按主键范围分片，借助多线程或 Spring Cloud LoadBalancer 并行导出各分片 SQL，最终合并为完整文件。导出文件实时压缩并按日期命名，保留 30 天后自动清理。通过 Spring Cloud Task 监控任务状态，确保数据一致性。方案简单可靠，业务无感知。
|
||||
|
||||
图 9 关系数据库备份流程图
|
||||
自动备份策略支持用户可视化交互页面自定义备份窗口（如02:00-05:00），系统根据预设的备份周期（按天/周/月），由Spring Scheduler自动触发备份任务，无需人工干预。用户可灵活配置各类备份的保留周期（如时序库全量归档保留90天、关系库全量备份保留7天），超过保留周期的备份文件自动清理，优化存储资源利用。
|
||||
此外，方案集成备份校验与告警机制，备份完成后自动校验备份文件的完整性（对比校验和），若校验失败或备份任务异常，通过Spring Cloud AlertManager发出告警信息，通知运维人员及时处理；同时支持备份文件的手动恢复操作，通过备份ID即可快速定位备份文件，执行恢复流程，确保数据可快速恢复，进一步保障数据安全性与业务连续性。
|
||||
3.4.2备份恢复
|
||||
表恢复适用于小范围数据错误，用户选择目标数据表后，系统自动备份当前表状态，恢复完成后生成数据比对报告。全库恢复用于灾难性故障，用户选择备份点后，系统先校验备份文件完整性并提示确认覆盖，支持恢复至原实例或新实例。
|
||||
指定时间点回滚基于全量+增量备份，用户选择目标时间点，系统自动定位最近全量备份并回放后续增量日志，回滚后自动校验数据一致性（主键、外键、业务指标）。
|
||||
3.4.3备份校验
|
||||
为保障备份数据可用性，防范备份文件损坏、缺失导致的恢复失败，结合系统备份体系要求，建立自动化备份文件完整性校验及分级告警机制，确保备份数据真实有效，为数据恢复提供可靠支撑，保障业务连续性，方案贴合常规建设规范，具备较强可实施性。
|
||||
备份校验依据两种方法：一是文件大小校验，提取备份文件实际大小，与备份元数据记录比对，差值超出±1%预设范围则判定异常；二是文件数量校验，扫描备份存储目录统计实际文件数，与元数据比对，出现缺失、多余文件即判定异常，全面保障备份文件齐全有效。每次备份任务（全量、增量、配置备份等）结束后，系统自动触发快速校验，聚焦大小、数量核心项，高效执行且不影响业务运行，同时记录校验过程及结果，生成日志便于追溯。
|
||||
建立分级告警机制，备份或校验失败时，系统提示告警信息，内容包含失败时间、数据源、具体原因（如存储空间不足、文件损坏等）及处置建议。告警分两级：“警告”适用于轻微不一致且可自动修复场景，无需人工介入；“严重”适用于备份不可用场景，需人工紧急介入处置，避免备份失效。
|
||||
系统自动记录告警信息及处置过程，形成完整台账，支持运维人员集中查看、筛选告警，持续优化机制，全面保障备份文件可用性。
|
||||
3.4.4异地存储
|
||||
为提升系统灾备能力，满足地理冗余及合规溯源要求，系统支持将备份文件自动上传至指定存储节点，通过科学的上传策略与异地保留规则，确保备份数据安全可控、可追溯，为数据灾备提供可靠支撑。
|
||||
备份文件生成后，先在本地节点留存，同时启动异步上传流程，将文件推送至异地存储节点，避免上传操作阻塞主业务，兼顾数据安全性与业务效率。系统支持配置多个异地存储节点，采用“主+备”架构，当主异地节点上传失败时，自动切换至备节点继续上传，确保上传任务不中断，保障异地备份的连续性。上传完成后，系统自动在备份元数据中记录具体上传时间，便于后续追溯管理。
|
||||
年度归档备份实行专项管理，每年12月31日系统自动将全年所有备份数据打包为不可变归档包，异地长期保存10年，严格满足长期周期溯源及合规要求，确保数据可长期追溯、不可篡改。
|
||||
3.5系统自检
|
||||
系统自检模块实现了对平台整体运行健康状况的自动化检测能力，支持对网关、数据库、缓存、消息队列、微服务等核心组件的可用性检测，以及对端-边-云数据传输链路的连通性与延迟检测。通过周期性或手动触发的自检任务，系统能够提前发现潜在隐患，降低故障发生风险，提升平台的可靠性与可维护性。
|
||||
系统自检模块采用分布式检测架构，支持多节点并发执行自检任务，检测结果统一汇总并生成结构化自检报告。模块设计遵循高内聚、低耦合原则，支持插件化扩展检测项，便于后续根据业务需求增加新的检测维度。
|
||||
3.5.1服务自检
|
||||
服务自检功能核心用于实时检测平台内部关键服务的可用性，全面排查服务运行异常，保障平台整体稳定运行，为运维人员提供精准的服务状态反馈，便于及时发现并处置潜在故障。其检测范围覆盖平台核心服务，具体包括：网关服务，重点检测API网关的连通性、响应时间及错误率，确保网关正常转发请求、响应高效且异常可控；数据库服务，聚焦主从数据库的连接状态、读写延迟及事务执行能力，保障数据存储与交互稳定；缓存服务，检测Redis等缓存服务的连接状态、读写性能及内存使用率，防范缓存失效或性能瓶颈；消息队列服务，核查消息中间件的生产者、消费者运行状态及队列堆积情况，避免消息阻塞影响业务；微服务，监测注册中心中各微服务的健康状态、心跳信息及调用链路通畅性，确保微服务间协同运行正常。
|
||||
|
||||
|
||||
图 10 服务自检架构示意图
|
||||
3.5.2链路自检
|
||||
链路自检功能核心用于检测端-边-云三层架构中数据传输链路的连通性与延迟，专门适配边缘计算、物联网等复杂部署场景，通过全方位链路检测，保障三层架构间数据传输顺畅、稳定，为复杂场景下的业务正常运行提供支撑。其检测内容按链路层级分层开展，具体如下：端侧链路检测，重点核查终端设备与边缘节点之间的网络连通性，同步监测终端向边缘节点上报数据的延迟情况，确保端边数据交互基础通畅；边侧链路检测，聚焦边缘节点与云端平台之间的数据传输稳定性，同时监测带宽利用率，防范传输中断或带宽瓶颈影响数据同步；端-边-云全链路检测，通过模拟业务数据从终端生成、边缘节点处理到云端平台汇聚的完整业务流程，全面检测各环节的响应时间与丢包率，精准排查全链路中的传输隐患，保障全流程数据传输高效、无异常。
|
||||
|
||||
图 11 端-边-云链路自检示意图
|
||||
3.5.3自检报告
|
||||
自检报告功能用于自动生成结构化的自检结果，支持查看与历史回溯。报告内容包括：
|
||||
检测时间：自检任务的开始与结束时间。
|
||||
异常详情：异常组件的错误信息、建议处理措施。
|
||||
报告支持导出为PDF或JSON格式。
|
||||
3.6监测大屏
|
||||
监测大屏模块实现了设备运行状态的实时可视化展示能力，支持100路10kHz高频时序波形的同步展示，以及设备工况、通道状态、采集数据等关键信息的集中监控。通过大屏直观呈现，运维人员可快速掌握系统全局状态，及时发现异常并定位问题。
|
||||
监测大屏采用 B/S 架构设计，基于 HTML5 + WebSocket 全双工通信技术实现数据实时推送，摒弃传统 HTTP 轮询方式，减少频繁请求响应带来的网络开销与时间损耗，数据由服务端主动推送至前端，省去客户端重复发起查询的等待环节。系统采用轻量化数据协议与高效序列化传输方案，精简报文体积、降低解析耗时，配合前端异步渲染与增量数据更新策略，避免全量重绘造成的性能损耗，可稳定满足端到端 200ms 以内低延迟要求，确保监测指标、状态变化毫秒级同步，显著提升数据刷新实时性与画面流畅度。同时支持多屏拼接，可灵活适配监控大厅等多场景大屏展示需求，实现数据可视化统一呈现。
|
||||
3.6.1波形实时展示
|
||||
支持最多100路通道的10kHz高频时序波形实时绘制，如同所示
|
||||
|
||||
图 12 波形展示示意图
|
||||
关键技术指标如下：
|
||||
表 1波形展示技术指标
|
||||
指标 参数
|
||||
最大通道数 100路
|
||||
采样频率 10kHz（每通道每秒10000个数据点）
|
||||
波形类型 电压、温度
|
||||
|
||||
支持缩放拖拽：鼠标悬浮查看局部细节。
|
||||
3.6.2通道状态展示
|
||||
通道状态区用于监控各采集通道的运行状况：
|
||||
|
||||
表 2 单通道波形示意图
|
||||
展示项 说明
|
||||
通道编号 1-100通道标识
|
||||
连接状态 已连接/断开/异常
|
||||
当前采样率 实际采样频率（Hz）
|
||||
3.6.3采集数据展示
|
||||
采集数据区展示各通道的实时数值与统计特征：
|
||||
实时数值：当前瞬时值，以数字形式刷新
|
||||
统计特征：平均值、有效值
|
||||
图 13 采集数据实时展示示意图
|
||||
3.7配置管理
|
||||
3.7.1设备管理
|
||||
提供设备管理界面，支持设备的接入、注册、编辑与删除操作。可维护设备的基本信息，包括但不限于设备型号、设备参数、所属单位、设备状态等。
|
||||
|
||||
图 14 设备管理列表
|
||||
3.7.2通道管理
|
||||
提供通道配置界面，支持对每个采集通道进行独立配置，包括采集频率、量程、通道类型、采样精度、采集周期等参数。支持通道的启用/停用、参数修改与配置历史记录查看，确保采集过程可追溯。
|
||||
|
||||
图 15 通道管理列表
|
||||
3.7.3采集配置
|
||||
支持启动或停止采集任务，可根据实际需求动态调整采集频率或采集策略。采集控制支持单设备、单通道操作，具备任务优先级配置与采集状态实时反馈能力。
|
||||
提供在线数据预览界面，支持查看通道原始数据、实时波形图、数值曲线等展示形式。可根据时间范围或采集点进行数据回放与比对分析，便于运维人员快速判断采集状态与数据质量。
|
||||
|
||||
图 16 通道数据实时预览
|
||||
3.8模型管理
|
||||
模型管理模块为数字孪生、故障诊断、虚拟仿真等上层应用提供统一的模型支撑能力，支持模型的全生命周期管理，支持模型录入、版本控制、部署与使用跟踪等功能
|
||||
系统提供模型上传与管理界面，支持多种类型的模型文件上传，其中主要包括虚拟仿真模型、故障算法模型和健康评估模型。虚拟仿真模型用于构建数字孪生体的几何、物理、行为等仿真内容，支持常见建模软件导出的格式；故障算法模型用于设备故障诊断与预测，支持Python等格式，涵盖分类、回归、聚类等多种算法类型；健康评估模型用于设备健康状态评估与剩余寿命预测，支持阈值模型、退化模型、机器学习模型等多种形式。在模型录入过程中，需填写模型名称、模型类型、适用设备型号、模型版本、模型说明、标签信息等元数据，同时界面支持模型文件的上传与校验功能，可确保上传的模型格式正确、内容完整。
|
||||
|
||||
图 17 模型管理流程图
|
||||
（一）版本控制流程
|
||||
实现模型的版本全生命周期管理，核心功能包括：
|
||||
(1)版本记录：每次模型更新或重新上传均自动生成新的版本号，记录版本的创建时间、上传人、模型文件大小、变更说明等信息，形成完整的版本演进历史。
|
||||
(2)版本回滚：支持任意历史版本的快速回滚操作，回滚后系统自动切换当前生效模型版本，同时保留回滚记录以备审计。
|
||||
(3)版本对比：提供不同版本之间的差异对比功能，支持对比模型文件大小、模型参数等维度，帮助用户快速了解版本演进内容。
|
||||
(4)历史版本保留：所有历史版本均持久化存储，支持按模型名称、版本号、创建时间等条件检索与查看，确保模型变更过程可追溯、可恢复。
|
||||
|
||||
3.9任务管理
|
||||
任务配置模块提供结构化、参数化的任务编排与配置能力，支持系统用户对任务数据进行标准化管理，支持定时任务的灵活配置与自动调度执行，支持任务执行过程中对第三方接口的调用集成，满足复杂业务场景下的自动化任务配置需求。
|
||||
任务配置采用统一数据接口规范、定时调度引擎、第三方接口适配器，具备配置灵活、接入简单、执行可控、易于扩展的特点，为系统用户提供一站式的任务配置与管理支撑。
|
||||
|
||||
图 18 任务管理业务流程图
|
||||
3.9.1用户数据管理接口
|
||||
提供系统用户对任务配置数据的标准化增删改查功能，支持任务模板、任务实例、执行参数等数据的创建、更新、删除及分页查询操作。接口参数统一采用标准时间格式，返回内容包含操作状态、提示信息及数据负载。同时支持批量查询、条件过滤（按任务名称、状态、时间范围等）及软删除机制，确保数据操作的完整性、安全性与可追溯性。
|
||||
3.9.2任务编排
|
||||
用户可将定时任务、第三方接口调用任务、数据处理任务进行组合编排，灵活设置任务节点间的依赖关系、数据传递映射及异常处理策略，实现复杂业务流程的直观构建与动态调整。
|
||||
3.9.3定时任务配置
|
||||
支持基于时间表达式的定时任务创建，可精确配置任务执行的时间点、执行周期、有效期范围（起止时间）及时区。系统根据用户添加的定时任务配置，自动按照设定的时间规则触发任务执行数据获取、处理或推送动作，满足周期性数据同步、报表生成、批量计算等业务需求。同时支持定时任务的立即执行、暂停、恢复及执行日志查看。
|
||||
3.9.4第三方接口调用配置
|
||||
支持在任务节点中配置对第三方系统的接口调用能力，涵盖常用的请求方法。用户可配置请求地址、请求头、请求参数、超时时间、重试次数及异常处理策略。任务执行时自动调用第三方接口获取或推送数据，并对响应结果进行解析、校验与异常处理，支持将接口返回数据作为后续任务节点的输入参数，实现跨系统的数据联动与业务集成。
|
||||
3.10数据[ 1、“驾驶舱”？“数据处理平台”][修改为数据可视化]可视化
|
||||
数据可视化模块提供平台运行核心指标的多维度统计与基础图表展示能力，涵盖设备、采集、故障、资源、任务等常用指标，通过直观的图形化方式辅助用户快速掌握平台整体运行态势，为日常运维巡检与简单决策提供数据参考。
|
||||
采用常规数据查询与基础开源图表组件，以简单、实用、易维护为设计原则，通过定时统计与手动刷新相结合的方式获取数据，避免引入复杂实时计算引擎或流处理框架，降低实现难度与运维成本。
|
||||
|
||||
图 19 示意图
|
||||
（一）设备统计
|
||||
提供设备层面的基础统计功能，包括当前在线设备数与离线设备数的实时统计、按设备类型（如采集设备、边缘网关、智能终端等）统计数量分布，以及设备累计运行时长的统计。统计结果以数字卡片或简单饼图形式呈现，帮助用户快速了解设备资产整体状态。
|
||||
（二）采集统计
|
||||
提供数据采集层面的基础统计能力，包括系统中已配置的采集通道总数统计，以及按今日、本周、本月等预设时间范围统计的数据接入总量。统计结果以数字加趋势箭头的方式展示，便于快速判断采集业务活跃度与数据规模。
|
||||
（三）故障统计
|
||||
提供故障维度的基础统计分析，包括统计周期内发生的故障总次数、按故障类型（如通信故障、设备离线、数据异常等）分类计数并展示占比分布，以及按设备或通道维度统计故障发生频次。统计结果以简单饼图或横向柱状图展示，辅助用户定位问题高发点。
|
||||
（四）资源统计
|
||||
提供平台基础设施资源的轻量级监控统计，包括存储空间使用率百分比、计算资源（CPU、内存）当前负载百分比，以及核心服务的可用性状态（正常或异常）。资源统计数据通过仪表盘或进度条形式展示，当使用率超过设定阈值时可进行简单高亮提示。
|
||||
（五）任务统计
|
||||
提供任务编排与执行层面的基础统计，包括系统中已创建的任务总数统计，以及按任务类型（如定时任务、一次性任务、周期任务等）统计数量构成。统计结果以数字卡片和饼图形式展示，简单反映平台任务编排规模。
|
||||
3.11数据服务
|
||||
数据管理[ 1、统一梳理“数据”相关内容提法，不要一会冒出一个说法；][统称数据管理，对于数据管理又分为数据资源管理、数据治理管理、数据服务管理等细化管理内容]以数据资源管理为基础，首先完成数据表、文件、主题库、标签、目录等资源的统一登记和编目；在此基础上，通过数据治理管理对数据标准、元数据、数据质量和清洗规则进行统一管控，提升数据的一致性、规范性和可信度；随后，数据开发管理基于治理后的数据资源开展 SQL 开发、数据加工、任务编排和结果发布，形成面向业务应用的数据成果；最终，数据服务管理将数据成果通过服务目录、API服务、接口发布、服务监控和服务日志等方式对外提供，实现数据资源的标准化输出、受控化共享和服务化应用。
|
||||
|
||||
|
||||
图 20 数据服务功能图
|
||||
|
||||
3.11.1数据资源管理
|
||||
数据资源管理模块用于对系统内各类数据资源进行统一登记、分类编目、属性维护、标签配置、关系管理、权限控制和使用管理，形成规范化的数据资产管理体系，为数据治理、数据分析、数据共享和业务应用提供基础支撑。
|
||||
1. 数据目录管理
|
||||
数据目录管理功能用于建立统一的数据资源分类体系，支持按照业务域、来源、应用场景等维度对数据资源进行分类管理。
|
||||
系统支持目录的新建、编辑、删除、排序、启用、停用和权限配置，支持将数据表、文件、接口、指标、主题库等资源挂接至对应目录下，实现数据资源的规范化编目管理。
|
||||
|
||||
图 21 数据目录页面示意图
|
||||
|
||||
2. 数据表管理
|
||||
数据表管理功能用于对系统内结构化数据表及字段信息进行统一维护。系统支持维护数据表中文名称、英文名称、所属数据库、表类型、所属目录、表说明、更新方式、更新频率、数据量、存储周期等信息。
|
||||
|
||||
图 22 数据目录页面示意图
|
||||
3. 文件资源管理
|
||||
文件资源管理功能用于对系统内文件型数据资源进行统一存储、分类、检索、预览和权限控制。系统支持 Excel、CSV、JSON、XML、PDF、Word、图片、二进制文件等多种格式文件的管理。
|
||||
系统支持文件上传、文件分类、在线预览、文件下载、版本管理、标签配置、权限控制、归档管理等功能，并支持将文件资源与产品、设备、故障、维修任务、模型算法等业务对象建立关联关系。
|
||||
|
||||
图 23 文件资源页面示意图
|
||||
4. 主题库管理
|
||||
主题库管理功能用于面向业务应用场景对数据资源进行主题化组织和管理。系统支持围绕产品基础、设备状态、故障诊断、维修保障、寿命健康、模型分析、系统审计等业务方向建立主题库。
|
||||
系统支持主题库的新建、编辑、删除、启用、停用，支持维护主题库名称等信息。
|
||||
|
||||
图 24 主题库管理页面示意图
|
||||
5. 数据标签管理
|
||||
数据标签管理功能用于对数据资源进行标签化标识和分类管理。系统支持建立业务标签、来源标签等标签体系。
|
||||
系统支持标签分类管理、标签新增、标签编辑、标签删除、标签绑定、标签检索、标签统计等功能，支持对数据表、字段、文件、接口、指标、主题库等资源进行手动打标或规则自动打标。
|
||||
|
||||
图 25 数据标签管理页面示意图
|
||||
3.11.2数据治理管理
|
||||
数据治理管理模块用于对系统内各类数据资源进行标准化、规范化、质量化、安全化和可追溯化管理。模块围绕数据标准、元数据、数据清洗等内容，建立统一的数据治理规则和管理机制，实现数据从接入、处理、存储、使用的全过程的规范管控，为数据分析、数据服务、业务应用和合规审计提供可靠的数据基础。
|
||||
1. 数据标准管理
|
||||
数据标准管理功能用于建立系统统一的数据标准体系，对数据名称、字段定义、计量单位、字典取值等内容进行统一管理，保证不同来源、不同业务、不同系统之间的数据具备一致的表达方式和使用口径。
|
||||
|
||||
图 26 数据标准管理页面示意图
|
||||
系统支持标准分类管理、标准字段管理、标准单位管理。支持对标准的新增、编辑、启用、停用、发布和版本追溯。
|
||||
2. 元数据管理
|
||||
元数据管理功能用于对系统内数据资源的结构信息、业务属性、技术属性和管理属性进行统一维护，形成完整的数据资源说明信息。通过元数据管理，可对数据表、字段、文件、接口、指标、主题库等资源的来源、结构、含义、更新频率、存储位置、使用范围等信息进行集中管理。
|
||||
|
||||
图 27 元数据管理页面示意图
|
||||
3. 数据质量管理
|
||||
数据质量管理功能用于对系统内数据的完整性、准确性、一致性、唯一性、及时性、有效性等进行校验和评估，及时发现数据缺失、重复、异常、格式错误、范围越界、口径不一致等问题，提高数据资源的可用性和可信度。
|
||||
|
||||
图 28 数据质量管理页面示意图
|
||||
4. 数据清洗管理
|
||||
数据清洗管理功能用于对接入系统的数据进行去重、补全、格式转换、字段规范化、异常值处理、单位转换、编码转换等处理，使原始数据满足系统统一的数据标准和业务使用要求。
|
||||
|
||||
图 29 数据清洗管理页面示意图
|
||||
|
||||
3.11.3数据开发管理
|
||||
1. 数据开发工作台
|
||||
数据开发工作台用于为数据开发人员提供统一的数据开发入口，支持数据脚本编写、SQL 查询、任务编排、调试运行、结果预览和任务发布等操作。
|
||||
系统应支持在工作台中创建数据开发项目，按照业务主题、数据域、任务类型等方式组织开发内容。
|
||||
|
||||
图 30 数据开发工作台页面示意图
|
||||
2. SQL 开发管理
|
||||
SQL 开发管理用于支持结构化数据查询、加工、转换、统计分析和结果写入。系统应提供在线 SQL 编辑、执行、调试、保存、发布和版本管理能力。
|
||||
系统应支持开发人员选择数据源、数据库、数据表后编写 SQL 语句，完成数据查询、数据清洗、数据转换、数据关联、指标计算、结果汇总等操作。对于常用 SQL，可支持保存为脚本模板或开发任务。
|
||||
|
||||
图 31 SQL 开发管理页面示意图
|
||||
3.11.4数据服务管理
|
||||
数据服务管理模块用于将系统内经过治理、加工、汇聚后的数据资源，以接口、订阅、共享、查询、下载等方式对外提供服务。模块围绕服务目录、API服务管理、数据接口发布、服务授权、服务调用、订阅管理、服务监控、服务日志和服务审计等内容，建立统一的数据服务发布与管控机制，实现数据资源的标准化输出、受控化共享和服务化应用。
|
||||
1.服务目录管理
|
||||
服务目录管理功能用于对系统内已发布的数据服务进行统一分类、编目和展示。系统应支持按照业务域、服务类型、数据来源、服务状态、接口类型等维度对数据服务进行分类管理。
|
||||
服务目录应展示服务名称、服务编码、服务类型、所属分类、服务描述、数据来源、发布状态、负责人、访问方式、调用地址、更新频率、共享范围等信息，便于用户统一检索和申请使用。
|
||||
|
||||
图 32 服务目录管理页面示意图
|
||||
2. API 服务管理
|
||||
API服务管理功能用于将数据表、主题库、指标结果、文件资源或业务数据封装为标准化接口服务，对外提供统一的数据访问能力。
|
||||
系统支持 RESTful API服务发布，支持配置接口名称、接口路径、请求方式、请求参数、返回字段、数据来源、查询条件、分页规则、排序规则、超时时间、调用频率限制等内容。
|
||||
图 33 API 服务管理页面示意图
|
||||
3. 数据接口发布
|
||||
数据接口发布功能用于对已配置完成并通过测试的数据接口进行发布管理。系统应支持接口发布申请、发布审批、发布确认、服务上线和发布记录管理。
|
||||
图 34数据接口发布页面示意图
|
||||
接口发布前完成参数校验、权限校验、数据权限校验、返回字段校验和调用测试，确保接口服务符合使用要求后方可正式发布。
|
||||
4. 服务监控管理
|
||||
服务监控管理功能用于对数据服务运行状态、接口调用情况、服务性能、异常情况和资源占用情况进行实时监控，保障数据服务稳定运行。
|
||||
系统应支持对接口调用次数、成功率、失败率、平均响应时间、最大响应时间、并发量、限流次数、异常次数等指标进行统计展示，并支持异常告警。
|
||||
图 35 服务监控管理页面示意图
|
||||
5. 服务日志管理
|
||||
服务日志管理功能用于记录数据服务创建、发布、调用、授权、变更、异常和下线等全过程日志，为服务运维、问题定位和审计追溯提供依据。
|
||||
图 36 服务日志管理页面示意图
|
||||
3.11.5数据溯源管理
|
||||
数据溯源管理模块用于对系统内数据资源从产生、接入、处理、转换、存储、共享、服务调用到最终使用全过程进行来源追踪、流向分析、处理链路记录和影响关系分析，建立完整的数据血缘与数据流转追溯体系，实现数据“来源可查、去向可追、责任可定位、过程可还原”，为数据治理、问题定位、安全审计、质量分析和合规管理提供支撑。
|
||||
1.数据血缘关系管理
|
||||
数据血缘关系管理功能用于建立数据资源之间的上下游关联关系，形成完整的数据流转链路。系统支持对数据表、字段、接口、文件、主题库、指标结果、数据任务等对象之间的数据来源关系和加工关系进行自动解析与关联管理。
|
||||
系统支持展示数据来源、加工过程、输出结果和依赖关系，支持按数据对象查看其上游来源和下游影响范围，形成可视化数据血缘关系图。
|
||||
|
||||
图 39 数据血缘关系页面示意图
|
||||
系统支持对 SQL 加工链路、数据同步链路、接口调用链路、文件导入链路和任务调度链路进行解析，自动生成血缘关系，并支持手动补充和修正血缘关系。
|
||||
2.数据流向追踪管理
|
||||
数据流向追踪管理功能用于对数据在系统中的流转路径进行全过程记录和跟踪。系统支持记录数据从采集接入、数据清洗、加工转换、数据开发、数据服务发布到外部调用使用的完整流转过程。
|
||||
系统支持按照时间、数据资源、任务名称、接口名称、数据来源、使用系统等条件对数据流转记录进行查询与分析，支持查看数据在不同系统、不同服务和不同任务之间的流转路径。
|
||||
|
||||
4.程序版本与硬件要求[ 1、过于简化，补充到位；][已修改]
|
||||
4.1端设备参数系统要求
|
||||
项目 最低要求 推荐要求 说明
|
||||
CPU X86架构处理器 4核及以上X86处理器 满足数据采集、缓存、协议转换等基础计算需求
|
||||
内存 32GB 32GB及以上 支持多任务并发运行及数据缓存
|
||||
存储 500GB 1TB及以上 用于程序部署、日志存储及临时数据缓存
|
||||
操作系统 Linux Ubuntu Ubuntu 20.04/22.04 LTS 支持Docker、ZeroMQ、C++运行环境
|
||||
网络 千兆以太网 千兆及以上 满足端边数据传输要求
|
||||
|
||||
4.2边设备参数系统要求
|
||||
项目 最低要求 推荐要求 说明
|
||||
CPU ARM架构处理器 8核及以上ARM处理器 支持边缘侧数据处理和服务部署
|
||||
内存 32GB 32GB及以上 满足边缘服务、数据库缓存和消息服务运行需求
|
||||
存储 1TB 2TB及以上 用于本地数据缓存、日志、数据库文件存储
|
||||
操作系统 麒麟v10 麒麟v10服务器版 满足国产化平台部署要求
|
||||
网络 千兆以太网 双网口/千兆及以上 支持现场侧与云端侧网络隔离和数据转发
|
||||
|
||||
4.3云设备参数系统要求
|
||||
项目 最低要求 推荐要求 说明
|
||||
CPU X86架构处理器 4核及以上X86处理器 支持云服务部署
|
||||
内存 32GB 32GB及以上 满足云服务、数据库、缓存和消息服务运行需求
|
||||
存储 1TB 2TB及以上 用于本地数据缓存、日志、数据库文件存储
|
||||
操作系统 Linux Ubuntu Ubuntu 20.04/22.04 LTS 支持Docke容器化部署
|
||||
网络 千兆以太网 千兆及以上 满足云服务的数据传输要求
|
||||
|
||||
4.4软件版本详细情况
|
||||
软件名称 版本要求 说明
|
||||
docker 24.0.7 容器化部署服务
|
||||
jdk 11.0.13 JAVA开发工具包
|
||||
nginx 1.25.0 高性能反向代理网页服务器
|
||||
redis 7.2.3 基于内存的键值对非关系型数据库
|
||||
C++ 11 系统编程语言
|
||||
zeroMQ 4.3.2 高性能消息队列
|
||||
KaiwuDB 3.2.0 高可用多模分布式数据库
|
||||
达梦 8.1.3.140+ 国产自主可控的关系型数据库
|
||||
emqx 5.1.6 开源高并发MQTT物联网消息服务器
|
||||
|
||||
Reference in New Issue
Block a user