AI前线去年做一条自动化包装线的上位机改造，甲方点名要“C# WPF + 西门子PLC + 实时报警大屏”，当时我第一反应是用WinForms糊一版就能跑，结果发现报警列表的刷新逻辑、PLC断线重连、界面线程调度这些事远没有想象中简单。后来趁着一个新项目机会，直接用MVVMLight把整套东西重写了一遍，这里把完整的落地思路和踩坑记录整理出来，覆盖从S7通讯选型到报警状态机设计，再到DataGrid性能处理的全部过程。
这套内容不是单纯介绍某个控件或某条API。它能解决的问题很明确：在WPF上位机项目里，如何稳定地从西门子PLC采集报警点，如何把报警的产生、恢复、确认做成“事件流”而不是“死表格”，以及如何用MVVMLight把通讯层、业务层和界面层拆干净。如果你正在做上位机开发、维护一套老旧的设备监控程序，或者面试前想系统捋一遍这条技术路线，本文应该能帮你省不少时间。
1. 先聊选型：WPF加MVVMLight，这套组合在图什么
1.1 组态软件和自研上位机的分界线
很多做设备的朋友上来就会问：设备监控不是有WinCC、组态王、InTouch这些组态软件吗，为什么还要专门写一套上位机？
我的看法是，组态软件的优势和劣势都写在它的定位上：画面搭建快、驱动多、适合标准工艺画面，但一旦业务逻辑超出“显示变量+弹窗报警”的范畴，定制成本会迅速失控。比如设备要和MES交换工单，要和SQL Server记录质量追溯数据，要对接视觉相机、读码器或者机械臂，还要在界面里做复杂的参数配方管理——这些场景里，组态软件的脚本环境和控件生态反而成了瓶颈。
而C#在这条赛道上有一个很现实的优势：招人容易。国内工控圈子熟悉C#的人远比熟悉组态脚本的人多，出了问题给一段调用栈，工程师能顺着逻辑Debug下去。WinForms和WPF性能足够，和数据库、WebService、Modbus、S7等通信库都有大量现成方案，代码的版本管理和多人协作也比组态工程文件来得成熟。
如果是单机设备、点位少、画面固定的项目，我很建议直接用组态软件，快速交付才是关键。但只要项目里出现“业务逻辑比重超过画面展示”“协议种类超过两种”“后续要持续迭代算法或界面”的苗头，自研上位机基本就是正确答案。
1.2 WPF相比WinForms的优势在哪里
WinForms能写上位机吗？当然能，而且我早期大部分项目都是WinForms写的。但当我要做一个“实时报警列表”时，WinForms的短板会非常明显。
报警列表不是简单的TextBox输出，它的需求通常长这样：不同等级的报警要显示不同颜色；产生和恢复要有不同的图标；已确认和未确认的要能区分；还要在列表里嵌入“确认”按钮。WinForms做这些UI状态切换时，大多依赖在后台代码里逐控件操作，一个页面塞几百行事件代码是常事。WPF则提供了数据绑定、数据模板、样式和触发器，界面的“状态”可以直接绑定到ViewModel的属性上，后台逻辑不需要关心某个单元格究竟画成什么颜色。
举个例子，报警等级这一列想按“严重/一般/提示”显示不同底色，在WPF里只需给属性加一个枚举，再用一个Converter把枚举转换成Brush，完全不用在代码里写if分支去设置控件颜色。类似这种绑定的表达力，是WinForms很难给你的；WinForms并非不能实现，但后期改需求时，拖动控件的开发体验会让人非常痛苦。
WPF还有一个对工控项目相当重要的隐性优势：它是保留渲染线程和逻辑线程分离的架构。界面卡顿不会直接拖垮后台的数据采集循环，只要你不主动用Dispatcher把重活全塞给UI线程，界面上短暂的刷新压力通常不会让整个程序假死。这点在高频报警刷新场景里特别关键。
1.3 MVVMLight在今天的角色和适用圈
MVVMLight是一个很轻量的MVVM框架，NuGet包只有几十KB，核心能力就是ViewModelBase、RelayCommand、SimpleIoc和Messenger。比起Prism的模块化、导航、区域管理那一整套，MVVMLight更像一把顺手的小刀，适合中小型WPF项目。
先说清楚它的现状：作者Laurent Bugnion对项目的功能迭代基本已经停下来了，新项目如果从零开始，我一般会建议评估CommunityToolkit.Mvvm或者Prism。但如果你接手的是一套已经用MVVMLight跑了两三年的设备程序，或者团队里没人愿意为了IOC容器和导航框架折腾半天，那MVVMLight在工控上位机这个场景里依旧完全够用，不用为了炫技而重构。
用MVVMLight做上位机最大的收益在于它逼着你把代码分成View、ViewModel、Model三层。以前用WinForms写通讯，PLC数据直接写在窗口类里；用MVVMLight之后，PLC的读写在Service层，界面上的“开始采集”“停止采集”“确认报警”都变成Command，界面状态全部通过绑定驱动。这时候程序像不像一个大型单页应用已经不重要，重要的是代码可测了、可维护了，出问题能顺着数据流排查。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 与西门子PLC通讯：协议库选型和连接层封装
2.1 前置条件：PLC侧的软硬件准备
和西门子PLC通讯通常走以太网的S7协议。物理上很简单，一台电脑、一根网线、PLC的以太网口接同一网段就行，但软件层面有一个极其容易忽略的坑：S7-1200/1500若要通过外部上位机直接访问数据块，必须在TIA博途里把CPU属性的“防护与安全”设置为允许通讯，同时确认“允许从远程伙伴进行PUT/GET通讯访问”是勾上的。
这个勾选被很多人漏掉。你代码写得再对，连接也可能超时，报错还往往是“连接被拒绝”或者无明确原因。第一次调S7-1500时我就是在这个设置上卡了一个下午，后来发现CPU默认禁止外部PUT/GET，代码倒是无辜的。
另外，S7-1500的DB块默认开启了“优化的块访问”。如果保持这个默认设置，传统S7协议通过绝对地址比如DB1.DBD24去读数据，往往是读不出来的，甚至返回一堆全零或者报“对象不存在”。解决方法是把要用到的那个DB块的“优化的块访问”属性取消勾选，或者改用基于符号访问的通讯方式。对很多从S7-300时代转过来的人来说，这个点非常容易踩。
做连接层之前，我建议先用一个简单的测试工具直接连接PLC，确认IP、机架号和槽号。S7-1200和S7-1500通常填Rack 0、Slot 1，S7-300的CPU有些在Slot 2或3。不同系列参数不一样，不要想当然套用。
2.2 常见通讯库的横向对比
C#里和西门子PLC通讯，最常见的有三个选择：S7netplus、Sharp7、HslCommunication。三个库我都写过实际项目，各有脾气。
S7netplus是开源社区比较活跃的项目，API做得很“高层”，直接用“DB1.DBD24”这样的字符串读写，代码读起来很舒服，适合点位少、逻辑偏业务的上位机。缺点也恰恰在这里——它把底层S7协议的很多细节包装掉了，一旦遇到S7-1500优化访问、TSAP参数不对这类问题，黑盒属性会让你排查起来比较吃力。
Sharp7走的是另一个风格，API贴近S7协议原生结构。它让你自己管理byte[]缓冲区，自己从缓冲区里解析Float、Bit、Word，性能好、可控性强，适合一次读几十上百个字节、或者大量报警点位集中轮询的项目，但写代码的细节量明显大一些，要清楚S7数据区里字节偏移和位偏移的关系。
HslCommunication是国人大佬开发的一套工业通信库，除了西门子还支持三菱、Modbus、ABB等一堆驱动，接口统一，中文文档丰富，集成多品牌设备时非常省事。不过它的包分免费版和商业授权，有些高级功能或者部分驱动有版权要求，公司项目用之前需要确认清楚许可边界，避免交付后产生纠纷。
如果是新项目又不需要对接多品牌设备，我建议从S7netplus入手，效率高，团队上手快。如果项目里有几百个报警点、需要做大块数据轮询，或者你对S7协议的底层行为有强迫症级的要求，Sharp7更合适。我在报警项目中最终用了Sharp7来做底层读块，因为报警扫描一次往往要连续读多个DB的连续区域，字节数组比逐字符串地址调用更高效。
2.3 连接服务封装：从单次读写到可重连的轮询服务
通讯层切忌在窗口代码里到处new连接对象。最合理的做法是抽象出一个IPlcService接口，内部维护连接状态、断线重连和读写方法，界面层和ViewModel只依赖这个接口。
先看连接部分，用Sharp7示例：
csharp复制using Sharp7;
public class S7PlcService
{
private S7Client _client;
private readonly string _ip;
private readonly int _rack;
private readonly int _slot;
public S7PlcService(string ip, int rack = 0, int slot = 1)
{
_ip = ip;
_rack = rack;
_slot = slot;
_client = new S7Client();
}
public bool Connect()
{
int result = _client.ConnectTo(_ip, _rack, _slot);
if (result == 0) return true;
// 非0即错误码
_client.Disconnect();
return false;
}
public void Disconnect()
{
_client.Disconnect();
}
}
连接建立后，读写一个具体地址或读一整块区域，核心差异在于“你要关注什么粒度的数据”。点位少时无所谓，按地址读更方便；报警点一多，就必须按块读。
假设PLC侧报警信息放在DB10，从DBW0开始的32个字节，每一位代表一个报警点。那么上位机可以一次性把这32个字节读回来：
csharp复制public byte[] ReadDbBlock(int dbNumber, int startOffset, int length)
{
if (!_client.IsConnected) return null;
byte[] buffer = new byte[length];
int result = _client.ReadArea(S7Area.S7AreaDB, dbNumber, startOffset, length, buffer);
if (result != 0) return null;
return buffer;
}
这里必须强调一点：S7的协议数据是高位字节在前的，也就是大端序。Sharp7提供了S7.GetFloatAt、S7.GetIntAt、S7.GetBitAt等解析方法，它们内部已经做了大小端转换，所以千万不要自己拿BitConverter去解析，否则数值会完全对不上。
把Service封装完后，还要处理断线重连。工业现场网络并不稳定，偶尔交换机抖动、PLC重启就会出现连接断开。上位机不能因此就要求操作员重启软件。我的做法是让PLC轮询线程定时检查连接状态，如果发现断开，每隔2到5秒重连一次，并且在界面状态栏里给出明显的“PLC通讯中断”提示，状态恢复时自动继续采集。
2.4 PLC地址映射的规划方法
设计通讯层之前，必须先规划PLC侧的数据区布局。实践中最省事的方式是：和电气工程师约定好一个“数据字典”，把报警位、模拟量、写控制字放在固定DB区。
比如：
- DB1.DBD0 ~ DB1.DBD99：存放模拟量，Real类型，温度、压力、速度等。
- DB10.DBW0 ~ DB10.DBW21：存放报警状态字，每一位代表一个报警点。
- DB20.DBW0：上位机下发的“报警确认字”，某一位为1时通知PLC对应报警已被确认。
这样约定了，上位机只需要面向地址表开发。要新增一个报警点时，只要PLC程序在预留的Word里多占用一个位，上位机配置文件里加一行，不用重新改通讯逻辑。
3. 报警实时显示的核心：从“每帧刷新”到“状态机”
3.1 最典型的错误做法：隔几秒清空表格重新读
网上很多上位机示例，做报警显示时会在Timer里每隔几百毫秒读一遍报警点，然后把DataGrid的ItemsSource重新赋一次值。程序跑起来确实能看到报警在跳动，交付到现场后问题就来了。
第一，DataGrid整体刷新时，用户如果正在用鼠标滑滚动条或者正在查看某一条报警，界面很可能被强行拉回顶部或者跳出选中状态，操作体验非常差。第二，报警有“产生”和“恢复”两个过程，只刷新当前值的话，用户看不到“刚才哪条报警是新的、哪条已经恢复”，失去了追溯价值。第三，如果PLC里有几十个报警点，某个瞬间同时产生七八条报警，每轮刷新都重建集合，UI线程会明显卡顿。
报警显示本质上不是一个“表格刷新”问题，而是一个“事件流问题”。上位机需要感知的是：这个点在上一个周期是0，这个周期变成1了，这是报警产生事件；反过来从1变0，是报警恢复事件。只有用事件驱动的方式，报警界面才是稳定的。
3.2 报警状态机：产生、恢复、确认
要完成事件驱动，先给报警点建模型。
一个报警点的基本属性是：报警ID，报警描述，报警等级，状态字所在DB，字偏移，位偏移。另一个重要属性是确认状态——很多设备要求操作员看到报警后按“确认”按钮，表示我知道了。那么一条报警实际上有多个状态维度：
- Active：当前是否仍然处于报警状态，由PLC状态字决定。
- Acked：操作员是否已确认，可以由PLC上的确认字控制，也可以由上位机本地维护。
- Time：产生时间和恢复时间，用于历史记录。
活动报警集合中，一条报警的生命周期可以这样描述：
- 未报警、未确认：初始态，什么也不显示。
- 产生报警后，变成Active且未Ack，界面上看到红色高亮，触发声音提示。
- 操作员点击确认按钮后，变成Active且已Ack，颜色变淡，声音停止。
- PLC状态字恢复为0后，变成Inactive且已Ack，这条报警从活动列表移除，转入历史记录表。
差异检测的核心代码如下：
csharp复制public void DetectChanges(byte[] currentBuffer)
{
for (int bitIndex = 0; bitIndex < _alarmPointCount; bitIndex++)
{
bool current = S7.GetBitAt(currentBuffer, _byteOffsetOfPoint, bitIndex);
bool previous = _previousStates[bitIndex];
if (current && !previous)
{
OnAlarmRaised(bitIndex); // 报警产生
}
else if (!current && previous)
{
OnAlarmGone(bitIndex); // 报警恢复
}
_previousStates[bitIndex] = current;
}
}
注意上面的_bitOffsetOfPoint通常是0，因为一个报警点位的字节偏移和位偏移，在规划数据字典时已经明确了。GetBitAt传入的是字节偏移和位索引。扫描时不是用ReadBool逐点查询，而是把整个报警字块读出来，然后统一做位运算比较，性能会好很多。
3.3 防抖、去重和扫描周期的选择
轮询周期的设置要兼顾实时性和总线负载。PLC程序一般本身有几十毫秒的扫描周期，上位机没必要做到每10毫秒刷一次报警状态。报警扫描周期200毫秒是一个很合理的起点，对操作员来说，报警出现到屏幕显示的延迟几乎感觉不出来，网络的报文压力又很小。如果这个上位机还同时采集大量模拟量做趋势曲线，报警周期放到300到500毫秒也是可以接受的。
防抖逻辑也很重要。现场电磁干扰会造成偶尔的信号毛刺，某些传感器也会在临界点反复跳变。如果一个报警点在200毫秒内发生了“产生-恢复-产生-恢复”，界面上的声音提示会反复触发，值班员会烦躁到想砸电脑。
常见的处理办法是给事件加时间戳过滤：同一个报警点再次触发产生事件时，距离上一次恢复事件至少要间隔500毫秒，否则丢弃或者合并。这个时间窗通常放在状态检测的外层做，不改变当前检测逻辑，只控制事件是否向UI发布。
去重则是另外一回事：如果某条报警在好几个周期内一直保持Active，就不能重复触发“报警产生”事件。状态机天然解决了这个问题，因为只有在状态发生跳变时才产生事件，持续报警不会重复推送。
3.4 活动报警和历史报警分开存储
界面通常需要两个视图：当前活动报警列表和历史报警记录。它们的数据来源不同。
活动报警列表服务于现场值班，只显示未恢复的报警，数据应一直常驻内存。比较好的做法是用一个Dictionary维护，键是报警ID，值是当前报警状态对象。当PLC数据变化时，只修改对应对象，并让集合发出通知，不需要清空再重建。
历史报警记录是流水账，每产生一个“产生/恢复”事件就追加一条。建议直接落库，可以是SQLite，也可以是纯文本日志。点位不多、一天几百条记录的小设备，用日志文件就能跑；如果报警量很大或者需要多人查询，SQLite是更好的选择，还能顺便做报表查询。
在报警项目里我采用了“内存活动表 + SQLite历史表”的结构。活动表负责UI实时刷新，历史表负责事后追溯，两组数据互不干扰。这样就算PLC一连串上报了上百条报警，UI也只需要处理那些状态发生变化的事件。
4. MVVMLight在项目里的实际落法：注册、调度和消息解耦
4.1 ViewModel的分层组织
MVVMLight不强制要求View命名规则，社区里最常用的做法是MainWindow对应MainViewModel，UserControl对应各自的子ViewModel。在一个上位机项目里，我习惯把它拆成：
- MainViewModel：负责连接按钮、启动/停止采集、状态栏文字。
- AlarmViewModel：负责活动报警集合、历史查询命令、确认报警命令。
- TrendViewModel：负责模拟量趋势曲线数据，如果用到曲线的话。
这些ViewModel由ViewModelLocator集中管理，MVVMLight里可以用SimpleIoc注册。例如在ViewModelLocator构造函数中：
csharp复制SimpleIoc.Default.Register<IPlcService>(() => new S7PlcService("192.168.0.10"));
SimpleIoc.Default.Register<AlarmViewModel>();
SimpleIoc.Default.Register<MainViewModel>();
MainViewModel从SimpleIoc取AlarmViewModel：属性AlarmVM给界面绑定。这样View层只需要在DataContext里指向ViewModelLocator.Main，整体依赖关系很清晰。
4.2 PLC轮询线程和UI线程的调度艺术
MVVM模式下最敏感的环节是跨线程更新UI。PLC采集线程、报警检测线程都不应该直接操作ObservableCollection，否则会抛“调用线程无法访问此对象”的异常。
解决方案是MVVMLight自带的DispatcherHelper。在App.xaml.cs的启动代码最早处执行：
csharp复制DispatcherHelper.Initialize();
之后工作线程要更新UI时：
csharp复制DispatcherHelper.CheckBeginInvokeOnUI(() =>
{
ActivityAlarms.Add(alarmItem);
});
这个办法写起来简单，但千万不要在报警检测的for循环里，每条报警都调用一次CheckBeginInvokeOnUI。因为每次调度UI线程都是一次消息投递，报警成批产生时，你会把UI线程的消息队列塞满，最终界面反而卡死。
正确的做法是：工作线程先把本次检测到的事件放进一个List/Queue，同一个周期结束后再一次性投递到UI线程，UI线程统一处理集合的添加、移除和排序。每次只调度一次，UI线程的压力会小一个数量级。报警项目里这个调优的效果非常明显。
4.3 用Messenger解耦报警弹窗和声音
报警发生时，活动列表也许只要往集合里加一条，但用户还希望看到弹窗提示、听到报警声。这些UI层面的响应不应该由AlarmViewModel内部直接写死。MVVMLight的Messenger适合做这类一对多的广播。
定义一条报警产生消息：
csharp复制public class AlarmRaisedMessage
{
public AlarmItem Alarm { get; set; }
}
在AlarmViewModel收到业务层的报警产生事件后，发送消息：
csharp复制Messenger.Default.Send(new AlarmRaisedMessage(alarmItem));
主窗口的View或者某个专门负责提示的控制器可以订阅这条消息，收到消息后播放声音、弹出悬浮提示。AlarmViewModel完全不依赖声音文件路径和弹窗控件类型，测试的时候只要验证消息有没有发出去就行，非常干净。
需要提醒的是，订阅了Messenger的窗口在关闭时记得Unregister，否则窗口已经销毁但消息还是会被投递，容易造成内存泄漏。MVVMLight的Messenger本身是弱引用还是强引用，不同版本行为有差异，所以建议自己在View的Closed事件里显式注销。
4.4 报警“确认”按钮的命令绑定
点击活动报警列表的“确认”按钮，最终动作是通知PLC把这个报警的确认位置1，或者在上位机本地把Acked置位。这里不要用事件处理器，而应该用RelayCommand绑定。
csharp复制public RelayCommand<AlarmItem> AckCommand { get; private set; }
// 构造函数里
AckCommand = new RelayCommand<AlarmItem>((alarm) =>
{
_plcService.WriteConfirmAlarm(alarm.Id); // 写PLC确认字
alarm.Acked = true; // 更新本地状态
AlarmUpdated?.Invoke(alarm);
});
MVVMLight的RelayCommand支持泛型参数，适合这种列表行按钮的CommandBinding。注意命令里尽量只做业务操作，更新完AlarmItem后通过属性通知让UI自动变色。
5. 交付级别的界面细节：报警列表、声音提示和数据可视化
5.1 DataGrid虚拟化：别让报警列表拖垮整台电脑
实时报警列表最常用的控件是DataGrid。默认情况下DataGrid启用行虚拟化，但当ItemsSource被频繁替换或集合项增长到几千行时，虚拟化效率会大幅下降。如果界面同时开了历史查询列表，使用体验会尤其明显：滚动时掉帧、点击卡顿。
要保证大数据量下的流畅度，有几个明确的设置项值得检查：
- 给DataGrid设置EnableRowVirtualization="True"，并设置VirtualizingStackPanel.VirtualizationMode="Recycling"。虚拟化模式从Standard改成Recycling，会复用容器而不是每次重新创建，滚动体验会好很多。
- 活动报警列表只保留一屏可见的数据。比如只显示最近100条，超过100条就移除最早一条。这样既满足现场监控需求，又保证集合规模可控。
- 不要让DataGrid每个周期都重新赋ItemsSource。更合理的是维护同一个ObservableCollection，更新其中的项或进行小范围的Add/Remove。即使某一次有大批量报警进入，也只在同一轮做多次Add，UI只响应一次集合变更广播，而不是被整个替换刷新打崩。
5.2 被选中默认高亮盖住的坑
现场值班员要盯报警列表，但列表里的行颜色又代表报警等级，这两件事经常冲突。WPF的DataGrid默认在选中某一行时，会给选中行套上系统的高亮背景，于是你可能发现红色“严重报警”行在被选中后会盖成系统蓝色，看起来完全不可分辨。
很多WPF新手在这里会尝试修改DataGrid.RowStyle里的Background，但发现点击时还是变色，这是因为DataGridCell默认模板会在选中时覆盖Cell的Background。解决思路是自定义DataGridCell模板或者使用CellStyle的触发器，把选中视觉改成浅边框或行头指示，而不要占用Cell本身的业务背景。
在我的项目里，做法是把Cell的Background交给业务Converter控制，选中态通过一个带边框的装饰层来实现。命令按钮列、状态灯列放在模板列中，模板根元素不要直接依赖默认选中态，这样再怎么点击，报警等级的颜色都不会被系统蓝盖掉。
这个问题表面看只是样式细节，但真到了交付现场，操作员会把它当成“软件Bug”报出来，所以建议在开发阶段就处理干净。
5.3 声音提示的实用设计
报警声音不能简单到“有报警就放一遍”就完事。实际现场会遇到设备一直报警、人员暂时不在的情况，声音提示需要具备重复提醒能力。
我通常会设计一个简单的报警声音服务：ActivityAlarms集合中有未确认的严重报警时，启动一个循环播放提示音的线程，播放间隔比如10秒一次；当所有严重报警都已确认或者没有严重报警时，停止循环并保留一声“嘀”表示告警消除。
第一次报警产生时优先播报一声急促音，后续由循环定时器负责提醒。主界面要放一个“消音”按钮，点击后临时关闭声音，但不影响报警状态显示。这个设计完全由AlarmViewModel的状态驱动，不涉及具体波表文件，因此测试阶段可以直接注入假的报警数据验证声音服务逻辑。
5.4 趋势曲线与历史查询：上位机不只是状态灯
实时报警页之外，客户一般还希望能看看温度、压力、速度这些模拟量的变化过程。WPF里做实时趋势曲线比较常用的库是OxyPlot和LiveCharts2。它们都支持绑定数据集合，定时追加数据点，刷新曲线。
OxyPlot和MVVM的契合度不错，因为PlotModel本身就是个可序列化的模型对象，可以在ViewModel里维护LineSeries，并把数据点追加进去。界面上只放一个PlotView控件，然后绑定到PlotModel属性即可。
这里要格外注意一点：实时趋势曲线的数据点不能无限往集合里加，否则内存迟早被吃光。正确做法是限制每个序列最多保留最近N个点，比如500个点，并在数据落后时调整X轴的范围。否则上位机跑一个星期，曲线内存就会膨胀到让软件假死。
历史报警查询页面则建议分页加载。DataGrid不要一次性加载整年的报警记录，查询时按月或者按数量分批加载，同时支持按报警等级、报警时间、是否已恢复等条件过滤。客户的真实操作往往是“查今天上午有没有发生过1号电机过载”，你给他一个快速筛选条件，比让他在一整页数据里找人要友好得多。
5.5 软件交付时容易被忽视的几个细节
最后分享几个容易被忽略的工程化细节。这些不会影响Demo演示，但会直接决定软件在现场是否好用。
第一，高DPI。现在的工控电脑很多配的是1080P甚至2K大屏，Windows的显示缩放往往不是100%。如果WPF程序没有做好DPI适配，界面会出现文字模糊甚至布局错乱。WPF对矢量布局的DPI支持总体不错，但要注意自定义控件和固定尺寸元素的问题，尽量使用自适应布局，避免大量写死高度和宽度。
第二，日志。上位机跑在现场，最难排错的就是“昨天报了警但没人看见”。程序和PLC通讯的读写日志、报警事件日志一定要留文件。不需要很复杂，把时间戳、操作来源、通讯错误码简明记录在文本里即可。出了问题，让现场把日志文件发过来，程序员能省下很多远程扯皮的时间。
第三，参数配置。PLC的IP地址、报警点位映射等信息不要写死在代码里。提供一套XML或JSON配置启动时加载，甚至可以做得简单一点——界面上的“通信设置”窗口允许用户修改IP和机架槽号，保存后下次启动生效。这样换一套PLC或者换一条产线时，不用让工程师背着电脑跑现场改代码重新编译。
5.6 如果报警量真的很大，考虑队列和批量落库
目前谈到的方案面向的是中小型设备：几十台电机、几百个报警点、单台上位机。这种规模下用“轮询读块+内存活跃表+SQLite历史”已经绰绰有余。
如果将来设备数量爆炸式增长，比如一台监控终端接了上千个报警点，同时要做秒级历史存储，那我会建议把事件传递从普通的.NET事件改为Channel或消息队列模式。轮询线程只负责从PLC采集数据并投递到队列，写入SQLite的消费者线程负责批量落库，UI线程订阅的又是另外的出队事件。这样采集、存储、显示三段完全解耦，每一段都可以独立伸缩。虽然代码结构会复杂一些，但对报警风暴的承受能力会成倍提升。
不过多数项目到不了那种规模。对绝大多数C# WPF + 西门子PLC的上位机来说，把基础的状态机和MVVM分层做好，稳定性和可维护性已经远超行业平均水平了。我用这个思路做下来的几个项目，最后交付时都只花很少时间在“报警显示”这个模块上扯皮，剩下的精力可以安心去处理控制工艺和客户需求变更。