调用树与块职责表
实际调用关系（不是设计时的设想），每个 OB/FB/FC 的职责、调用者、被调用者、执行条件。
能力 02 · 程序结构分析与文档化
程序只有一个工程师看得懂
程序只有一个工程师看得懂
那就是这家工厂最大的单点风险
设备是好的，图纸丢了，点表是手抄的，程序只有一个人能改。这个人休假、离职或者只是病了，整条线就进入“不敢动”状态。文档化做的事很朴素：把程序里的事实写成任何人都能查的形式。
¥12,000 起单台设备（≤2,000 行）
5–10 个工作日典型周期
可脱离我们文档单独可用，不绑定服务
按事实写以现场程序为准，不以原图纸为准
文档化不是把程序翻译成人话。很多“程序说明”只是把网络逐个念一遍，看完还是不知道改哪里。有用的文档要回答四个问题：这个信号从哪来、经过谁、写到哪去；这个动作由什么条件触发；出这个报警该先查什么；要加一个功能应该动哪个块。
交付的五份东西
变量字典
符号名、绝对地址、数据类型、单位与量程、读写方、所属设备单元；覆盖 DB、M、I/O 与 HMI 关联变量。
I/O 点表重建
以现场实际接线和程序使用为准，重建输入/输出点表，标注备用点、被短接点、程序未使用的点。
功能说明书
按工艺动作分段描述：启动条件、互锁、时序、异常处理；配时序图或流程框图，不堆代码。
维护手册
常见故障的判断路径、可调参数清单与安全范围、备份与恢复步骤、改动前必须确认的事项。
怎么做出可信的文档
- 以现场为准，不以图纸为准。先核对实际模块、固件版本与接 line，再读程序；图纸与现场不一致的地方单独列成《差异表》——这本身就是排查隐患的过程。
- 先测绘，再写字。用交叉引用把每个变量的写入点与读取点全部列出来，逻辑关系图是从数据流里长出来的，不是凭印象画的。
- 交叉验证。文档里的每个关键结论至少用两种方式验证：程序交叉引用 + 现场动作确认，或 + HMI 画面表现。
- 让当事人读一遍。初稿交给现在维护这台设备的人读，他说“这里不对”，我们就回去查——这一步能抓出大部分想当然的错误。
档位（未税）
行数按实际程序块统计；含现场核对时另计差旅。
| 范围 | 包含 | 参考价 |
|---|---|---|
| 单台设备 | ≤2,000 行，含点表与维护手册 | ¥12,000 – 20,000 |
| 单条产线 | 2,000–8,000 行，3–8 个工位，含功能说明书 | ¥20,000 – 48,000 |
| 整厂/多线 | >8,000 行，多线关联，含资产台账 | ¥48,000 起，按线计 |
| 增量维护 | 文档随改动同步更新（年度） | ¥6,000 / 年起 |
和“程序抢救”的区别：抢救解决的是“程序还没有、拿不出来”；文档化解决的是“程序在，但没人说得清”。两件事经常一起做——先读出程序，再做结构与文档。如果你连原始工程都没有，先看程序抢救与托管。
常见疑问
文档做完，我们还需要你们吗？
['不需要，这是设计目标。文档、变量字典、点表都是可独立使用的交付物，格式用 Excel / Word / PDF，不加密、不绑定我们的工具。只有后续改动需要人做时才会再找我们——那是另一件事。']
原厂不给图纸怎么办？
['按现场重建。模块型号、接线、传感器类型都可以现场核对，程序里的地址与符号能反推出大部分信号含义。重建的点表会标注“已现场确认”和“程序推定”两类，推定项建议后续停机时逐点验证。']
会不会把我们的工艺秘密写出去？
['不会。文档只描述信号与控制关系，不涉及配方数值与工艺参数的具体取值（这些写成“由配方 DB 提供”）。交付前签保密协议，文档只交你们指定的人。']