第二章：需求分析与方案设计

说实话，很多自控系统项目从一开头就埋下了隐患。为什么？因为需求没搞清楚，方案就急着动手了。我见过太多项目，硬件选型拍脑袋，软件平台凭感觉，最后调试阶段才发现——嗯，这玩意儿根本跑不通。

这一章，咱们就聊聊需求分析与方案设计。说白了，就是搞清楚「用户到底要什么」，然后「我们怎么给他造出来」。

2.1 用户需求调研：别让用户说「我也不知道」

用户需求调研，听着简单，做起来全是坑。我刚开始做项目时，用户说「我要一个自动控制系统」，我就真信了。结果呢？他想要的是能远程监控，我给他做了个本地触摸屏。白干。

所以我的习惯是，调研时一定要问清楚三件事：

• 控制对象是什么？ 是电机、阀门，还是整个生产线？
• 控制精度多高？ 0.1% 还是 1%？差一个数量级，硬件成本差好几倍。
• 故障时怎么办？ 是停机报警，还是自动切换到备用设备？

这里有个小技巧：让用户画出他理想中的操作界面草图。你想想看，用户可能说不清技术参数，但他能画出「我想在这里看到一个绿色的启动按钮」。这张草图，比十页需求文档都管用。

2.2 技术规格书编写：把「人话」翻译成「技术话」

技术规格书，就是需求调研的「翻译件」。用户说「我要快」，你得写成「系统响应时间 ≤ 100ms」。用户说「我要稳」，你得写成「稳态误差 ≤ 0.5%」。

我个人习惯把技术规格书分成三块：

1. 功能规格：系统能做什么？比如「支持 8 路模拟量输入，4 路数字量输出」。
2. 性能规格：做到什么程度？比如「采样周期 ≤ 10ms，控制周期 ≤ 50ms」。
3. 环境规格：在什么条件下工作？比如「工作温度 -20℃ ~ 60℃，防护等级 IP65」。

写规格书时，最忌讳模糊词。像「大概」「差不多」「尽量」这些词，一律删掉。我见过一份规格书写着「系统应尽量稳定」，你猜后来出了多少问题？

2.3 系统架构设计：画好这张图，后面少走弯路

系统架构设计，说白了就是「谁跟谁怎么连」。我一般分三层来考虑：

• 现场设备层：传感器、执行器、变频器这些「干活的」。
• 控制层：PLC、DCS、RTU 这些「发指令的」。
• 监控层：上位机、服务器、操作员站这些「看数据的」。

这三层之间怎么通信？用总线还是以太网？冗余怎么做？这些都得在架构设计阶段定下来。否则后期改架构，那成本——你懂的。

下面这张图，是我常用的自控系统架构示意。你看一眼就明白了：

你看，架构清晰了，后面选型、编程、调试都有方向。我习惯在架构图上标注好通信协议和冗余策略，这样团队里每个人拿到图，都知道自己那块该怎么干。

2.4 硬件选型原则：别只看参数，要看场景

硬件选型，很多人上来就比参数：CPU 主频多高？内存多大？I/O 点数多少？这些当然重要，但我觉得更重要的是——这硬件在你那个现场环境里，能不能扛得住？

我总结了几条选型原则：

原则	说明	我的经验
环境适应性	温度、湿度、振动、粉尘	化工厂里，普通 PLC 一年就坏，得选宽温型
可靠性	MTBF（平均无故障时间）	关键设备我至少要求 10 万小时
可扩展性	I/O 模块、通讯接口能否扩展	预留 20% 余量，别把路走死
供货周期	备件好不好买	进口品牌有时要等 3 个月，国产替代要提前验证

举个例子。有次做水处理项目，现场湿度常年 90% 以上。客户选了普通 PLC，结果半年内坏了三块 CPU。后来换成防护涂层型，再没出过问题。你看，参数表上不会写「怕不怕潮」，但现场会告诉你。

2.5 软件平台选择：别追新，要追稳

软件平台这事儿，我吃过亏。早些年喜欢追新，哪个版本最新就用哪个。结果呢？新功能没用上，倒是踩了一堆 bug。后来我学乖了——工业软件，稳定压倒一切。

选软件平台，我主要看三点：

• 生态成熟度：用的人多不多？社区活跃不活跃？出了问题能不能搜到解决方案？
• 兼容性：能不能跟现有的硬件、第三方系统对接？别搞成信息孤岛。
• 长期支持：厂商会不会很快停止维护？我见过一个项目用的小众组态软件，两年后厂商倒闭了，系统升级都没人管。

我个人比较推荐的主流平台：

• PLC 编程：西门子 TIA Portal、罗克韦尔 Studio 5000
• 组态软件：WinCC、Intouch、组态王（国产里算不错的）
• SCADA 平台：Wonderware、iFix

当然，具体选哪个，还得看项目预算、团队技术栈、客户偏好。没有「最好」的平台，只有「最合适」的平台。

---

公众号:蓝海资料掘金营，微信deep3321