第二章：需求分析与系统规划
从机械/电气需求中提取软件需求
说实话，很多做自动化设备的团队，软件和机械电气是各干各的。机械那边画完图，电气那边出完电路，才把一沓文档甩给软件工程师。这时候你一看，好家伙，气缸动作时序没写，传感器触发逻辑靠猜，通讯协议就写了几个字“走Modbus”。
我个人的习惯是，在项目启动的第一周，必须拉着机械和电气工程师坐下来，开一个“三方对账会”。会上我们要把机械动作流程、电气IO分配、传感器布局，一条一条过。为什么？因为软件需求就藏在这些细节里。
需求提取的三个核心维度
我一般把需求分成三类，你想想看是不是这个理：
- 功能需求：设备要干什么。比如“上料”、“定位”、“焊接”、“检测”。这些通常来自机械的动作流程图。
- 性能需求：干得多快、多准。比如“节拍小于3秒”、“定位精度±0.1mm”。这些来自电气和机械的规格书。
- 接口需求：跟谁通信、怎么通信。比如“与MES通过TCP/IP交互”、“扫码枪走RS232”。这些来自电气原理图。
我踩过的一个坑：有一次做一台点胶机，机械图纸上画了一个“检测传感器”，但没写是光电还是接近。我默认按光电处理，结果现场调试时发现是接近传感器，触发逻辑完全反了。从那以后，我要求所有传感器必须标注型号和触发方式。
功能模块划分：别让代码长成“一坨”
模块划分这件事，说白了就是“高内聚、低耦合”。但很多新手容易犯一个毛病——按硬件来分模块。比如“气缸模块”、“电机模块”、“传感器模块”。这样分其实不对。
我建议按业务流程来分。举个例子，一台贴标机：
- 上料模块：负责物料到位检测、夹紧、定位
- 贴标模块：负责标签剥离、取标、贴附、滚压
- 检测模块：负责视觉拍照、结果判断、NG排出
- 通讯模块：负责与PLC、MES、扫码枪交互
你看，每个模块内部可能同时用到气缸、电机、传感器。但对外暴露的接口是清晰的——上料模块只管“给我一个物料”，贴标模块只管“把标签贴上去”。
一个小技巧：模块划分时，可以画一张“功能-硬件映射表”。横轴是硬件（气缸1、电机2、传感器3），纵轴是功能模块。哪个模块用了哪些硬件，一目了然。这样后期改硬件时，你马上知道要改哪个模块的代码。
接口定义原则：把话说清楚
接口定义是软件架构里最容易吵架的地方。我见过两个工程师为了一个函数名争半小时。其实核心原则就几条：
- 单一职责：一个接口只做一件事。别搞什么“SetAllParameters”这种大杂烩函数。
- 参数明确：参数类型、范围、单位都要写清楚。比如“speed”是mm/s还是rpm？不写清楚就是坑。
- 返回值规范：成功返回0，失败返回错误码。别搞什么返回true/false，然后错误信息藏在日志里。
- 异步回调：耗时操作（比如视觉拍照）必须用异步接口，别阻塞主流程。
我曾经遇到一个血泪教训：一个同事写的接口叫“MoveToPosition”，参数传了X、Y、Z三个坐标。结果现场调试时发现，这个函数内部还偷偷做了“夹爪闭合”的动作。因为机械设计上，到位后必须夹紧。但软件接口上完全没体现。后来改接口名改成“MoveAndClamp”，才避免后续的混乱。
知识体系框架图
下面这张图，是我做需求分析时脑子里始终绷着的一根弦。你可以把它当成一个检查清单：
接口定义实战：一个例子
假设我们要定义一个“扫码枪接口”。很多人的第一版可能是这样的：
// 不好的接口设计
int ScanBarcode(); // 返回条码字符串？还是错误码？嗯，这里要注意。我建议这样定义：
// 好的接口设计
typedef struct {
char barcode[64]; // 条码内容
int length; // 有效长度
int result; // 0=成功, -1=超时, -2=无条码
} ScanResult;
// 异步接口
int StartScan(int timeout_ms); // 启动扫码，返回0表示启动成功
int GetScanResult(ScanResult *result); // 获取结果，非阻塞为什么这么设计？因为扫码枪在实际产线上经常超时、误读。如果你用同步阻塞的方式，整个设备流程就被卡死了。异步接口配合状态机，才是工业级的做法。
我个人习惯：所有硬件接口都加上超时参数。哪怕机械说“这个传感器响应很快，1ms就够”，我也留个100ms的超时。现场环境跟实验室不一样，灰尘、振动、温度都会影响响应时间。
需求文档的“三件套”
最后，我建议每个项目都产出三份文档：
| 文档名称 | 内容 | 谁负责 |
|---|---|---|
| 软件需求规格书 | 功能列表、性能指标、接口定义 | 软件架构师 |
| 接口定义文档 | 函数原型、数据结构、通讯协议 | 软件工程师 |
| 模块划分图 | 模块关系、数据流、状态机 | 软件架构师 |
这三份文档，在项目启动前必须评审通过。别想着“先写代码，后面再补文档”。我见过太多项目，因为需求没对齐，最后调试阶段改得面目全非。
一个小建议：需求文档里，每条需求都要有“验收标准”。比如“上料模块在3秒内完成”，那验收时就要拿秒表测。没有验收标准的需求，就是耍流氓。
公众号:蓝海资料掘金营，微信deep3321