C#实战：基于WebAPI与Modbus构建EMS核心采集服务
1. 为什么需要EMS核心采集服务？
在工业现场，我们经常会遇到几十台甚至上百台智能电表、传感器等设备需要监控。这些设备可能来自不同厂家，使用不同的通信协议，数据格式也各不相同。想象一下，如果每个设备都需要单独开发对接程序，那工作量会有多大？
我去年接手过一个工厂能源改造项目，现场有87台电表分布在6个车间，使用3种不同协议。最初客户使用Excel手动记录数据，不仅效率低下，还经常出错。这就是为什么我们需要一个统一的EMS核心采集服务——它就像一位精通多种语言的翻译官，能够与各种设备顺畅交流，把杂乱无章的原始数据转化为标准格式。
2. 技术选型：为什么是C#+WebAPI+Modbus？
2.1 C#的优势
很多新手会问：为什么不用Python或者Java？我在实际项目中测试过，C#在Windows平台下的表现确实更胜一筹。特别是它的异步编程模型，处理高并发采集任务时非常给力。比如下面这个简单的异步采集代码：
public async Task<List<DeviceData>> ReadMultipleDevicesAsync(List<ModbusDevice> devices) { var tasks = devices.Select(device => _modbusClient.ReadHoldingRegistersAsync(device.Address, device.Register, device.Count)); return (await Task.WhenAll(tasks)).ToList(); }2.2 WebAPI的灵活性
相比传统的WinForm应用，WebAPI提供了更好的跨平台兼容性。我遇到过这样的情况：客户突然要求增加手机端查看功能。如果是WebAPI架构，只需要开发前端页面就行，后端完全不用改动。而使用ASP.NET Core创建的WebAPI项目，部署起来也非常简单：
dotnet publish -c Release -o ./publish2.3 Modbus协议的必要性
在工业领域，Modbus就像普通话一样普及。根据我的经验，约75%的工业设备都支持Modbus RTU或TCP协议。使用开源的NModbus库，我们可以轻松实现协议解析：
using Modbus.Device; // 创建Modbus TCP客户端 var master = ModbusIpMaster.CreateIp(new TcpClient("192.168.1.100", 502)); ushort[] registers = master.ReadHoldingRegisters(0, 10); // 读取10个保持寄存器3. 实战：搭建采集服务框架
3.1 项目结构设计
经过多个项目实践，我总结出一个稳定的项目结构：
EMS.DataCollection/ ├── Controllers/ # WebAPI接口 ├── Services/ │ ├── ModbusService.cs # Modbus通信核心 │ └── DeviceManager.cs # 设备管理 ├── Models/ │ ├── Device.cs # 设备模型 │ └── DataPoint.cs # 数据点定义 └── Utilities/ └── ModbusHelper.cs # Modbus工具类3.2 设备连接管理
现场设备经常会出现断线情况，一个好的重连机制必不可少。这是我的实现方案：
public class ModbusService { private IModbusMaster _master; private int _retryCount = 3; public async Task<ushort[]> ReadWithRetry(byte slaveId, ushort address, ushort count) { for(int i=0; i<_retryCount; i++) { try { return await _master.ReadHoldingRegistersAsync(slaveId, address, count); } catch { if(i == _retryCount-1) throw; await ReconnectAsync(); } } return null; } }3.3 数据采集策略优化
不同设备的数据更新频率要求不同。我通常采用分级采集策略：
- 重要参数（如总用电量）：5秒采集一次
- 次要参数（如温度）：1分钟采集一次
- 状态参数（如设备开关状态）：变化时采集
使用C#的Timer可以实现这种多频率采集：
var highFreqTimer = new Timer(5000); highFreqTimer.Elapsed += (s,e) => ReadHighFrequencyData();4. 常见问题与解决方案
4.1 设备响应超时
这是最让人头疼的问题之一。我的经验是：
- 合理设置超时时间（Modbus默认是1秒，工业现场建议设为3秒）
- 实现分级降频机制：连续3次超时后自动降低采集频率
- 记录超时日志，方便后期分析网络问题
4.2 数据解析异常
不同厂家的Modbus设备可能有不同的数据格式。比如：
- 有的电表将电压值放大10倍存储
- 有的温控器使用16位有符号整数
- 还有的设备使用自定义的浮点格式
建议在代码中加入数据转换器模式：
public interface IDataConverter { object Convert(ushort[] rawData); } public class FloatConverter : IDataConverter { public object Convert(ushort[] rawData) { // 实现具体的浮点转换逻辑 } }4.3 高并发性能瓶颈
当设备数量超过50台时，同步采集方式会导致性能急剧下降。我的优化方案是：
- 使用连接池管理Modbus TCP连接
- 采用并行采集策略，但要注意控制并发数（建议不超过10个并行任务）
- 对频繁访问的数据实施本地缓存
5. 进阶技巧：让采集服务更健壮
5.1 心跳检测机制
我在每个设备服务中都实现了心跳检测：
// 每5分钟检测一次设备在线状态 _heartbeatTimer = new Timer(300000); _heartbeatTimer.Elapsed += async (s,e) => { var isOnline = await CheckDeviceOnline(deviceId); if(!isOnline) AlertSystem.SendAlert(deviceId); };5.2 数据质量监控
不是所有采集到的数据都是可信的。我会检查以下指标：
- 数值是否在合理范围内（如电压不能为0）
- 数据变化是否连续（温度不会瞬间跳变10度）
- 数据更新时间是否正常（不能长时间不更新）
5.3 配置热更新
现场调试时经常需要修改采集参数。通过实现IConfiguration接口，可以做到不重启服务就更新配置：
services.AddSingleton<IDeviceConfig>(new DeviceConfig(configuration)); services.AddHostedService<ConfigWatchService>(); // 监控配置文件变化6. 部署与运维建议
6.1 日志记录策略
我习惯使用Serilog记录不同级别的日志：
- 信息级：正常采集记录
- 警告级：设备响应慢
- 错误级：通信中断
配置示例：
Log.Logger = new LoggerConfiguration() .WriteTo.File("logs/collection-.log", rollingInterval: RollingInterval.Day) .CreateLogger();6.2 性能监控
使用Prometheus+Grafana监控关键指标：
- 采集成功率
- 平均响应时间
- 线程池状态
6.3 容器化部署
对于大型项目，我推荐使用Docker部署：
FROM mcr.microsoft.com/dotnet/aspnet:6.0 WORKDIR /app COPY ./publish . ENTRYPOINT ["dotnet", "EMS.DataCollection.dll"]在实际项目中，我发现这套架构可以稳定支持200+设备的并发采集。记得第一次完整跑通所有设备采集时，那种成就感至今难忘。现在每次看到客户通过我们系统实时掌握能耗情况，都更加确信这个方向的价值。