📚 课程目录第2章项目启动与需求工程

2. 项目启动与需求工程

在TIA Portal自动化项目中，真正决定交付成败的往往不是编程技巧，而是项目启动阶段对需求的把握。客户提供的URS（User Requirement Specification，用户需求说明）通常以工艺语言描述“我要什么”，而自动化团队需要把它翻译成可设计、可编程、可测试的自动化需求规格书（Automation Requirement Specification，ARS）。这一转换过程如果缺失或草率，后期就会出现“程序做完了，客户说不是这个意思”的返工。本节围绕需求收集、边界定义、验收标准与需求追溯矩阵四个核心动作展开。

一、URS与ARS的本质差异

URS是客户视角的期望文档，常见表述如“反应釜温度需稳定控制在设定值±1℃”“配方切换时间不超过5分钟”。它描述的是生产目标，不关心PLC型号、IO点数或PID参数。ARS则是工程视角的约束文档，需要把上述期望拆解为：温度检测采用PT100还是热电偶、量程与精度、PID回路数量、采样周期、报警阈值、联锁条件、HMI显示方式、数据归档周期等。URS回答“做什么”，ARS回答“用什么做、做到什么程度、怎么验证”。

需求收集阶段建议采用“三源合一”方式：一是客户URS原文逐条编号；二是现场勘察记录（设备清单、仪表台账、现有控制柜状态）；三是工艺工程师访谈纪要。三者交叉比对后，才能识别出URS中未写明但实际必须实现的隐含需求，例如安全联锁、断电恢复策略、与MES的接口协议等。

二、边界定义：把“不做什么”写清楚

边界定义是需求工程中最容易被忽视却最影响验收的环节。它至少应明确四类边界：控制边界（PLC负责哪些设备，哪些由第三方控制器负责）、接口边界（与MES、SCADA、机器人、称重系统的通信协议与数据点表）、责任边界（电气柜接线由谁完成、仪表校准由谁负责）、范围边界（本期不包含哪些工位或功能）。边界不清会导致接口调试时互相推诿，甚至出现“这个信号到底谁给”的僵局。

例如某包装线项目，URS要求“与现有码垛机联动”。若不在ARS中明确联动信号是硬线还是Profinet、握手时序由谁主导、故障时谁先停，调试阶段就会反复扯皮。因此边界定义应形成书面清单，并由客户与集成商双方签字确认。

三、验收标准的可测量化

验收标准必须可测量、可复现、可判定。URS中的“运行稳定”“操作方便”无法验收，ARS中应转化为：连续运行72小时无意外停机；单次配方切换时间≤300秒；温度控制超调量≤2℃、稳态误差≤±0.5℃；报警响应时间≤1秒；HMI画面切换时间≤2秒。每条标准都要注明测试方法、测试工具和判定依据，例如温度指标用趋势图记录，切换时间用秒表或PLC时间戳统计。

验收标准建议与客户在项目启动会上逐条确认，并写入ARS附录。后期若客户提出新增需求，应走变更流程，避免“顺便加一点”导致范围蔓延。

四、需求追溯矩阵的建立

需求追溯矩阵（Requirements Traceability Matrix，RTM）是连接URS、ARS、程序块、测试用例和验收结果的桥梁。它的核心价值在于：任何一条客户需求都能向下追溯到具体实现和测试，任何一段程序也能向上追溯到需求来源。RTM通常以表格形式维护，字段包括需求编号、URS条目、ARS描述、实现位置（如FB/FC/DB编号）、测试用例编号、测试结果、验收状态。

在TIA Portal项目中，实现位置可以精确到具体块，例如“温度PID控制”对应FB1001“PID_Temp_Control”，测试用例对应TC-005“温度阶跃响应测试”。这样在最终验收时，只需按RTM逐行核对，即可证明每条需求都已覆盖。对于未覆盖或部分覆盖的条目，应明确标注并说明原因，避免验收时出现“这条好像没做”的争议。

五、实操示例：温度控制需求条目

以下给出一条从URS到ARS再到RTM的完整示例，参数为教学假设值，实际项目需按工艺重新确认。

URS-012：反应釜温度需稳定控制在设定值±1℃。
ARS-012：采用PT100三线制，量程0~200℃，精度±0.3℃；
         采样周期100ms，PID控制周期200ms；
         加热功率调节采用4~20mA模拟量输出；
         超温报警阈值设定值+5℃，联锁切断加热；
         HMI显示实时趋势，归档周期1s。
实现位置：FB1001 PID_Temp_Control，DB100 温度数据块
测试用例：TC-005 温度阶跃响应测试
验收判定：超调量≤2℃，稳态误差≤±0.5℃，连续运行72h无异常

这条示例说明：URS只给出一句话，ARS必须展开为可执行的工程参数，RTM则把URS-012、ARS-012、FB1001、TC-005和验收结果串成一条可核查的链路。项目启动阶段完成这张矩阵，后期调试和验收就有了共同依据。

常见误区：把URS直接当ARS使用，或ARS只写“按客户要求实现”。前者导致设计无依据，后者导致验收无标准。需求工程的价值就在于把模糊期望转化为可测量、可追溯的工程约束。

总结来说，项目启动与需求工程的核心动作是：以URS为输入，通过需求收集补齐隐含信息，用边界定义锁定责任与接口，用可测量验收标准建立判定依据，最终以需求追溯矩阵把客户需求、程序实现和测试验收连成闭环。这一步做得越扎实，后续TIA Portal编程、调试和交付就越顺畅。