从设备台账、实时采集到风险预警、维修派工和备件补货，一次围绕制造现场运维链路完成的 Java 项目实践。
在制造业现场，设备维护往往不是"等坏了再修"这么简单。温度、振动、电流等数据持续变化，异常一旦没有及时发现，后续可能涉及停机、人员排班、备件准备和生产节奏调整。
这次我借助飞算JavaAI完成了一套面向制造业的设备预测性维护与工单管理系统。我希望它不是单独展示预测模型，也不是只做一张工单表，而是把"设备运行数据出现异常"到"生成维修动作并回看结果"的过程连起来。文中页面数据为项目演示数据，用于说明业务流程与实现思路。
1. 先确定作品要回答的问题：设备异常之后，下一步由谁处理？
我给项目设定的主线是：设备台账提供对象基础，状态监测持续采集运行参数，预测模块评估风险，告警中心集中待办，工单模块负责派发和闭环，维护计划与备件管理提供执行保障，最后再通过运维分析回看成效。
登录页把这条业务链提前放到了页面说明中。进入系统后，设备总览会先展示设备在线率、高风险设备、待处理工单和平均健康分，并把健康、关注、高风险等状态放在同一个视图里。这是我希望演示时先呈现的结果：运维人员不用在多张表之间来回找信息，而是先知道哪里值得优先处理。
02. 用飞算JavaAI把"做什么"先变成工程边界
我在飞算JavaAI中先明确了项目的服务边界：设备管理、工单管理、告警、数据采集、故障预测、用户权限与运维分析需要分开组织，但又要能通过统一入口协作。后端以 Spring Boot、Spring Cloud 为基础，前端用 Vue 承载设备台账、状态监测和运维看板。
飞算JavaAI的智能引导会通过 5 步 逐步补全需求、技术栈、功能模块、数据与工程配置，让"设备预测性维护"不止是一句描述，而能形成完整 Java 工程的起点。生成工程后，我仍会检查模块依赖、接口命名、配置和业务字段；AI 可以加快起步，但设备规则、告警阈值和数据口径必须由开发者确认。
项目使用多模块结构组织公共能力、网关、设备服务、工单服务、告警服务、数据采集服务和预测服务。下面的创建记录是把项目骨架逐步落到父工程、公共模块和基础异常处理代码中的过程。
03. 设备台账不是"设备名单"，而是后续判断的锚点
预测和工单都要先知道对象是谁、在哪条产线、由谁负责、当前处于什么状态。因此我先建立设备台账，记录设备编码、名称、所属产线、设备型号、健康分、负责人和状态。
例如演示中的 CNC-01、PRESS-03、MOTOR-08、PACK-05 分别对应不同设备类型和产线。设备台账把基础信息固定下来，后续监测数据、告警、工单与维护计划都可以关联到同一个设备编码，避免信息在模块之间失去上下文。
04. 实时状态采集：先看原始信号，再讨论预测
对主轴电机这类设备，我把温度、振动、电流、转速作为运行状态指标。状态监测页同时展示当前值、阈值和状态，并按时间呈现趋势，方便判断一次瞬时波动还是持续偏离。
技术上，设备端数据可以经由 MQTT、Modbus 或 OPC UA 等方式接入；时序数据可存入 InfluxDB 或 TimescaleDB，业务服务再根据规则和模型计算健康状态。截图中的数值只是演示场景，但页面要表达的重点是：风险判断应该尽量有数据依据，而不是只靠人工描述故障。
05. 预测结果的价值，在于能否给出可执行的建议
故障预测页将历史故障和实时传感器数据作为输入，展示异常检测、剩余寿命预估、故障概率和处理建议。项目演示中，MOTOR-08 被标记为轴承磨损高风险，并给出停机检修与更换轴承的建议；PRESS-03 则提示检查油路和冷却系统。
这里我把模型输出定位为辅助决策信号：它帮助运维人员排序和核查，不应该绕过现场诊断或安全流程直接下结论。无论使用 scikit-learn、TensorFlow 还是其他模型，训练数据质量、阈值设置、误报漏报与模型版本管理都需要持续验证。
06. 从预警到工单：让"发现问题"变成有人负责的任务
只显示红色风险卡片还不够。告警中心负责收集设备异常、阈值告警和预测性维护风险，并提供确认、批量处理和转工单入口。不同级别的告警进入不同的处理队列，防止高优先级问题被普通提醒淹没。
工单创建后，需要明确设备、工单标题、优先级、处理人、截止时间和当前状态。以 MOTOR-08 为例，风险信号可转成"主轴电机轴承检修"紧急工单，再由维修一组接单、维修、验收和闭环。这样告警不再停在监控页面，而是可以追踪到实际执行结果。
07. 计划维护与临时抢修，需要在同一张排程里协作
并非所有维护都来自告警。自动包装机的月度保养、数控加工中心的刀具点检、冲压机的液压保养，都可以提前进入维护计划。计划页记录维护类型、维护内容、计划日期、负责人和状态，便于把日常保养与故障处置安排在同一套工作机制中。
对于周期性任务，XXL-JOB 或 Quartz 这类调度工具可以定期生成计划、巡检任务或健康状态评估；对于紧急风险，则可以由预测和告警模块触发工单。两条路径最终都回到可分派、可追踪、可验收的工单闭环。
08. 备件是否到位，决定了维修闭环能不能落地
预测到轴承问题却没有库存，工单再及时也难以快速完成。因此，备件模块把当前库存与安全库存放在一起展示，并可在低库存时触发补货提醒。演示中 6208 高速轴承的当前库存低于安全库存，系统将其标记为低库存。
把备件管理纳入同一平台，是为了让运维人员在处理风险时同时看到资源限制：是否有可用备件、是否需要提前补货、相关工单是否应该调整执行时间。这是从"预测设备会不会坏"走向"企业能不能处理好"的关键一步。
09. 运维分析不是报表收尾，而是下一轮策略的输入
运维分析页集中观察停机、告警、工单、MTBF、MTTR 和健康趋势，并把需要关注的事项以文字结论呈现。例如可以据此确认哪条产线的主轴类故障更集中、哪些备件有安全库存风险、哪些设备应纳入下一轮重点巡检。
这些指标需要基于真实、完整的历史数据才能用于生产决策；在本次作品中，它们的作用是把前面各模块沉淀的信息做一次可读的汇总，验证项目不只是"采集数据"或"生成工单"，而是在尝试形成持续改进的运维闭环。
10. 微服务如何支撑这条闭环
服务层面，我将 Gateway 作为统一入口，Nacos 用于服务注册发现和配置管理；设备、数据采集、预测、工单、告警等服务各自承担清晰领域职责，并通过 OpenFeign 完成需要的同步调用。MQTT 负责接入设备消息，RabbitMQ 或 RocketMQ 可传递告警、工单状态等异步事件；MySQL 存放业务数据，Redis 用于热点状态与缓存，时序数据库承载连续采集数据。
系统治理页把这些服务的实例、端口、中间件和状态集中展示。它并不替代正式的生产监控体系，但在项目演示中能够清楚交代：设备实时数据、预测模型和工单业务并非堆在一个单体应用里，而是按照协作边界组织。
11. 这次使用飞算JavaAI的复盘
对我来说，飞算JavaAI最有帮助的环节是把项目从一个场景描述推进到可检查的 Java 工程：通过智能引导先梳理需求，再围绕多个服务创建基础结构和代码文件，让我能更快把精力放在设备状态、风险规则、工单流转和页面验证上。
它提供的 10 个 Java 专家 Agent 可以在需求、文档、编码与编译修复等不同阶段提供辅助，但工程生成不等于项目完成。尤其是制造业场景，数据接入可靠性、权限控制、设备安全、预测模型有效性、工单流程和备件库存口径都需要由开发团队持续检查。
12. 活动记录与入口
本次「飞算JavaAI炫技赛·盛夏季」活动时间为 2026 年 7 月 10 日至 7 月 27 日，设置「晒一晒」和「讲一讲」两类创作赛道；具体参与方式、奖励与规则请以官方页面的最新说明为准。根据活动资料，飞算JavaAI提供 9.9 元包月方案，价格和权益可能调整，请以官方信息为准。
#飞算JavaAI炫技赛 #AI编程 #Java开发 #SpringCloud #制造业数字化 #预测性维护 #设备运维 #技术分享