目录前言项目介绍项目功能项目特点项目技术项目代码项目效果项目源码总结前言工业现场的数据采集与监控说起来简单做起来坑不少。串口超时、寄存器地址错位、设备突然离线、数据刷新太快页面卡死、历史数据堆积成山——每个问题都能让人折腾好几天。这两年在折腾工业监控系统时一直想搞一套既能快速落地、又不用被商业组态软件绑架的方案。.NET 8 的 Blazor Server 给了我一个新思路用 C# 从头撸到尾从设备驱动到前端展示不用换语言不用搞前后端分离那一套复杂工程。把思路和实现整理出来希望能给同样在搞工业监控的同行一些参考。项目介绍一套基于 .NET 8 Blazor Server 开发的轻量级工业 Web SCADA 系统专门针对多泵站集中监控场景设计。整套系统涵盖了设备数据采集、实时监控、报警管理、历史存储和数据分析等核心环节。系统默认配置了一套四泵站标准点表模板71 个标签/站涵盖液位、频率、运行状态、控制模式等关键参数。开箱即用只要配好 Modbus TCP 设备地址就能在浏览器里看到泵站的实时运转情况。项目功能实时监控泵站总览 Dashboard在线/离线统计、报警数量、各站液位概览泵站详情页液位实时曲线、泵组启停控制、运行状态指示灯标签数据 100ms 级刷新操作响应基本感觉不到延迟报警管理高低限报警、设备离线报警自动触发报警列表支持按时间、级别、确认状态筛选报警确认操作带操作人记录历史数据标签值定时归档默认 10 秒一次支持按时间范围查询任意标签的历史曲线数据导出为 CSV 格式设备诊断每个设备的通讯状态实时可见提供 /api/status、/api/device-status 等诊断接口采集日志结构化输出排查问题不靠猜多客户端推送SignalR 实时广播外部客户端可订阅数据防抖机制避免高频推送压垮网络项目特点**全栈 C#**从 Modbus 驱动到 Web 界面一套技术栈从头写到尾维护成本低团队上手快配置驱动设备和点表全部走 JSON 配置新增泵站只需复制一份模板文件改改 IP 地址轻量存储SQLite 作为历史库部署省心数据量不大时完全够用采集与展示分离后台服务负责轮询和计算Blazor 组件只做渲染各司其职防抖推送不管是页面更新还是 SignalR 广播都做了 100ms 批量合并避免高频刷新把浏览器搞崩并行轮询多设备并行采集一个设备卡住不影响其他站的数据更新项目技术层级技术选型说明前端框架Blazor Server (InteractiveServer)服务端渲染实时数据通过 SignalR 推送通讯协议Modbus TCP (NModbus)主流 PLC 和 RTU 都支持兼容性好实时推送SignalRWebSocket 长连接延迟低数据存储EF Core SQLite轻量、免安装适合工控机部署日志Serilog结构化日志方便接入 ELK 或 Seq图表ECharts (CDN)液位趋势、历史曲线展示DI 容器.NET 8 原生 DI不用第三方容器够用项目分层结构IndustrialWebScada/ ├── config/ # 配置目录 │ ├── devices.json # 设备列表 │ └── device-templates/ # 点表模板 │ └── pump-station.json # 71 标签标准模板 ├── src/ │ ├── IndustrialWebScada.Core/ # 领域模型、接口、事件定义 │ ├── IndustrialWebScada.Application/ # 业务逻辑TagValueStore、AlarmEngine │ ├── IndustrialWebScada.Drivers/ # ModbusTcp、MQTT 驱动实现 │ ├── IndustrialWebScada.Infrastructure/ # EF Core SQLite 持久化 │ ├── IndustrialWebScada.BackgroundServices/ # 采集、推送、报警、归档服务 │ └── IndustrialWebScada.Web/ # Blazor Server 主程序 │ ├── Components/Pages/ # Dashboard、PumpStationList 等页面 │ ├── Components/Shared/ # PumpStationCard、WaterLevelTank 等组件 │ └── Program.cs # 入口与 DI 配置 └── tests/ └── IndustrialWebScada.Drivers.Tests/ # 驱动层单元测试项目代码数据采集服务核心循环public classDataCollectionService : BackgroundService { privatereadonly ITagValueStore _store; privatereadonly IEnumerableIDeviceDriver _drivers; privatereadonly ILoggerDataCollectionService _logger; protected override async Task ExecuteAsync(CancellationToken stoppingToken) { while (!stoppingToken.IsCancellationRequested) { var tasks _drivers.Select(d CollectDeviceAsync(d, stoppingToken)); await Task.WhenAll(tasks); // 并行采集互不干扰 await Task.Delay(GetInterval(), stoppingToken); } } private async Task CollectDeviceAsync(IDeviceDriver driver, CancellationToken ct) { try { var tags await driver.ReadAllTagsAsync(ct); _store.Update(tags, DateTime.UtcNow); } catch (Exception ex) { _logger.Warning(ex, 采集失败 [{DeviceId}], driver.DeviceId); _store.MarkOffline(driver.DeviceId); } } }采集服务以 BackgroundService 形式跑在后台每个设备独立并行执行。某个设备超时或断线不会拖累其它设备的数据更新。防抖推送器100ms 批量合并public classTagValueNotifier : IDisposable { privatereadonly System.Timers.Timer _timer; privatereadonly Dictionarystring, TagValue _buffer new(); privatereadonlyobject _lock new(); privatereadonlyint _intervalMs 100; publicevent ActionIReadOnlyListTagValue OnNotified; public void Push(TagValue tagValue) { lock (_lock) { _buffer[tagValue.TagId] tagValue; // 同一标签只保留最新值 } } private void Flush() { ListTagValue snapshot; lock (_lock) { if (_buffer.Count 0) return; snapshot _buffer.Values.ToList(); _buffer.Clear(); } OnNotified?.Invoke(snapshot); } }页面组件订阅这个 Notifier收到批量数据后统一调用 StateHasChanged()。100ms 的窗口既能保证实时性又避免了逐条刷新带来的频繁渲染开销。Modbus 地址合并读取减少报文往返public async TaskDictionarystring, object ReadAllTagsAsync(CancellationToken ct) { var result new Dictionarystring, object(); var mergedRequests MergeAdjacentAddresses(_tagConfigs); foreach (var request in mergedRequests) { var data request.FunctionCode switch { 2 await _modbusMaster.ReadInputsAsync(unitId, request.Start, request.Length), 3 await _modbusMaster.ReadHoldingRegistersAsync(unitId, request.Start, request.Length), 4 await _modbusMaster.ReadInputRegistersAsync(unitId, request.Start, request.Length), _ thrownew NotSupportedException() }; // 按原始点表拆分数据 ParseAndFill(result, data, request); } return result; }点表里 71 个标签如果逐个读取需要发 71 次请求。这个合并逻辑会把地址连续的寄存器批量读取读 16 个保持寄存器只需 1 次请求效率直接拉满。项目效果主控台页面聚合了所有泵站的状态概览右上角显示在线/离线数量和未确认报警数中间区域以卡片形式展示各站的液位和运行泵数。泵站详情页是使用频率最高的界面。左侧是液位动态水位图中间是四台泵的运行状态灯和启停按钮底部是最近 30 分钟的液位趋势。控制指令下发后泵状态的变化在 1-2 秒内就能在界面上反映出来。报警页面按时间倒序排列未确认的报警高亮显示。点击确认按钮会记录操作人和确认时间方便事后追溯。历史查询页面支持选择时间范围和标签名称曲线图用 ECharts 渲染缩放和平移操作都很流畅。右侧提供 CSV 导出按钮方便导出数据做进一步分析。项目源码GitHubhttps://github.com/suwencjp/VibeCodingIndustrialWebScada总结回过头来看这套系统最大的价值在于把工业采集和 Web 监控打通了而且全程没离开 .NET 生态。当然这套方案也有明显的局限。Blazor Server 依赖长连接大规模部署时对服务器的 SignalR 连接数有压力。另外 SQLite 在高并发写入场景下性能一般如果点位超过 5000 个建议换成 PostgreSQL 或 InfluxDB。不过对于中小型泵站几十到几百个标签来说这套架构足够皮实好用了。引入地址