1. 为什么会有“动态加密计时”这种需求
先聊个真实的场景：你接了一个某物流仓库的PLC改造项目，用的是西门子S7-1200，程序写完了，现场也调试完了，生产线跑得贼顺。结果呢？甲方那边负责验收的经理出差了、盖章的领导去开会了、财务说要等发票一起走流程……反正就是一个“等”字，拖了你一个半月。你这边每天都在想，这活儿到底什么时候能收尾？下个项目的房租、人工、设备款都堆在那，资金链都快断了。
这就是咱们工控行业的老大难：技术难度从来不是核心瓶颈，回款周期才是。硬件成本、调试工时、差旅花费、反复修改的隐性成本，全压在你身上，但付款节奏却完全不在你手里。很多同行搞了几年，项目做了一大堆，年底一算账，利润全在“应收账款”里挂着。那种干完活、验收单签了、就是钱迟迟不到位的感觉，真比写不出程序还闹心。
所以就有了“动态加密计时”这种想法，听着挺玄乎，其实核心思路很简单：在不破坏设备正常运行的前提下，为你的程序加上一层时间相关的授权保护机制。当项目顺利完成验收、款项结清后，你提供一个“正式释放”的授权即可；但如果项目已经到了合同规定的付款节点、甲方却迟迟不推进，程序会在预设的时间窗口内逐步限制某些非核心功能的使用——注意，是逐步提示、非破坏性降级，绝不是让设备突然停转、产品卡在半道，那会出安全事故，咱们坚决不能干。
这套方案的底层逻辑，其实是从商业软件领域借鉴过来的：你用自己的技能和工时服务于项目，知识产权和技术成果理应受到尊重，而“动态加密计时”就是给技术人员一个结构化的自我保护工具。它解决的不是“写不出程序”的问题，而是“写完程序之后怎么体面地推进验收和回款”的问题。
适合谁看？主要是有独立接项目、或者在小团队里负责完整交付的PLC工程师、自动化项目负责人。如果你是在大厂做驻场运维，或者项目本身是内部固定资产，那这套东西基本用不上，别给自己找麻烦。
2. 核心原理拆解：西门子PLC的加密与计时机制
2.1 先搞清楚PLC的“加密”到底能做什么
西门子PLC的加密体系分好几个层级，很多新手容易搞混，我在这里给捋一下。
第一类是访问级保护。比如S7-1200/1500的“专有技术保护”（Know How Protect），可以对块（FB/FC/OB）进行加密，别人即使上传了你的程序，也看不到内部逻辑，只能看到接口。这种保护是“防窥探”的，不会影响运行。
第二类是下载保护。也就是防止别人把你的程序上传走、复制到别的PLC上，属于防克隆范畴。
第三类是运行级授权机制。这种不是西门子官方模块直接提供的，而是需要你在程序里自己搭建的逻辑——通过读取PLC的系统时钟、比对预设授权信息、控制某个运行标志位，来实现“时间到了该提醒”或“授权验证不通过则降级运行”的功能。
咱们要说的“动态加密计时”，就是基于第三类机制的工程化实现。它的技术本质是：把你的逻辑成果和PLC内部的实时时钟（RTC）绑定，通过授权码、窗口期、累计运行时间三个维度，形成一套动态约束体系。
这里要强调一下：这套方案不代表西门子官方某款加密狗功能的替代品。它是在你合法拥有项目主导权、并已与甲方签订明确合同的前提下，用来规范化交付与回款节奏的一种工程手段。如果项目条款里明确写了“质保期一年、设备必须无条件运行”，那你在交付前就应该把授权周期设置得足够长（比如两年），绝不能让设备在你撤场后三天两头提醒“授权过期”，那种吃相太难看了，也会砸招牌。
2.2 “动态”二字到底体现在哪
“动态”这个词，放在咱们这个场景里，指的是两个层面的变化：
第一，授权状态不是一锤子买卖。你可以设置多个阶段：正常运行期、友好提醒期（屏幕上有文字提示联系开发者确认验收）、功能降级期（锁定部分非关键辅助功能，比如数据记录、某一路不太重要的模拟量输出），最后才是锁机等待期。每一阶段的转换条件，都是“当前PLC时间”与你在程序里预设的时间基准点的差值。
第二，计时方式要能自适应。单纯看日历时间有个漏洞——如果甲方把PLC的时钟往回改了（比如断电状态下把RTC改慢半年），你的保护机制就形同虚设。所以动态加密计时要引入“累计运行时间”的概念。你可以用OB1里的扫描周期计数，或者用系统自带的运行小时计数器（S7-1200的Diagnostic Buffer里其实有上电时间统计），把你程序激活后的累计运行时长也作为一个判据。这样，就算对方把日历往回拨，累计运行时长照样在涨，授权保护一样生效。
2.3 S7-1200和S7-200 SMART的差异
做这套方案，你大概率会碰到两种主流平台：S7-1200/1500和S7-200 SMART。
S7-1200/1500的优势在于：支持READ_CLK（读取RTC）、WRITE_CLK（写入RTC）系统指令，而且可以在HMI上直接显示时钟状态，程序块支持加密，逻辑写起来结构很清晰。做动态授权计时，首选这个平台。它的字符串处理能力、数据类型转换也都比较丰富，做授权码比对的时候很方便。
S7-200 SMART就麻烦一些。它的时钟读取指令是READ_RTC，返回的是BCD码格式，用起来不够直观。而且200 SMART的存储区空间有限，程序保护机制也比较基础（只支持CPU级别的密码保护，不支持块级别的Know How Protect）。如果你的项目必须用200 SMART来做这套逻辑，那建议把授权管理的核心逻辑放在触摸屏上（如果配了HMI的话），PLC里只留简单的“允许运行/禁止运行”标志位，效果会好很多。
顺便说一句：S7-300/400的老设备现在新项目里已经很少见了，如果碰上改造项目需要加这种计时保护，大部分情况是外部单片机或者仪表定期发送心跳信号给PLC，PLC收到心跳才正常运行——这种方案做起来更麻烦，但可靠性还行，我早期在一个老水泥厂改造项目里就这么干过。
3. 完整实现方案：从需求分析到程序落地
3.1 先确定授权策略
动手写代码之前，最要紧的不是打开TIA Portal，而是把这个授权策略用文字写清楚。我一般会做一个类似这样的表格，跟客户或者自己团队过一遍：
| 阶段名称 | 触发条件 | 设备表现 | 处理方式 |
|---|---|---|---|
| 正常运行期 | 授权有效期内 | 无任何提示，全功能运行 | 无 |
| 友好提醒期 | 距到期日≤14天 | 触摸屏弹窗提示“设备运行正常，请联系项目方确认服务状态”，HMI上显示剩余天数 | 不影响生产 |
| 功能降级期 | 距到期日≤3天 | 锁定非核心功能（如报表打印、历史数据导出） | 主要工艺保持运行 |
| 待授权期 | 已到期 | 开机运行30分钟后自动停机，触摸屏显示授权码输入界面 | 需输入正式授权码解锁 |
这里要重点说一下“待授权期”的设计。很多新手会写成“到期直接停机”，我不建议这么做。从工程伦理和安全角度讲，突然停机在大多数工业现场是不可接受的（尤其涉及炉温、压力、运动控制这种场景）。所以我更推荐“运行30分钟后停机”的方式——给现场操作人员一个缓冲时间，让他们有时间去联系管理方，而不是直接把设备卡死在那个节骨眼上。同时，停机动作本身只能作用于安全可中断的设备（比如普通传送带、风机），绝对不能用于安全联锁回路。
3.2 数据块设计：授权信息的“存储地基”
在S7-1200里，我会专门建一个DB块，名字就叫DB_Authorization，里面定义这些变量：
| 变量名 | 数据类型 | 初始值 | 说明 |
|---|---|---|---|
| CurrentDate | DTL | -- | 当前PLC时间（由READ_CLK自动刷新） |
| InstallDate | DTL | -- | 程序激活日期（首次上电自动写入） |
| ExpireDate | DTL | -- | 授权到期日期（由授权码计算得到） |
| RunHoursAccum | REAL | 0 | 累计运行时间（单位：小时） |
| AuthStatus | INT | 0 | 授权状态：0=正常，1=提醒，2=降级，3=待授权 |
| AuthCodeInput | STRING[32] | '' | 触摸屏输入的授权码 |
| LicenceValid | BOOL | FALSE | 授权有效标志 |
| FirstRunFlag | BOOL | FALSE | 是否是首次激活 |
| OffsetDays | INT | 0 | 授权码中包含的有效期天数偏移 |
这个DB块是整个方案的核心，相当于你的“授权信息数据库”。注意，这里有几个细节容易踩坑：
InstallDate的写入时机必须放在首次上电扫描周期里。我在OB100（启动组织块）里做这个判断：如果FirstRunFlag为FALSE，说明是第一次激活，就写当前时间到InstallDate，然后把FirstRunFlag置TRUE。一定要用保持型M或DB位，不然每次断电上电都会重新写日期，授权保护就直接失效了。
ExpireDate的计算逻辑：我推荐用库函数法，因为TIA Portal里STL编写日期运算比较麻烦，直接用高级语言（SCL）写一个根据OffsetDays计算到期日期的函数会顺畅很多。S7-1200支持SCL，所以直接把日期转成Unix时间戳格式（自1990年1月1日算起的秒数），加上OffsetDays×86400，再转回DTL格式，判断逻辑就简单了。
3.3 授权码算法设计
授权码是整套机制的“钥匙”，设计得好不好直接决定安全性。简单分享一套我在实际项目里用过的方案，思路来自常见的注册码算法：
生成端（你在办公室用自己的电脑，跑一个Python或C#的小工具）：
- 取PLC的CPU唯一标识（在TIA Portal在线诊断里能看到，类似设备编号、MAC地址序列号这类的个性化标识，具体字段每个系列有差异，能取到就行）。
- 把这个标识和授权天数（如365）和到期日拼起来，形成一个字符串。
- 对这个字符串做HMAC-SHA256运算，密钥是只有你知道的一个长字符串（建议至少32个字符）。
- 把得到的哈希值做Base36编码（0-9和A-Z），取前24位，每4位一组加一个短横线，就得到类似
X7K2-PQ4M-9ZT5-8WQ1-3R6U-...这样的授权码。
PLC端验证逻辑：
- 操作员在HMI上输入这串授权码。
- PLC的SCL程序按照完全相同的算法（PLC里做HMAC-SHA256比较吃力，但S7-1200固件V4.4以上已经有了相关指令支持，比如LIBRARY里自带的加密计算块；如果你的CPU不支持，也可以降级用简单的CRC32校验，安全性略低但对一般场景够用）算出预期哈希值。
- 和输入的授权码比对，一致则
LicenceValid:=TRUE，然后用授权码里解析出来的OffsetDays和CPU标识一起重新计算ExpireDate。
这里有个经验：授权码里的字母要剔除容易混淆的O和0。另外，为了保证授权码在离线状态下也能用（毕竟现场可能没有外网），PLC侧的密钥就是硬编码在程序里的。所以PLC程序块本身一定要开启Know How Protect，防止别人把授权验证逻辑破解了。
提示：在PLC内部实现SHA256/HMAC需要一定的计算资源和存储空间，建议基于S7-1200 V4.4以上固件，并提前在TIA Portal里将相关安全库函数编译进去。如果遇到固件版本太低、库里没有现成加密块的情况，别死磕，直接换CRC64/自定义查表法做降级方案，效果也不差。
3.4 程序主体结构
整个动态加密计时程序，我习惯把它拆成三个功能块，这样调试和维护都清晰：
FC_TimeManage：管理时间逻辑
- 调用READ_CLK读取CurrentDate
- 计算剩余天数：
RemainDays := ExpireDate - CurrentDate - 把RemoteDay发送给HMI显示用
FC_AuthLogic：管理授权判断
- 判断AuthStatus：①如果AuthStatus=0且RemainDays>14天，维持正常；②如果RemainDays降到14天以内，置为1；③如果RemainDays≤3天，置为2；④如果已经过期（RemainDay<0），置为3。
- 如果
LicenceValid为TRUE且RemainDays刷新后为正，则所有功能维持正常。
FB_SafeGuard：执行保护动作
- 这是个FB，因为要有静态变量来记录“已运行30分钟”的定时状态。
- 当AuthStatus=3时，系统启动后开始累计运行时间，达到设定的缓冲分钟数（比如30分钟），就把
SafeStopRequest置TRUE，让主流程HMI或接口程序收到停机请求信号。 - 同时，HMI上显示强制密码输入框，把AuthCodeInput传给FC_AuthLogic做验证，验证成功则自动复位所有状态，强制执行一次日期刷新。
SCL伪码示例，放在FC_AuthLogic的调用段里：
IF NOT #DB_Auth.LicenceValid THEN #DB_Auth.AuthStatus := 3; // 授权未解锁 ELSE #DB_Auth.RemainDays := CALC_REMAIN_DAYS(#DB_Auth.ExpireDate, #DB_Auth.CurrentDate); IF #DB_Auth.RemainDays > 14 THEN #DB_Auth.AuthStatus := 0; // 正常 ELSIF #DB_Auth.RemainDays > 3 THEN #DB_Auth.AuthStatus := 1; // 提醒期 ELSIF #DB_Auth.RemainDays >= 0 THEN #DB_Auth.AuthStatus := 2; // 降级期 ELSE #DB_Auth.AuthStatus := 3; // 待授权 END_IF; END_IF;3.5 与HMI的联动
这套方案的效果好不好，HMI侧的配合很关键。强烈建议在触摸屏上增加一个独立的“系统服务”页面（最好放在系统设置里，别太显眼，也不要用“注册码”这种字眼，就用“服务信息”这种中性名称）。
页面上显示：
- 当前日期时间（直接读PLC的CurrentDate，如果发现时钟不对，HMI会有标识）
- 剩余运行天数
- 一个授权码输入框
- 运行状态文字（正常服务中/请联系服务商确认服务状态/服务状态需要确认）
HMI报警文本可以用得缓和一些。比如“设备运行状态：系统将在倒计时结束后进入服务确认流程，请与项目供应商确认服务的连续性”，这种话术既不显得突兀，也能清晰地传达信息——甲方收到之后自然会去找商务对接。
4. 实际调试中的常见坑与排查技巧
4.1 PLC时钟被改怎么办
这是很多同行用这类方案时最先担心的点。如果你只是单纯读RTC来做判断，那确实容易被“往回拨”绕过去。所以我在3.2节提到累计运行时间就是为了防这一手。
实际项目里，我见过最狠的情况是甲方直接把PLC的RTC电池断开、再回拨两年。但因为他每天生产总要开机，累计运行时间计数器一直在涨，所以到期保护照样触发。两种计时方式取“最严”（也就是先触发的那个），逻辑上就不会被轻易绕过。
4.2 授权码算好了，但HMI输进去没反应
大概率是“授权码解析的OffsetDays”和“PLC端用于验证的CPU标识”对不上。生成授权码的时候，你一定要在TIA Portal在线诊断里复制实际硬件标识，不要用模拟器里的虚拟标识。另外，剔除O和0那一步也要在PLC侧同步做，不然视觉上看起来一样，验证时却对不上。
4.3 断电重启后AuthStatus被重置了
这个原因一般是：你把AuthStatus定义在非保持型DB变量里，默认值又是0，一断电就回到“正常”状态。解决方案很简单：把AuthStatus以及FirstRunFlag、InstallDate、ExpireDate这些关键变量全部勾选“保持”（Retain），在S7-1200里就是给DB变量勾选保持属性。
4.4 时间计算差8小时
很多老项目PLC时钟默认用的是UTC，设备在东八区，就该考虑时区偏移了。建议在PLC程序里统一用UTC存储和比较，只在HMI显示的时候加8小时。如果一开始就混着用，到后面排查日期偏移问题时很容易被绕晕。
4.5 OB1里调用READ_CLK会不会影响扫描周期
实测下来影响很小。READ_CLK本身就是系统指令，读取RTC的操作耗时可忽略不计。我是每10秒调用一次，没必要每个周期都读。
4.6 触摸屏上传时把授权码界面暴露了
如果甲方自己会用TIA Portal或者WinCC，他可能会在HMI组态里把“系统服务”页面翻出来。所以建议给这块页面加一个单独的HMI用户权限（比如管理员角色）。西门子触摸屏用户管理是支持多角色权限的，把运维工程师、操作员、管理员权限分开，不会太麻烦。
5. 动态加密计时的法律边界与职业道德
这一节是我觉得必须要写的。这套方案能做，但绝不能滥用。它的正确打开方式是：作为项目交付和回款流程中的一项合同保障措施，目的是促使双方按约定完成验收和付款，而不是破坏设备的合法使用。
实际操作中，有几个边界一定要守住：
第一，书面合同里要写清楚。你可以在技术协议的补充条款里写明：“系统包含授权保护机制，设备交付后有一个明确的免费运行保障期，保障期结束后需提供有效服务授权码以维持全部功能运行；授权码将按合同约定的服务阶段提供。”这样这套机制就有了合同依据，不是暗地里坑人。
第二，不要影响安全功能。任何涉及安全回路（急停、安全门锁、光栅、抱闸控制）的部分，绝对不允许参与授权降级逻辑，这些部分必须无条件可靠运行。
第三，要留够缓冲区。提醒期至少14天，降级期至少3天，让甲方有充裕的时间走内部流程。动不动就“明天下班就锁机”的做法，在行业内传开了，你后续就很难接到新项目了。
第四，授权码发放要及时。正常节点是验收通过、合同款到账后，第一时间把正式长期授权码给甲方。如果甲方付了款，你这边还拖延，那就是你的不对了，非常败口碑。
6. 实操中的个人心得与扩展建议
这套动态加密计时方案，我在一个某食品包装线的项目里完整跑通过一遍。当时项目周期比较紧，现场调试完成后甲方内部要等集团审批才能验收付款，前后拖了两个多月，说实话我内心也焦虑，但因为程序里有这套保护逻辑，倒计时还剩一个多月的时候，甲方自己就主动催商务流程了，因为现场那台触摸屏上一直显着“剩余服务天数”，他们的设备主管一看就懂了，直接绕着弯提醒采购经理赶紧推进。最后验收和回款过程基本顺畅，双方也没因此翻脸。
几个具体建议：
建议一：授权状态提示别做得太“叫嚣”。我见过有的同行在HMI上弹窗写“非法使用，联系XXX”，那个太冲了，甲方看了很不舒服。咱们是技术保护，不是打劫，语气要专业、中性、友好。
建议二：授权码生成工具一定要离线保存。我一般是拿一个不联网的旧笔记本放一个小工具，输入PLC标识和天数就能生成。这个工具不用给别人，只你有就行。万一哪天笔记本坏了，授权逻辑源码还在，重新编译也能跑。
建议三：给PLC程序块加上下载保护之外，建议再设置一个CPU访问密码。把保护层级拉满，避免别人在线看你的程序、硬把授权逻辑找出来删除。
建议四：这套方案也可以拓展到设备预付款的“里程碑付款”场景。比如一个项目分三段付款，你就可以提供三段授权码，第一阶段授权90天，二期款收到了给第二段授权码，三期收齐再给永久授权。每个阶段授权码自动衔接，省得你反复跑现场去解锁。
最后再分享一个我个人的经验：做这一行，技术做到最后拼的是信任。动态加密计时是一个辅助工具，它能帮你把回款节奏掌握在自己手里，但不能替代项目的品质、售后的响应和基本的行业信誉。你手里有底牌，不代表你要随时掀桌子；大多数情况下，把底牌亮在明处、合同里写得清清楚楚，大家反而能踏踏实实按节奏办事。
