苏州做C#工业上位机，通信架构决定项目能活多久。成熟的拆法是四层：设备驱动层屏蔽品牌差异，协议层管报文组解，会话层管连接与断线恢复，应用层只认业务标签。WinForm和WPF只是两个"壳"，通信底座做成独立组件，两个壳随时能换。

苏州的工业现场，对通信架构提了什么特殊要求？

苏州的制造业密度在全国排得上号：工业园区和昆山的电子装配、吴江的精密元件、常熟的汽车零部件，一个车间里西门子、三菱、欧姆龙、基恩士混着来太常见了。节拍快，数据还要喂MES，这意味着架构必须扛住三件事：多协议并存、换设备不动业务代码、断网后自己爬起来。哪一条不满足，项目交付完就是维护噩梦的开始。

C#上位机通信分层，每层到底管什么？

第一层设备驱动：每个品牌一个驱动类，统一实现同一个接口——连接、读、写、订阅四个方法。S7netPlus对接西门子，MC协议封装对接三菱，FINS对接欧姆龙，业务代码永远只面对接口。第二层协议报文：帧头、地址编码、校验都锁在这层，换PLC型号只改驱动不动上层。第三层会话管理：连接池、心跳探测、指数退避重连收在这一层，网络抖动业务无感。第四层应用标签：把D100、DB37.DBX0.0这些软元件地址翻译成"产量计数""主轴转速"这样的业务标签，界面和逻辑只读写标签。

分层的价值在换设备那天才真正显现。你可能会问，小项目有必要拆四层吗？其实吧，拆层的成本就多一两天，而不分层的项目，第二年加设备时改代码的时间是当初的三倍不止，这笔账很好算。

WinForm和WPF，通信架构要写两套吗？

完全不用。通信层跟界面框架零耦合，做成独立的通信类库DLL，WinForm和WPF都直接引用。差异只在展示端：WinForm用Timer加Invoke，简单监控够用；WPF走MVVM数据绑定，采集线程把标签值一更新，界面自动刷新，适合点位多、画面复杂的场景。我们的做法是通信库和UI工程分开建仓，界面再怎么改版，通信底座一行不动。

落地时哪些设计点最值钱？

①读写合并：把几十个点位凑成一次批量请求，网络负载降一个数量级。②采集与UI解耦：后台线程采集，数据进队列，UI按自己的节奏取，绝不让网络等待卡住界面。③断线状态机：正常、可疑、断开、重连四态流转，配本地缓存，网络恢复后数据补传不丢。④超时分级：读点位500毫秒、写指令2秒、连接3秒，一刀切的超时设置会误杀正常请求。

我之前处理过一个苏州吴江3C电子厂的改造项目，原系统通信代码和界面逻辑搅在同一个Form里，三千多行，加一台新机台要翻半天代码。按四层重构花了差不多两周，之后半年陆续加了六台不同品牌的设备，每台就是新增一个驱动类加几张标签配置表，业务层没动过一行。

想动手整理现有项目，第一步做什么？

行动建议：把现有代码里所有"连PLC"的语句挑出来，先抽出一个驱动接口，让西门子和三菱各自实现一遍——这一步做完，你就自然理解分层的意义了。架构不是画出来的，是从第一台多品牌并存的车间里长出来的。