前言
大家好，我是wacky。上四篇我们画完了.NET工控的生态地图------通信协议、数据存储、业务逻辑、界面展示，一条完整的技术栈链路。从这一篇开始，我们换个角度：不聊技术栈，聊聊一些工控的基本概念。这些概念看起来"虚"，但它们直接决定你做架构决策时的判断力。
第一个要聊的概念是"实时"。如果你做过Web开发，你对"实时"的理解大概是WebSocket推送、SignalR长连接、消息队列的毫秒级延迟。但在工控领域，"实时"这个词的含义完全不同------它不是"快"，而是"确定"。
Web的"实时"：够快就行
先明确一下Web开发中"实时"是什么意思。你给一个Web系统发请求，服务器处理完返回结果，整个过程从几毫秒到几百毫秒不等。在用户体验层面，"实时"通常意味着"感觉不到延迟"------比如聊天消息秒推、股票行情毫秒刷新、在线协作光标跟随。技术上靠的是WebSocket、长轮询这些方案。
这种"实时"的核心特征是：快，但不保证。网络抖动一下，延迟可能从50ms跳到500ms；服务器GC一下，响应可能卡半秒。用户顶多觉得"刚才卡了一下"，刷新就好了。因为Web系统的业务逻辑不依赖精确的时间------你晚0.5秒收到聊天消息，不影响任何事。
工控的"实时"：必须确定
工控的"实时"不是"快"，是"确定"。这不是文字游戏------"快"是平均值，"确定"是最坏情况。
举个例子。一个化工厂的反应釜，温度超过120℃必须立刻关闭加热器。从温度传感器读到120℃，到PLC输出"关闭加热器"信号，这个过程必须在确定的、可预见的时间内完成。这个时间不是"大概50ms"，而是"严格不超过5ms"。
为什么"大概"不行？因为如果你的系统"大部分时候3ms完成，偶尔50ms"，那偶尔的50ms发生在温度超标的那一刻，反应釜可能已经到150℃了------轻则废料，重则爆炸。
这就是工控"实时"的核心：确定性响应时间（Deterministic Response Time）。不是平均多快，而是最坏多慢。工控系统设计的时候，关注的是"这个操作最长需要多长时间"------因为最坏情况才是安全边界。
硬实时 vs 软实时
理解了"确定"这个概念，再来看工业领域对实时的分类：
硬实时（Hard Real-Time）：错过截止时间意味着系统故障。上面那个反应釜的例子就是硬实时------超过5ms没响应，后果是安全事故或设备损坏。硬实时的典型场景是运动控制（伺服电机位置环在微秒级）、安全联锁（急停回路必须在几毫秒内切断）、高速数据采集。
软实时（Soft Real-Time）：错过截止时间会导致性能下降但不造成事故。比如上位机界面上温度曲线的刷新------本来应该每100ms刷新一次，偶尔200ms刷新一次，操作员觉得"有点卡"，但不影响安全。软实时的典型场景是HMI界面刷新、历史数据记录、报警日志。
这中间还有一个"固实时（Firm Real-Time）"的概念------错过截止时间不会造成安全事故，但数据就无效了。比如高速采集卡丢失了一个采样点，这个点永远回不来了，但不影响系统安全。
为什么PLC能做硬实时，.NET不能
聊到这里，你可能想问：.NET能做硬实时吗？
答案是：不能。不是.NET不够好，是设计目标不同。
PLC能做硬实时，因为它的运行机制是为实时控制设计的。PLC的工作方式是"扫描循环"------输入采样→程序执行→输出刷新→回到输入采样。每次扫描的时间是确定的，因为PLC不跑操作系统，没有多任务调度、没有GC、没有网络中断。它的处理器就干一件事：按固定周期跑你的控制逻辑。扫描周期可以精确到毫秒甚至微秒级，而且每次扫描的时间高度一致。
.NET运行在通用操作系统上（Windows/Linux），操作系统有几百个进程在跑、有内存管理、有磁盘IO、有网络中断。即使你把.NET程序的优先级调最高，操作系统仍然可能在你最关键的时刻做一次内存页交换，让你的代码卡住几十毫秒。这几十毫秒对Web系统无所谓，对硬实时控制就是灾难。
所以工业控制中硬实时场景的架构是：PLC做硬实时控制，上位机（.NET）做软实时------数据采集、界面展示、报警处理、历史记录。上位机不参与毫秒级的控制决策，它通过通信协议（Modbus/OPC UA）读取PLC已经处理好的数据，展示给人看、存储到数据库、做趋势分析。
这个分工意味着：.NET上位机的"实时"目标是"及时"，不是"确定"。你需要在100ms内把温度显示到界面上，但偶尔200ms也可以接受。
上位机开发的"实时"技巧
虽然.NET做不了硬实时，但上位机开发中仍然有一些"实时"相关的坑需要注意。这里说两个最关键的。
第一个是轮询频率。很多工控新手上来就写一个100ms的定时器不停地读PLC数据。但如果PLC的扫描周期是20ms，你100ms读一次没问题。但如果PLC的扫描周期是200ms，你100ms读一次，读到的数据有一半是重复的------PLC还没更新呢。轮询频率要匹配PLC的扫描周期，不是越快越好。通常建议轮询周期≥2倍PLC扫描周期。
第二个是UI线程不能阻塞。工控上位机的界面卡顿，80%的原因不是"电脑太慢"，是有人把耗时操作放在了UI线程上。WPF的数据绑定机制已经帮你解决了大部分问题------数据更新在后台线程完成，ViewModel通过INotifyPropertyChanged通知界面刷新。但如果你在按钮点击事件里写了一个同步的PLC通信操作，界面就会卡住。记住一条铁律：所有通信操作必须异步。
// 错误：按钮事件里同步读PLC，界面卡死
private void ReadButton_Click(object sender, RoutedEventArgs e)
{
var data = plc.ReadHoldingRegisters(0, 10); // 同步阻塞UI线程
// 空值和长度检查
if (data == null || data.Length == 0)
{
TemperatureText.Text = "无数据";
return;
}
TemperatureText.Text = data[0].ToString();
}
// 正确：异步读PLC，界面不卡
private async void ReadButton_Click(object sender, RoutedEventArgs e)
{
// 防止重入：读取过程中禁用按钮
ReadButton.IsEnabled = false;
try
{
// 在后台线程读取 PLC，不阻塞 UI
var data = await Task.Run(() => plc.ReadHoldingRegisters(0, 10));
// 空值和长度检查
if (data == null || data.Length == 0)
{
TemperatureText.Text = "无数据";
return;
}
// await 之后自动回到 UI 线程，可以安全更新控件
TemperatureText.Text = data[0].ToString();
}
catch (Exception ex)
{
// async void 中必须捕获所有异常，否则直接崩溃
TemperatureText.Text = $"读取失败: {ex.Message}";
}
finally
{
ReadButton.IsEnabled = true;
}
}后记
"实时"这个词在IT和OT两个世界里含义完全不同。做Web的人聊实时，说的是体验；做工控的人聊实时，说的是安全。理解了这个区别，你就理解了为什么工控系统的架构是PLC+上位机的组合，而不是一个.NET程序包办一切。
下一篇我们聊PLC的扫描周期------理解了它，才算真正入了工控的门。诸君共勉。
本文首发于我的公众号【wacky的碎碎念】，欢迎关注追更！