1. 为什么需要EMS核心采集服务在工业现场我们经常会遇到几十台甚至上百台智能电表、传感器等设备需要监控。这些设备可能来自不同厂家使用不同的通信协议数据格式也各不相同。想象一下如果每个设备都需要单独开发对接程序那工作量会有多大我去年接手过一个工厂能源改造项目现场有87台电表分布在6个车间使用3种不同协议。最初客户使用Excel手动记录数据不仅效率低下还经常出错。这就是为什么我们需要一个统一的EMS核心采集服务——它就像一位精通多种语言的翻译官能够与各种设备顺畅交流把杂乱无章的原始数据转化为标准格式。2. 技术选型为什么是C#WebAPIModbus2.1 C#的优势很多新手会问为什么不用Python或者Java我在实际项目中测试过C#在Windows平台下的表现确实更胜一筹。特别是它的异步编程模型处理高并发采集任务时非常给力。比如下面这个简单的异步采集代码public async TaskListDeviceData ReadMultipleDevicesAsync(ListModbusDevice 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 Taskushort[] ReadWithRetry(byte slaveId, ushort address, ushort count) { for(int i0; 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.AddSingletonIDeviceConfig(new DeviceConfig(configuration)); services.AddHostedServiceConfigWatchService(); // 监控配置文件变化6. 部署与运维建议6.1 日志记录策略我习惯使用Serilog记录不同级别的日志信息级正常采集记录警告级设备响应慢错误级通信中断配置示例Log.Logger new LoggerConfiguration() .WriteTo.File(logs/collection-.log, rollingInterval: RollingInterval.Day) .CreateLogger();6.2 性能监控使用PrometheusGrafana监控关键指标采集成功率平均响应时间线程池状态6.3 容器化部署对于大型项目我推荐使用Docker部署FROM mcr.microsoft.com/dotnet/aspnet:6.0 WORKDIR /app COPY ./publish . ENTRYPOINT [dotnet, EMS.DataCollection.dll]在实际项目中我发现这套架构可以稳定支持200设备的并发采集。记得第一次完整跑通所有设备采集时那种成就感至今难忘。现在每次看到客户通过我们系统实时掌握能耗情况都更加确信这个方向的价值。