Siemens LBC 系列：基础控制库的定位与作用

假设要控制一个带开、关到位反馈的阀门。起初看起来很简单：自动程序发命令，PLC 驱动输出，HMI 再放两个按钮。但很快就会遇到更具体的问题：自动运行时，手动按钮能不能操作？命令发出后一直不到位，要显示什么？复制到下一台设备时，PLC 程序、操作面板和报警又要改多少处？

把启停逻辑写进一个 FB，解决的是其中一部分。我研究 Siemens 的 Library of Basic Controls（LBC，基础控制库），更关心的是另一件事：能不能围绕同一个设备，把控制、操作和诊断一起组织好，而不是分别拼出几套互相牵扯的变量。

阅读范围：这篇写给已经接触过 PLC 功能块、准备了解 LBC 的读者，只讨论定位和设计思路，不提供可直接下载运行的程序。下文以 Siemens《Automation Framework V2.2》官方资料中的 LBC 集成示例说明具体接口与画面；AF 的版本不等于 LBC 库包版本，也不能据此推定所有 LBC 块的接口。本篇为资料解析，未进行 TIA Portal 工程运行或实机测试。

一、先看一个阀门：命令发出，不等于设备已经到位

继续用开头的假设场景。操作员按下“打开”，只说明有人提出了打开请求；输出接通，也不自动等于阀门已经到达开位。程序还需要根据反馈判断实际状态，并决定异常时如何处理。

为了把问题拆清楚，我会先区分下面几件事。它们是这个阀门例子的需求整理，不是 LBC 的正式引脚表。

需要区分的信息	在这个例子里表示什么
动作请求	希望阀门打开或关闭。
执行条件	当前模式和过程条件是否允许这次操作。
实际反馈	现场开位、关位信号反映了什么。
设备状态	正在动作、已到位，还是位置尚不能确定。
异常与恢复	哪项检查没有通过，条件恢复后又需要怎样确认。

这几类信息即使最后都表现为 Bool，也不能因为数据类型一样就混用。尤其不能用“打开命令”代替“已经打开”的反馈。否则操作画面看起来有反应，实际设备却可能处在另一种状态。

Siemens 的 AF 料斗示例提供了一个直观参照：同一张画面里有 Product_Valve 和 Drain_Valve 的设备面板。看图时先不研究整个料斗顺序，只比较设备名称、位置提示和操作按钮。它们分别回答“是哪一个设备”“现在是什么状态”“能够提出什么操作”。[4]

Siemens AF V2.2 料斗示例中，Product_Valve 与 Drain_Valve 面板分别显示设备名称、位置状态及操作按钮 — 图 1：先观察两个阀门面板中的名称、位置状态与命令按钮，它们不是同一种信息。此图属于 AF 料斗集成示例，不是独立 LBC 库的目录截图（图片来源：Siemens《Automation Framework V2.2》，10.3 HMI Screen）。

把这些内容放回同一个设备对象来设计，才是我希望从 LBC 学到的东西。重点不是按钮统一成什么颜色，而是按钮、状态和程序说的是不是同一件事。

二、LBC 提供的是基础控制模块，不是一整台机器的程序

Siemens 在官方的库说明中，把 LBC 定位为按统一概念编写的基础控制模块，并说明其参考 Siemens 编程风格指南和 PLCopen 指南。[1]

可以把它理解为设备控制的可复用基础，而不是另一门编程语言。同一份官方资料把用于数学、定时、计数等通用功能的 LGF，与提供基础控制模块的 LBC 分别列出；两者关注的工作并不相同。[1]

这也有助于划清研究范围。我想先看明白一个设备怎样接收请求、反映状态、暴露操作接口，再讨论多个设备如何配合。至于一台机器先送料还是先夹紧、某个步骤如何等待另一机构，这些仍要从实际工艺需求出发，不能只因为选用了一个库就省略设计。

一个写得好的自定义 FB 也可以做到这些。LBC 的意义不是证明“自己写的都不可靠”，而是提供一个现成的官方参考，便于比较：哪些接口已经约定好了，哪些重复工作可以少做，哪些地方仍要由项目自己负责。

三、看懂接口，比数清有多少个引脚更重要

面对一个陌生的控制块，我会先问：哪个输入是命令，哪个输入来自现场，哪些数据用于配置，哪些数据提供给画面？把这些关系分开，比一开始逐行研究内部实现更容易建立整体认识。

这里还要区分三个概念：FB 描述控制行为；UDT 定义一组数据的结构；按这个数据类型声明的变量才承载具体数值。UDT 不是额外执行的一层程序，也不会因为被命名为“接口”就自动建立 PLC 与 HMI 的通信。

在 AF 的官方实现中，Siemens 使用了 LBC 的专用 Control Node 版本：把命令和监视信息组织进相关 UDT，便于上层集中处理。这是该集成方式的具体选择，不应扩大成“所有 LBC 模块都必须这样调用”。[2]

手动控制示例则进一步展示了接口的用处。文档中的 enableManualCmds 输入由 PLC 侧的 #tempManualControlAllowed 控制；HMI 操作经由 moduleInterface，PLC 内部控制还涉及 controlNode。[3]

Siemens AF V2.2 的 LBC 功能块调用示例，手动操作许可连接到 enableManualCmds 输入 — 图 2：关注 enableManualCmds 的外部连接：手动命令是否允许执行，由 PLC 侧条件参与决定。图示为 AF 文档中的 LBC 调用，不代表所有版本和所有块的接口都相同（图片来源：Siemens《Automation Framework V2.2》，11.3 Operating modes）。

从这个例子能借鉴的，是操作请求与操作许可要分开。有手动按钮，不代表 PLC 在任何状态下都应该接受它；具体能否执行，还要看相应块和项目的规则。图中的许可条件来自 AF 的上层模式设计，不能直接当成另一台机器的通用条件。

同样，HMI 访问实例 DB 本身并不必然是错误。我要避免的是画面随意依赖内部临时变量，导致程序一调整，画面就失去依据。比较可维护的做法，是明确哪些数据允许外部使用，并在接口发生变化时同步检查调用方。

四、诊断不只是一个 Fault：还要知道它为什么出现

回到阀门例子。“没有打开”只是一个现象：可能没有收到请求，可能请求被当前条件拒绝，也可能已经驱动输出却没有得到预期反馈。这个假设场景中的几种情况，需要不同的排查动作，不适合统统解释成“阀门坏了”。

Siemens 的 AF 诊断章节说明了另一条有用的链路：LBC 块检测异常并输出状态信息，示例再通过报警文本把状态解释给操作人员看。文档以 LBC_AxisControl_TecPlcCn 为例，展示了对应的 PLC 报警文本列表。[5]

Siemens AF V2.2 示例中，LBC_AxisControl_TecPlcCn 的诊断信息通过 PLC 报警文本列表表达 — 图 3：轴控制模块的诊断信息与 PLC 报警文本列表。这里只借它说明“状态值需要对应明确含义”，不能把图中的状态定义套给其他模块（图片来源：Siemens《Automation Framework V2.2》，15.3.3 Error Handling within the LBC Library Blocks）。

这个 AF 示例还使用 ProDiag 监督相关错误位，并结合状态值选择报警说明。[5] 这说明的是一种集成方法，不代表使用任何 LBC 模块都必须购买或配置同样的 ProDiag 功能。

对自己的项目，我会沿着这条关系检查：块里判断出的异常，经过状态值和报警映射以后，画面能否仍然准确解释？如果 PLC 已经区分了不同原因，HMI 最后却只有一句“设备故障”，这条信息链就没有接完整。

复位也需要单独理解。清除一个状态、确认一条报警、重新允许设备动作，可能是不同的操作。具体块怎样处理，需要查该块和版本的说明；不能把“画面上的红色消失了”当作所有恢复条件都已满足。

五、库提供了基础，项目仍然要决定使用边界

研究 LBC 时，我会把“设备对象自身的行为”和“整台机器的要求”分开。前者可以借助标准模块；后者仍包括动作顺序、模式切换、设备之间的协调，以及异常后的处置。

例如，一个模块能够处理手动命令，并不能替项目决定：自动流程进行到一半，是否允许人工接管？接管前要确认哪些条件？退出手动后从哪个状态继续？这些问题必须有项目自己的答案，而不是靠 HMI 多放几个按钮来解决。

安全边界也不能省略。普通控制里的许可、联锁或故障反馈，不能仅凭名称就当作已实现的功能安全措施。Siemens 在 AF 中另设 Safety 章节，明确要求按具体应用评估风险并正确配置、编程和验证安全功能。[6] 本篇的设备控制讨论不替代风险评估、F 程序、F-I/O 钝化与重新集成要求或最终安全验收。

还有一个容易忽略的边界是版本。能在一张官方截图里看到某个接口，并不等于手头下载的每个块都有同样的成员、默认值和行为。正式使用前，应以实际库包、目标 CPU、工程软件和 HMI 版本逐项核对。这里不把 AF 示例的版本当成独立 LBC 库的兼容性声明。