设备交付半年了，尾款还没到账；试用期三个月到了，客户一句“再让我用用”就把设备继续开着；租赁设备到期了，客户不还也不买。做非标设备、专用机械的朋友，这几句话听着是不是特别耳熟？干这行久了就会明白，合同是合同，回款是回款，中间隔着的是客户的实际使用意愿。所以很多设备厂商会在PLC程序里做一道“时间锁”，设备运行到授权日期自动停机，输入厂家提供的解锁码才能继续运行。这就是标题里说的“西门子博图时间加密程序块”：基于TIA Portal（博途）环境，为S7-1200/1500系列CPU量身定制的授权控制功能块。
这篇文章把我实际项目中反复验证过的方案完整梳理了一遍，包括为什么用时间锁、程序块怎么设计、防篡改逻辑怎么落地、1200和1500两条平台有什么本质差异、以及各种边角问题的排查思路。不管你是给自家设备加授权机制，还是接了一个“帮忙写个到期停机”的私活，这篇都能直接参考着抄作业。
1. 为什么设备要加时间锁——场景与方案选型
1.1 时间锁解决的典型工程问题
先说场景。我碰过的需求大致分几类：
- 尾款保障：设备发货时先收首付款，剩余尾款约定验收后付清。但设备都拉客户现场了，客户今天拖明天、明天拖后天，尾款就是不到位。时间锁在这类场景里的角色是给谈判加一个“硬边界”。
- 租赁计费：设备按季度或年度租赁，租期到了自动锁定，续费后由我们下发新的解锁码。
- 试用期限制：给意向客户免费试用一个月，到期后客户如果买，我们远程提供正式授权；如果不买，设备自动停。
- 分期付款：部分客户资金紧张，约定分12个月付款。每个月由我们下发一个周期解锁码，客户付款后解锁下月。
这些需求如果靠人工催，效率低，还容易闹僵。程序块的好处是自动化：到期自动锁定，不用我们开口；客户主动联系，说明有真实续费或购买意向，双方都好下台阶。
1.2 可行方案对比：为什么不能无脑选一种
做时间锁，实现方式其实不止一种。我简单列一下，顺便说说各方案的坑。
| 方案 | 实现思路 | 优点 | 致命伤 |
|---|---|---|---|
| 硬件计时模块 | 外接一个独立的日历/计时模块，PLC通过通讯读取 | 不依赖PLC时间，断电也能走时 | 增加硬件成本，模块可能被剪掉或短路，通讯故障时逻辑难判 |
| PLC定时器累计 | 用保持型定时器累计设备运行时长，用总时长做授权 | 完全不受断电和改时间影响，实现简单 | 只能按“通电小时数”授权，没法按自然日/日期授权 |
| 系统时间判断 | 读CPU系统时间，与授权截止日期比较 | 直观、零成本、日期概念清晰 | 依赖CPU时钟精度和断电保持，可能被人改时间绕过 |
| 上位机/云平台校验 | 设备联网，由服务器下发授权状态 | 最灵活，可远程管理 | 需要一个长期维护的服务端，断网场景直接失效 |
这里有个关键判断：没有哪一种方案是万能的，真正可靠的是根据平台特性组合使用。比如S7-1500自带电池保持RTC，断电后时间基本不丢，用“系统时间+日期判断”就非常顺手；S7-1200断电后时间只能靠内部电容维持一小段时间，一旦时间回退，直接按日期锁就会出大问题。所以标题说“为1200/1500系列量身定制”，本质区别就在这里。
1.3 我最终选择的组合方案
在综合考虑之后，我基本采用的是这套组合：
- 主判断逻辑：读取CPU本地时间，与出厂时写入的授权截止日期比较。
- 防篡改核心：时间回拨检测，凡是发现当前时间比上一次记录的时间还早，一律判定为非正常状态并锁定。
- 时间有效性保护：如果PLC时间明显无效（例如年份小于某个阈值），不直接误锁，而是视为时钟异常，等待校准。
- 解锁机制：厂家输入动态解锁码，解锁码与设备ID、当前日期绑定，避免一个码全国通用。
对S7-1200平台，我会额外提供一个“累计通电时长”的备选方案，专门应对RTC掉电保持能力弱的问题。这套组合的优点在于：不增加硬件成本，逻辑全部在PLC内部完成，修改灵活，也能承受客户“改时间”这种最常见的绕过尝试。
2. 程序块的整体架构与防篡改核心原理
2.1 功能块的外部接口设计
程序块我用FB（函数块）来做，名字叫FB_TimeLock。选择FB而不是FC，是因为FB自带背景DB，保持性变量天然可以落在背景DB里，掉电后锁定状态不丢。接口设计如下：
| 参数方向 | 参数名 | 数据类型 | 说明 |
|---|---|---|---|
| 输入 | i_bEnable | Bool | 总开关，TRUE启用锁定逻辑 |
| 输入 | i_ui_ExpireYear | UInt | 授权截止年份 |
| 输入 | i_ui_ExpireMonth | UInt | 授权截止月份 |
| 输入 | i_ui_ExpireDay | UInt | 授权截止日 |
| 输入 | i_bTryUnlock | Bool | 解锁请求沿信号 |
| 输入 | i_ui_UnlockCode | UInt | 客户输入的解锁码 |
| 输入 | i_ui_DeviceID | UInt | 出厂写入的设备ID |
| 输出 | o_bLocked | Bool | 当前锁定状态 |
| 输出 | o_bExpired | Bool | 是否因到期锁定 |
| 输出 | o_bTamper | Bool | 是否因时间异常锁定 |
| 输出 | o_bClockInvalid | Bool | 当前时钟是否无效（未校准） |
| 输出 | o_us_RemainDays | UInt | 剩余天数（粗略估算，用于HMI显示） |
背景DB里放一组保持性变量：
| 变量名 | 数据类型 | 说明 |
|---|---|---|
rb_LastTimeStamp | ULInt | 上一次正常运行时间戳 |
rb_InitDone | Bool | 首次运行初始化标志 |
rb_LockFlag | Bool | 锁定标志，断电保持 |
这里有个很实际的经验：锁定标志一定要做成保持性的，而且放在背景DB的可保持区。如果断电后锁定标志丢了，客户只要重启设备就能绕过锁定，时间锁等于白做。
2.2 三大核心机制拆解
到期判断的机制很简单，核心是一个时间戳：把年月日时分秒拼成一个14位整数，比如2026年12月31日23时59分59秒就是20261231235959。当前时间戳大于等于截止时间戳，就表示到期。用整数比较，比逐字段比较年月日清爽得多。
时间回拨检测的逻辑稍微绕一点，核心思路是：设备每次通电运行时，把当前时间戳存到保持性变量里。如果这次上电读到的时间戳小于上次记录的时间戳，说明时间被往回调了。为什么能抓住？因为正常的时间流逝方向是单调递增的，回拨一定意味着有人动过手脚。
时间有效性判断是最容易忽略的部分。S7-1200断电后RTC会回到一个出厂默认时间，如果直接拿这个时间跟上次记录比较，会误判成“回拨”并锁死。所以代码里要先判断当前年份是否小于一个合理基线，比如小于2020年，就认为是时钟无效，进入等待校准流程，不参与锁定判断。
2.3 关于“加密强度”的实话
必须说清楚：PLC时间锁不是军用级加密，它防的是“懒人型绕过”。一个熟悉博途的工程师上载程序、在线监视、直接改掉保持性标志位，理论上还是能绕过。所以在工程上我会再加两道保险：
第一道是博途自带的专有技术保护。对FB和背景DB设置编译保护后，别人上载程序只能看到接口，看不到SCL源码，也就不知道锁定逻辑怎么写的。
第二道是冗余锁定标志。不要把锁定状态只放一个变量里，放两到三个互相校验。比如rb_LockFlagA、rb_LockFlagB、rb_LockFlagC，三个都一致才认为是有效状态，否则按锁定处理。这样即使有人在线改其中一个，锁定逻辑依然生效。
强度层面我的原则是：不要试图做到绝对防破解，而是把破解成本提高到“不如老老实实付款”的程度。
2.4 SCL核心代码：到期判断与防回拨
下面这段是功能块的SCL核心逻辑，我跳过了变量声明，重点看算法：
// 1. 读取PLC本地时间 #tmp_Retval := RD_LOC_T(OUT => #tmp_DTL); // 2. 当前时间转14位时间戳 #tmp_NowStamp := UINT_TO_ULINT(#tmp_DTL.YEAR) * 10000000000 + UINT_TO_ULINT(#tmp_DTL.MONTH) * 100000000 + UINT_TO_ULINT(#tmp_DTL.DAY) * 1000000 + UINT_TO_ULINT(#tmp_DTL.HOUR) * 10000 + UINT_TO_ULINT(#tmp_DTL.MINUTE) * 100 + UINT_TO_ULINT(#tmp_DTL.SECOND); // 3. 截止时间戳：截止当天23:59:59 #tmp_ExpireStamp := UINT_TO_ULINT(#i_ui_ExpireYear) * 10000000000 + UINT_TO_ULINT(#i_ui_ExpireMonth) * 100000000 + UINT_TO_ULINT(#i_ui_ExpireDay) * 1000000 + 235959; // 4. 首次运行初始化：只记录时间，不判断 IF NOT #rb_InitDone THEN #rb_LastTimeStamp := #tmp_NowStamp; #rb_InitDone := TRUE; END_IF; // 5. 时间有效性保护：年份明显异常时不参与锁定 IF #tmp_DTL.YEAR < 2020 THEN #o_bClockInvalid := TRUE; // 时钟无效时不做回拨判定和到期判定 ELSE #o_bClockInvalid := FALSE; // 6. 时间回拨检测 IF #rb_LastTimeStamp > #tmp_NowStamp THEN #o_bTamper := TRUE; #rb_LockFlag := TRUE; END_IF; // 7. 到期判断 IF #tmp_NowStamp >= #tmp_ExpireStamp THEN #o_bExpired := TRUE; #rb_LockFlag := TRUE; END_IF; END_IF; // 8. 解锁码验证：动态解锁码，绑定设备ID和截止日期 #tmp_UnlockRef := ((UDINT(#i_ui_DeviceID) * 31 + UDINT(#i_ui_ExpireYear) * 12 + UDINT(#i_ui_ExpireMonth)) * 100 + UDINT(#i_ui_ExpireDay)) * 137 + 8861; #tmp_UnlockRef := #tmp_UnlockRef MOD 1000000; IF #i_bTryUnlock AND #i_ui_UnlockCode = UINT_TO_UDINT(#tmp_UnlockRef) THEN #rb_LockFlag := FALSE; #o_bTamper := FALSE; #o_bExpired := FALSE; #rb_LastTimeStamp := #tmp_NowStamp; END_IF; // 9. 锁定输出 IF #i_bEnable THEN #o_bLocked := #rb_LockFlag; ELSE #o_bLocked := FALSE; END_IF;代码里的细节我给几个注释：时间戳拼接时注意类型转换，因为DTL的年月日是UInt（16位），直接和10位数相乘会溢出，必须先转成ULInt。解锁码计算同理，乘法结果要用UDInt承接，再用MOD 1000000取6位。整个解锁码的逻辑不需要客户理解，只要厂家这边拿着同样的算法用Excel或小工具生成即可。
3. 1200与1500平台适配要点及实操配置
3.1 S7-1500：绝对日期锁是首选方案
S7-1500全系列都带电池或电池模块，RTC在断电后能长期保持，日期锁的基础条件非常稳。所以1500平台上，直接采用上面这套“系统时间+防回拨+动态解锁码”的逻辑，效果最好。
实际配置时有几个步骤需要注意：
- 在CPU属性里启用“时间同步”为手动或NTP方式，保证设备交付时时间被校准过。
- 把
FB_TimeLock的背景DB的保持性属性打开。选中DB，勾选“保持性”，确保rb_LockFlag在断电后不丢。 - 在OB1里每个扫描周期调用一次
FB_TimeLock，且调用位置放在程序最前面，避免其他逻辑在锁定后还执行一轮。 - 锁定动作建议用常闭触点串联到设备的运行控制回路，锁定时直接切断自动运行。
S7-1500的背景DB默认是优化访问，保持性变量的分配不用操心，工程上很省事。
3.2 S7-1200：必须处理RTC掉电保持能力
S7-1200的RTC在外部断电后依靠内部电容只能维持较短时间，具体时长和固件版本、环境温度都有关系。一旦时间超过保持期限，上电后RTC会回到一个基准值，这时候如果直接跑日期锁，就会出大问题：要么把正常设备误锁死，要么被客户通过断电大法绕过授权。
针对1200平台，我给出两条路线：
路线一：带时钟有效性保护的日期锁。就是上面SCL代码里#tmp_DTL.YEAR < 2020那一段逻辑。时间无效时不参与锁定，但输出o_bClockInvalid报警。这个方案适合设备平时不断电、偶尔短时间断电的场景。客户短时间断电再上电，RTC时间还在，不影响；万一时间丢了，设备不锁死，但HMI上会显示“时钟异常请联系厂家”，由厂家重新校准后继续使用。
路线二：累计通电时长方案。完全不依赖RTC，用保持型定时器或循环中断累加设备通电时间。我做过一个版本，在OB10循环中断里固定每100ms累加一次：
#rb_RunSeconds := #rb_RunSeconds + 1; // 保持性变量，单位0.1秒授权到期判断改为：#rb_RunSeconds > 授权总时长(单位0.1秒)。这个方案的好处是客户怎么断电、怎么改时间都影响不了累计值，只能老老实实找厂家解锁。缺点是只能按“设备通电时长”授权，例如“授权运行500小时”，没法做成“2026年12月31日到期”这种自然日期模式。用于租赁和分期场景反而够用。
3.3 保持性DB与专有技术保护的配置步骤
这两个配置的实操细节非常关键，我踩过坑，直接讲重点。
配置保持性DB，步骤是这样的：
- 在博途项目树里选中背景DB，右键“属性”。
- 找到“保持性”属性，选择“保持性”选项（注意TIA里1200和1500的界面略有差异，但都在通用属性里）。
- 把需要掉电保持的变量
rb_LockFlag、rb_LastTimeStamp、rb_InitDone确认在保持区域。 - 编译并下载。
配置专有技术保护，步骤是这样的：
- 选中
FB_TimeLock，右键“属性”。 - 在“编译”页签里勾选“专有技术保护”。
- 设置密码并确认。
- 编译。编译后，从PLC上载程序，外部只能看到FB的接口和背景DB，看不到内部SCL逻辑和局部变量。
注意：专有技术保护只保护代码不被查看，不保护接口数据。所以锁定标志的值还是有可能被在线监视到的。真正要防在线改值，请配合本文2.3节的冗余锁定标志。
另一个大坑是下载程序时保持性值会被清空。如果你修改了DB的结构或者勾选了“下载后复位”，背景DB里的rb_LockFlag会被重置成初始值。遇到这种情况，最稳妥的做法是：下载前先在线备份背景DB的值，下载后把保持性变量重新写回去。我在现场调试时经常遇到“下载一次程序，锁就被解开了”的问题，后来养成了下载前备份的习惯，就再没出过这个乱子。
3.4 在OB1中调用FB与HMI解锁界面设计
调用位置我建议放在OB1最前面，这样每个扫描周期最先执行锁定判断，后续任何逻辑都受到约束。调用时背景DB选择一个新的实例DB，例如DB_TimeLockData。参数按接口表一一连接即可。
HMI解锁界面的设计我们用的是西门子触摸屏，画面逻辑是这样的：
- 第一屏“设备状态”：显示锁定状态、剩余天数、时钟异常报警。锁定图标用红色，正常用绿色。
- 第二屏“授权管理”：一个输入框输入解锁码，一个“尝试解锁”按钮。这个画面在触摸屏的用户管理里设了权限，只对厂家组开放，客户看不到。
- 解锁按钮的点击事件直接触发
i_bTryUnlock的上升沿，同时把输入框的内容赋值给i_ui_UnlockCode。
实际使用中的流程是：客户发现设备停机，HMI上显示“请与厂家联系”，客户打电话过来，我们问设备ID，然后根据“截止日期”和“设备ID”用Excel算出解锁码，客户输入后设备恢复运行。整个过程不超过两分钟。
4. 常见问题与排查技巧实录
4.1 客户改PLC时间绕过锁怎么办
改时间是最常见的绕过尝试。针对不同的改法，前面两套机制分别有应对：
| 改法 | 现象 | 结果 |
|---|---|---|
| 把时间改到过去 | 当前时间戳小于上次记录时间戳 | 触发回拨检测，直接锁定 |
| 把时间改到未来很远 | 当前时间戳大于截止时间戳 | 直接触发到期锁定 |
| 把时间改到授权期内更早日期 | 时间戳小于上次记录 | 同样触发回拨检测 |
| 把时间改到授权期内更晚日期 | 时间戳大于上次记录，但未到期 | 设备继续运行，但剩余天数变少，对客户无收益 |
可以看到，在“回拨检测+到期判断”的夹击下，单纯改时间几乎没法占到便宜。我实测过几种思路，基本都堵住了。
这里还要提醒一句：如果客户通过博途在线功能直接改PLC时间，改完立刻就会在程序里留下记录。因为rb_LastTimeStamp保持性变量已经记录了改之前最后运行的时刻。只要时间发生过回退，插翅难逃。
4.2 断电后PLC时间丢失导致误锁
这个问题在S7-1200上尤其常见。设备停了一个月再上电，RTC电容早就放完了，时间会回到一个基准值。如果代码里直接做回拨检测，就会把正常设备锁死。
解决思路就是2.2节提到的时间有效性判断。阈值设多少有讲究：我一般设成“授权截止年份-1”和“系统部署年份-1”的最小值。比如设备是2025年交付的，授权截止是2026年，那我设阈值就是2020年，既不会误伤正常时钟，又能挡住明显回拨。
如果现场遇到误锁，解锁方式很简单：用博途在线连接，把PLC时间改成正确时间，再输入一次解锁码，锁定标志清零，rb_LastTimeStamp刷新到当前时间，恢复正常。
4.3 下载程序后锁被清空
这个问题我在3.3节提过，再深入说一个真实案例。有一次我在客户现场优化FB逻辑，修改完之后直接点击“下载”，没有勾选“仅下载更改”。结果下载完成，客户设备自动进入锁定状态——锁倒是没被解开，而是被“双重锁死”了，因为保持性DB被初始化，rb_LastTimeStamp清零，rb_InitDone也清零，上电后第一次跑初始化逻辑，居然把当前时间当基准时间存进去了，后边一切正常。但如果是客户自己下载新程序，就很容易把锁定标志清掉，等于免费解了一次锁。
所以我的建议是：出厂前把背景DB的备份留好，下载时尽量选择“仅下载更改”，修改FB代码但不改DB结构时一般不会清保持值。如果必须覆盖下载，下载完成后第一时间核对rb_LockFlag的值。
4.4 解锁码算法被破解怎么办
如果设备卖出去了几万台，解锁码算法又在某个环节泄露了，那后果就是所有设备都能被客户自己解锁。我的做法是给每台设备一个独立的DeviceID，出厂时写入背景DB的保持区。解锁码计算时必须带上这个ID。这样即使算法泄露，不知道具体设备的ID也没法算码。
有的同行会做得更狠，把解锁码算法做成按季度更换，每个季度厂家换一个盐值。这需要厂里维护一套小工具，但安全性确实更高。我目前的方案是“设备ID+截止日期+固定盐值”的三元组，配合TIA的专有技术保护，对绝大多数客户来说已经是铜墙铁壁了。
4.5 测试阶段“改时间把自己锁住”的实操经验
这块是我最想分享的“现场翻车”经验。第一次测试时，我为了验证到期锁逻辑，把PLC时间直接调到了截止日期之后。验证完，锁定了，然后我想恢复时间，却忘了刚才时间已经被记录成了“未来时间戳”。结果我改回正确时间的时候，回拨检测直接触发，设备又被锁了一次。然后我又输解锁码解锁，但又忘了解锁后rb_LastTimeStamp会刷新成“当前时间”，于是只要我继续在“未来时间”和“真实时间”之间反复横跳，它就会反复锁。
后来我总结出一套测试流程：
- 测试前，先把解锁码算好，放在手边。
- 修改PLC时间测试到期逻辑，验证完成后，先把时间改成正确时间，再输入解锁码，一次性完成“解锁+刷新基准时间戳”两个动作。
- 不要修改一次时间测试完立刻又改回去，中间一定要执行“时间校准→输入解锁码→确认锁定标志清零”的完整流程。
这套流程我后来写到了项目调试手册里，后面带新同事做测试，再也没有出现过“自己锁死自己”的尴尬局面。
5. 最后补一个实用细节：锁定动作要讲究“体面”
时间锁的最终目的是让客户联系厂家，而不是把设备毁掉。所以锁定动作本身也需要设计。我的建议是分级处理，不要把“到期”变成“原地爆炸”：
- 提前30天：HMI弹窗提示“设备即将到期，请与厂家联系”，不锁机。
- 提前7天：每天增加一次短暂停机提示，比如运行10分钟提示一次，但还能干活。
- 到期后：设备进入“限制运行模式”，自动停止自动循环，但允许手动点动操作。这样设备可以停在安全位置，避免产品卡在半截、机械手臂停在空中这类危险情况。
这个“体面停机”的细节，客户体验好很多，也显得咱们做事专业。我在好几个项目里都是因为这个设计，被客户评价“想得周到”。
根据我个人的实际体会，时间加密程序块本身写起来不难，难点全在边界情况的处理上：掉电时间丢失、时间回拨、下载清保持值、解锁流程顺畅度。把这些处理好，这套功能才能真正给设备厂商带来回款保障，而不是给现场调试添堵。希望这篇整理能让你少走几趟弯路。
