这三个系统其实是上位机里最典型的业务三件套配置管参数、报表管统计、报警管异常。它们共享同一套数据层和权限体系建议一起设计而不是各写各的。一、参数配置管理系统1. 核心设计原则所有参数不写死在代码里PLC IP、端口、站号、采集间隔、报警阈值、权限都应外置到 JSON/XML 或配置类中好处是不改代码就能适配不同现场。2. 版本化与迁移最容易出事故的地方JSON 配置文件中必须包含版本号字段如configVersion: 3启动时根据版本号执行逐步迁移逻辑而不是简单判断文件能否打开。禁止因新增字段直接生成新配置覆盖旧文件需通过版本比对做字段映射与数据转换。publicclassConfigManager{privateconstintCurrentVersion3;publicAppConfigLoad(stringpath){varrawFile.ReadAllText(path);vardocJObject.Parse(raw);varverdoc[configVersion]?.Valueint()??1;// 逐级迁移不要跳级if(ver2)MigrateV1ToV2(doc);if(ver3)MigrateV2ToV3(doc);varcfgdoc.ToObjectAppConfig();Validate(cfg);// 关键禁止字段缺失时静默用默认值returncfg;}}几个必须守住的细节配置按用途拆分为独立文件如 system.json 系统参数、device.json 设备标定参数、recipe/ 工艺配方不同配置有独立生命周期避免导出工艺配方时误覆盖设备地址或标定参数加载时对关键字段做显式校验并限制参数范围、明确单位如速度要区分毫米/秒与毫米/分保存时采用原子性替换策略先写临时文件确认成功后再替换原文件关键配置保存前保留上一份备份以支持快速恢复。3. 权限分级工控场景通常采用三级权限操作员查看、确认、启停、管理员参数修改、报表导出、超级管理员配置通信、用户管理。参数修改入口务必挂权限校验并同步写操作日志。二、生产报表统计系统1. 先分清数据类别工控数据分两类存储策略完全不同配置数据和业务数据设备信息、用户权限、工单记录、报警历史结构化、需要事务支持、查询条件复杂属于关系型数据库的活儿时序数据温度曲线、转速波动写入频繁、单条简单、按时间范围查询、很少修改是时序数据库的主场。两类数据用不同方案别图省事用一个库搞定所有事。历史数据建议采用分钟级聚合归档既保证追溯精度又控制数据量膨胀。2. 报表生成流程报表生成基于历史数据结合 NPOI、EPPlus 等 Excel 操作组件无需依赖 Office 环境。核心流程分四步数据查询按时间范围、设备类型从数据库查询需优化语句避免大数据量阻塞主线程模板设计定义表头、列名、数据格式和统计规则如平均值/最大值/最小值数据填充与样式设置导出与归档可设置定时归档避免文件堆积。publicasyncTaskGenerateDailyReportAsync(DateTimeday){// 1. 异步查询避免阻塞 UIvardataawait_repo.GetAggregatedAsync(day,day.AddDays(1));// 2. 模板填充 统计usingvarpkgnewExcelPackage();varwspkg.Workbook.Worksheets.Add(日报);ws.Cells[A1].Value$生产日报{day:yyyy-MM-dd};// ... 表头、数据、边框样式// 3. 归档并记录日志varpathPath.Combine(_archivePath,$Daily_{day:yyyyMMdd}.xlsx);awaitpkg.SaveAsAsync(newFileInfo(path));}如果是 Web 端或需要复杂中国式报表可以考虑后端基于 ASP.NET Core Web API 提供数据接口用 EF Core 或 Dapper 做数据访问SignalR 实现报表数据实时推送Redis 缓存高频查询数据也可以集成 FineReport 这类专业工具通过 API 对接数据源。数据库设计需建立事实表与维度表多厂区场景可采用主库业务库动态路由读写分离优化查询性能。三、设备报警记录系统1. 分级与规则常见报警类型包括上限报警超过设定值、下限报警低于设定值、变化率报警变化太快、偏差报警偏离正常值、超时报警长时间无数据。分级上可参考紧急红色闪烁如温度超上限 15℃、热电偶断线声光报警弹窗置顶短信通知、重要橙色超上下限 5℃弹窗记录企业微信推送、一般黄色偏差预警或通信短暂中断界面提示日志、提示蓝色开关机、参数变更仅记录不打扰。2. 全生命周期 防抖每条报警应完整记录产生 → 确认 → 恢复 → 关闭四个时间节点支持追溯响应时长。防抖是必做的温度在阈值附近来回跳动会导致报警反复出现可用延时确认连续 3 次超限才报警或滞回区间触发值 80、恢复值 75来避免临界抖动。publicclassAlarmEngine{privatereadonlyDictionarystring,int_overCountnew();publicvoidEvaluate(AlarmRulerule,doublevalue){if(valuerule.UpperLimit){if(_overCount[rule.PointId]rule.ConfirmCount)return;// 延时确认__service.RaiseAsync(rule,value);}elseif(valuerule.RecoverLimit)// 滞回而非直接等于上限{_overCount[rule.PointId]0;__service.RecoverAsync(rule);}}}3. 表结构与实现要点核心表可参考MachineInfo机台编号、型号、位置、OPC 地址、AlarmRule点位、上下限、优先级、防抖时间、AlarmRecord产生/确认/恢复时间、确认人、持续时长、OperationLog用户、操作类型、时间、IP、SystemUser账号、角色、密码哈希。EF Core 配置上建议用 DateTime 精准映射 SQL Server 的 datetime2(3) 保证毫秒级精度温度历史表按月份分区报警记录表建立 MachineId RaiseTime 复合索引。实现要点报警判断放在子线程避免卡 UI报警记录存数据库保证可追溯确认操作要记录谁在什么时候确认的历史报警定期清理。另外建议加上报警屏蔽功能维护时可临时屏蔽避免检修期间刷屏。四、三者如何协同建议按模块拆分通信模块、数据采集模块、报警模块、曲线模块、报表模块、权限模块、配置模块、日志模块做到新增设备不改动旧代码、新增协议实现接口即可、新增字段配置加一行而不用改逻辑。日志方面至少要覆盖四类通信日志收发报文、IP、端口、时间、操作日志谁、何时、做了什么、报警日志变量、值、阈值、时间、异常日志堆栈、方法、现场信息。如果你目前的项目是 WinForm 还是 WPF、数据库用的是 SQLite 还是 SQL Server可以告诉我我按你的实际结构给一份更具体的表设计和模块划分方案。