近日，天谋科技解决方案专家、IT-OT 域资深专家 Christofer Dutz 于德文期刊《Computer & AUTOMATION》发表题为《IT 与 OT 的融合：自动化领域的 IT 既视感》（“Das Déjà-vu aus der IT”）的行业分析文章，对于自动化领域中相关 IT 与 OT 技术的应用现状、发展方向与面临挑战进行了深入分析。以下为翻译内容全文。
如今的自动化领域正呈现出令人振奋的发展趋势——这些革命性的创新技术在 IT 领域已不新鲜，但在自动化领域却颇具新意。
当前，许多制造业公司的处境与 15 年前的 IT 行业颇为类似。因此，许多公司开始关注 IT 项目方法论。Scrum（一种敏捷项目管理框架）无疑是这方面最为人所知的方法。不过，在 OT 领域，尚无一家公司能够在一夜之间全面改用 Scrum。公司更倾向于分步落实。这种分阶段实施背后的逻辑是，团队希望尝试用更敏捷的方法，以省去冗长的前期规划，从而能够更快地开始实施项目。然而，管理层往往坚持要规划好固定的项目完成日期、设计特定的功能。并且需要随时获得团队的技术支持。
一个根本的挑战是敏捷方法的非此即彼性：企业要么全面采用敏捷方法，要么根本不采用。折衷的“半敏捷”行不通，因为敏捷项目依赖于许多技术和实践，这些都是成功的关键。如果省略其中一些，整个框架将无法运作。
例如，在自动化领域，Scrum 团队的目标是在每个冲刺结束时（通常为两到三周）冲刺燃尽图的剩余工作量归零，这意味着团队已完成所有计划内的任务。然而，通常情况下，工作量会保持直线，它甚至会在冲刺结束时增加。这意味着什么呢？直线意味着没有进行任何工作，而这是不太可能的。那么另一种可能性就是在当前冲刺期间新增的工作与已经完成的工作量完全相同。上升线表示增加的工作量超过了项目团队能够完成的总工作量，从而破坏了冲刺的目标。
这里的矛盾在于，冲刺计划实际上是为了精准规划团队在即将到来的冲刺中应实施的内容，因此冲刺计划一旦开始，就必须严格按照计划执行，不应该随意添加新任务。如果出现重大问题，Scrum 的解决方案应该是取消当前冲刺，重新规划并重新开始，而不那么紧急的调整应该推迟到下一个冲刺。
通常需要添加任务是因为出现了需要立即解决的重大故障，比如系统宕机。这样的理由完全可以理解，却也凸显了一个根本问题，那就是 Scrum 方法可能并不适合这项任务。譬如，在技术支持领域往往不适合采用 Scrum 方法，这个领域采用 Kanban（看板）等其他敏捷方法要更为合适。不过对于传统的项目管理来说，Kanban 就又不太合适了。
因此，当一个团队同时开展两个项目时，共同采用两种敏捷方法不失为一种可能的解决方案——即在产品开发过程中应用 Scrum，在技术支持过程中采用 Kanban。对同时参与两个项目的团队成员的任务管理模式可以按照其工作时间的分布做相应的调整。例如，一位员工通常每周有两天从事技术支持工作，那么他的工作内容会有 40% 会被 Kanban 方法管理，60% 会遵循 Scrum 方式。这样一来，开发项目就有了一定程度的规划性和可预测性，同时不必担心系统停机。
自动化测试与模拟：OT 领域的滞后性
在测试方面，自动化领域要比 IT 领域落后了 15 至 20 年。OT 的一个主要难题是其依赖于实体硬件，这些硬件可能稀缺或延期交付。虽然 IT 已将测试作为质量保证的核心方面整合到众多开发工具中，但自动化行业还缺乏成熟的自动测试和模拟系统工具。
据笔者所知，没有任何工程环境将“测试”作为一个必要环节。在 IT 领域，测试是质量保证最重要的支柱之一，这首先体现在开发工具和可用工具的数量上，而 OT 领域还远远难以望其项背。
虽然在 OT 领域已经有了进展，也有了可以用模拟系统测试模拟 PLC（可编程逻辑控制器）的初步解决方案，但它们尚未投入使用。造成这一结果的理由可能是没有时间，可能是没有预算，也可能二者都没有。
在实践中，运气好的话可以获得一个 PLC 用于测试。然而这类设备往往是最抢手的——如果硬件在交付时出现问题，PLC 总是优先被项目工程师拿走。这种优先次序恰恰说明了测试在自动化世界中的重要性。测试一般在真实环境中进行，最理想的情况是在系统停机期间进行测试或直接将测试作为系统调试的一部分，但实际上，测试大多只能在周末期间当系统间歇性运行时进行。如果测试过程不尽如人意，就会需要加班加点以锁定并解决问题，以尽快重新投入生产。
测试效率：严格评估
对测试的有效性的评判往往非常主观，因此也常常被错估。举个实践中的例子：在笔者参与的一个具体项目中，项目的 Scrum 团队被指责工作效率低于其他团队，因为该团队在测试上浪费了太多时间，而其他团队在同样的时间内完成了更多的任务。
然而，在对现状进行更详细的分析后，Scrum Master（敏捷教练）列出了有多少已完成的任务是由漏洞和其他失误引发的额外工作，结果发现其他团队平均花费了 45% 的时间来弥补错误，而被批评的团队只花费了大约 5% 的时间来修复漏洞。这说明相对于其他团队，这个团队通过测试将工作效率明显提高。因此，测试通常只是乍一看成本较高，长远看来却能带来更多的回报。
云服务：迁移须谨慎
另一个从 IT 向自动化领域辐射的影响是云服务的广泛普及，特别是涉及基于云的制造执行系统（MES）和可编程逻辑控制器（PLC）。
云资源确实能够提供几乎无限的存储空间和计算能力，但这些服务并非免费。尽管如此，这种解决方案对一些用户还是很有诱惑力。
很多公司都由于缺乏能够熟练操作本地大数据和机器学习集群的员工而倾向于将数据转移到云端。然而在使用云计算时，有几个与传统数据处理相比非常重要的成本因素需要考虑：
互联网或云连接成本：云服务的成本考虑包括连接费、存储、运营和数据传输成本，但只需简单计算一下，就会发现成本并不低。
存储和操作成本：如果一家公司需要不间断的使用计算资源，那么它从任何云提供商处租用服务器的价格都将高于其本地化部署同样配置的计算机的成本。唯一的例外可能是虚拟服务器，即多个虚拟服务器共享一个真实服务器的容量。在这种情况下，公司可以通过云计算节省开支，因为他们可以节省采购和培养经过专门培训的员工的费用。
传输成本：云提供商通常会收取数据传输费用。如果公司需要处理大量数据，传输成本也会增加。然而，很多人都忘记了，公司将数据存储在云提供商处的时间越长，更换提供商的成本就越高。如果公司将来决定更换提供商，在某些情况下费用会变得非常昂贵。这种情况今后会如何发展还有待观察：就在几周前，谷歌公司在市场营销活动中取消了云传输的传输费用，成为头条新闻。
当前，一些 IT 公司已经不堪云计算成本的重负，正在将数据中心搬回公司内部。现在也有专门为公司优化云成本的 IT 服务提供商。不过，微软等公司的一些行为也让很多企业用户更加正视云计算：几周前，微软宣布将要关闭其 Azure loT Central 平台，这让一些依赖于该平台的公司完全措手不及——他们似乎不得不在两个月内对其解决方案做部分调整。后来微软出面声称官方公告有误，其中的原因不得而知，不过这让许多公司意识到了自己对云服务提供商的依赖程度。
因此，一定要确保不要过于依赖云计算提供商的产品。只有这样，才能在类似情况下灵活应对。可以预见的是，自动化领域终究也会幡然醒悟，将数据或者至少部分数据的存储和处理从云端重新转移回公司。
结论：从 IT 中学习
当前震撼自动化世界的变革并非新鲜事；其他行业，尤其是 IT，已经经历了这些变革。自动化行业应该也必须从 IT 行业过往的教训中学习。
敏捷项目管理：为了避免代价高昂且耗时过长的错误，通常建议负责人对不同的方法论详细分析。这里也可以向 IT 顾问求助：他们可以根据公司的现状开发定制解决方案，并提供合适的培训。
测试：自动化领域在这方面还有很长的路要走。自动化设备制造商必须提供适当的解决方案。此外，与信息技术领域一样，开放源代码也是一种选择。不过，自动化行业需要更主动一些，利用开源倡议共同开发对所有参与者都有益的解决方案——这种策略将大大减轻开发专有系统的高昂成本。
