自动化视角谈谈边缘计算

显示全部楼层 · 2024-9-13 08:50:33

最近，与上海交通大学电院戴文斌博士、上海自动化仪表院（SIPAI）教授级高级工程师/PLCopen原主席彭瑜老先生共同编写的《边缘计算使能工业互联网》新书出版。虽在其中内容不多，忝列作者之席。但也想借此文来谈谈自己对于“边缘计算”的渐近认知过程和对工业互联网的粗浅看法。

“边缘计算”-互联网进入制造业的通道

约是在2016年夏天认识了华为的Richard兄，当时他是在华为企业网络业务领域担任边缘计算（Edge Computing）的首席架构师并与团队推进ECC联盟的成立。ECC还邀请我担任专家委员会专家。在当时，边缘计算也是个新兴概念。因此对我这个来自OT(这个OT词也是这个时候用到-原来OT是一个相对IT的叫法)，初期还是有些迷惑的-就是这个边缘计算究竟指的是什么？在参加ECC后有幸认识很多来自ICT厂商的专家。有点模糊的在于—这个与自动化行业的DCS/SCADA/PLC干的事情大抵相当。但是，ICT厂商是希望通过“通用平台”来解决这些问题。也即，将原来的采集、控制、显示、计算、管理任务放在通用的硬件或者标准网络架构上，从这个角度来说，ICT厂商进入制造业现场，希望通过一个通用平台，而非自动化行业的平台来介入。从这个意义来说，它是当时“互联网经济”思维的延伸，即，借助于无所不在的通用计算资源，将其复用到制造业现场，进而实现成本的低廉—互联网的扩散正是依仗边际成本递减的效应来实现的。

当然，这必须基于一个完整的生态系统，即，来自ICT厂商的软硬件架构，以及工业领域的垂直行业应用集成，打通南向北向，包括东西向（这是最近才发现的词）数据链路，以及制定有效的规范与接口。才能用既有资源基础上，实现这个大的集成。就思想而言，这与RAMI 4.0/IIRA其实都是一样的。边缘计算联盟ECC的作用也就在构建这样的生态系统，以推进制造业现场的工业边缘计算。

记得在18年夏天，Richard兄说介绍一位厉害的角色给我。在上海虹桥天地，见到了戴文斌博士。在交大电院做老师，但他又同时是IEC61499国际标委会委员，对于IEC61499不甚明了。听了戴老师热情洋溢的介绍后（充满了对自己所从事工作的热爱）。以我初浅的理解来说，自动化系统是基于集中式控制架构，这是因为闭环控制的需求必须是构成一个整体。而对于边缘计算，即，计算性任务，则需要一个更高一层，在机器的上面一层的任务调度，牵扯到策略、优化问题。它就像PLCopen的IEC61131-3对控制器的编程一样，在计算这一层，其实，也是需要一个“编程”的，以及运行这个开发与任务的操作系统。而Richard非常赞赏这个IEC61499平台架构，他认为边缘计算不仅局限于网关等场景，即通过一个网关融合网络通信、计算和控制，而是认为边缘计算更大的价值在于分布式，觉得IEC61499是个可以证明边缘计算价值的好东西。

虽然不是特别了解IEC61499，但是直接的理解的话，我想它采用了事件驱动方式来进行状态逻辑的编程，数据与事件分离，可以采用SoA的方式为应用提供支持。它可以实现在各个设备之间的连接，而其所调用的功能可以在IEC61131-3或采用C/C++、Java所编的算法中，它主要的作用在于以状态驱动的逻辑来调度各个控制任务。

究竟何为“边缘计算”

之前都是和自动化行业打交道，自从进入边缘计算圈，以及在工业互联网火热的时段里，结识了很多来自ICT企业的专家。包括像华为、阿里、ARM、Intel、微软等等专家。我比较深的印象就是，ICT厂商对于制造业的期待比较高，但对于如何落地，产业的需求，以及技术的场景匹配这个问题会比较难以理解。

记得2017年左右，林雪萍老师组织大家出了本《智能制造词条》的书，还让我写了篇关于“边缘计算”的词条。以我当时与Richard兄交流的“控制基于信号，而计算基于信息”来理解。前段时间有朋友问及“为什么控制要集中式架构？”—我回答他“因为，控制系统它是一个闭环控制，它需要把所有变量采样，集中汇集后再进行策略的调整，并构成一个循环（Close Loop），这决定了它必然是集中式的架构”。控制的任务都是基于“等时同步”的，采用信号采样负反馈，比较实际的信号差，然后去控制输出，它是基于信号的系统。而计算任务它是在全局层面，即，机器的全局数据采集，是更大的闭环，但它吃的是信息，而不是直接的信号。另外，就是控制解决的是系统纠偏、稳定的输出、控制精度等问题。而计算则要考虑的是“调度、策略、优化”这几类问题—这些问题本身不是需要全局的数据采集，然后进行信息级的计算—但是，边缘计算的关键又在于它也是需要闭环的。但是，相对于控制而言，它的时间粒度（又是IT用语）比较大，控制通常会在μS级，而边缘计算放在100mS这个级别。

那么，这个边缘计算，其实是要实现“集中控制与分布式计算的统一”。当然，再另一个视角，例如对于DCS的控制而言，它是分布式控制。但是，它实际上也是集中式管理、分布式控制，这里的分布式控制是经过“解耦”的。DCS在也可以被理解为边缘计算—只不过，OT从来没有“边缘计算”这个词。而DCS通常被ICT厂商理解为“专用”系统，而非通用软硬件架构。但是，不管怎么说，这也是为什么后来与IT厂商交流的时候，我就认为他们所讲到的边缘计算，在自动化系统里属于“早已有之”。因此，边缘计算这个新兴概念的关键在于“通用”平台，包括采用Intel X86、ARM、GPU这些通用的硬件和Windows/Linux这样的软件平台来解决问题，当然，也包括采用云边融合的“云计算”资源。最大限度利用开放世界的资源，对于“开放自动化”的实现企业而言，这倒也不难理解。

对于边缘计算的推动，Richard兄花费了大量的经理，也大量接触了自动化厂商、终端用户后。他更是清楚的意识到制造业最大的问题在于硬件与软件的强耦合关系—这里的硬件不仅指自动化系统，也包括机器的物理变量，声、光、电、热、流体等。而OT端最为重要的是行业价值，必须得有更为深远的软件积累—这可能是我给Richard兄最大的贡献。大概那个时候，Richard兄会更为清晰，中国基础工业软件的“匮乏”-我想这对于后来Richard兄更多从事在这方面的工作是有影响的，包括在垂直业务场景里的基础机理模型、数据模型。同时，与戴老师，我们三个人也聚过几次，每次都会讨论起这些架构，应用、行业，也的确是非常高密度的让我成为了跨界的专家。

后来，我们三个一起拜访了彭瑜老师，彭瑜老师作为自动化业界前辈，虽年高80有余，但仍保持学习新知识的状态。他非常高兴看到像Richard兄跨界来支持制造业，而戴老师年轻有为推动整个架构的设计与商业化推进。当2019年机工社的王颖老师觉得边缘计算是个好题材，我推荐了Richard作为第一作者，并愿意自己写一部分内容。后来Richard事务繁忙，王老师追着我来写，我成功将火力转移给了戴老师（他毕竟在大学里算是中立组织，再说他也是IEC61499的参与者）。然后和彭瑜老师重新组队来写这本书。当然，回头一看，我们三个成为了OT人的视角结合IT来看“边缘计算”的作者。彭瑜老师年高80有余，也还积极的学习并编写了大部分的内容，我想他也是对于我们这些年轻人的厚爱，愿意为我们打下书的权威专家这个基础。

IT与OT实现方法的差异

但是，作为自动化领域的从业人员，早先对于ICT厂商讲的这个边缘计算比较困惑的地方在于“那究竟它与我们的SCADA+DCS、以及我们在控制理论里讲到的参数寻优、路径规划有何不同”—这是个难以回答的问题。因为，这件事情同时也给我了启发“究竟IT和OT的思维方式差异在哪里？”—包括林诗万博士，他是IIC的IIRA首席架构师，和他交流了很久，后来倒是他自己开的玩笑把我提醒了“我们就是手里拿着榔头，到处找钉子”—IT是“自上而下”的思维方式，而OT则是“自下而上”的设计。也即，在这个阶段，我明白了，关于所谓的边缘计算，IT和OT厂商其实都在往前走。但是，由于思维方式的差异，使得这个问题变成了，IT在找场景，而OT就在场景中，这就像“不识庐山真面目，只缘身在此山中”。Richard经过大量和自动化企业打交道后，也意识到了这个边缘计算必须得有垂直行业场景，以创造真正的商业价值。

其实，这也是为什么自动化行业最近一些年头都开始关注数字化平台架构。这些架构的共同目的是将IT与OT融合。将计算任务和控制任务在统一的硬件架构下集成，并通过平台内部的接口实现互操作。当然，自动化厂商可能不大称为“工业互联网”而更愿意称为“工业物联网”或者。其实，这也预示着自动化也在向制造业的IT应用领域延伸。相反，其实，越来越多的人也感受到了，IT再向OT的领域延伸，这包括像微软、腾讯、阿里等，他们实际上已经大量招募了工业领域的专家。

那时候，我会觉得这个边缘计算会成为“IT与OT的战场”，记得2016年在一次会议上和当时友商的标准专家华老师聊起来说打算写一篇文章“IT与OT必有一战，战场就在边缘计算”。华老师说别惹事，现在回头想想，咱们工业的人比较低调，不大原因挑起事端。但是，在来自AI领域的朋友就会说“我们这行互相攻击，那是家常便饭，你们还是太保守—其实，吵吵更健康”。当然，我们“求同存异”是一贯的风格。

在《边缘计算使能工业互联网》一书中，我也仅是写了不大多的几个小节，谈到了OPCUA over TSN的规约，以及边缘计算中的数字孪生的理解—当然，本文倒不想谈及此话题，之前也写了比较多。主要是想谈谈整个对于边缘计算的理解。完全基于OT视角来看，而非IT视角。

边缘架构的协作如何被实现？

那么，这个边缘架构，就会牵扯到在上面一层的编排问题，而IEC61499基于事件和数据分离的模式，来把整个模块单元的子任务进行封装，例如机器和产线的机构作为一个模块，被IEC61499的逻辑调度，这个调度可以基于状态的变化。而对于这个下面的机器模块，则采用IEC61131-3的编程来实现。

D同学是OPC UA的开发者（虽然经常也会出现在我的文章，是因为他比较低调），他对于“协作”的理解还是比较深刻的。结合之前阅读彭瑜老师对PackML的几篇文章给我的启发。而这个就与规约紧密相关，之前我写过一篇文章谈到这个话题，不妨再讨论一下：

1.关于对象建模的问题

对于PackML、AQDEF、SEMI/GEM等规约，他们都已经提供了制造现场的建模问题，即，对于对象，如何标记其关键所需信息的问题。

他们都把这个产线按照最基本的组件，如一个传感器、一个电机进行了组件级的建模。在这个组件建模后，它们以几个组件构成的闭环控制，形成一个独立的功能单元，例如放卷、裁切、卷绕等。第三个层面就是由这些功能单元构成一个机器，例如印刷里的制版、胶印、折页、配页、胶装、切书中的某一个机器的独立完整功能。

图2:Automation ML中对于CAE相关对象信息的建模

除了这些用于生产环节，像CAE类信息的交互，也可以通过图2的Automation ML进行信息建模与交互。

2.关于信息的传递问题

在整个从组件-功能单元-机器的这个过程中，需要传递机器的基本参数（如尺寸规格、编号等）、动态运行参数等，这些信息需要通过通信规约来标准化定义。这些信息以信息标签的形式被进行了标记传输，例如图3中PackML中，像上行命令也会以ComandTags的方式来下发，而上行机器状态和管理所需信息则以StatusTags和AdminTags的方式上传。

图3-PackML中对于信息的标签

3.协作问题

协作包括了在两个层面的协作，一个常说的水平集成，即，机器间的交互，其次就是机器与管理系统间的协作。通过状态（Status）空间的切换，机器模块和功能单元携带了信息，进行相互之间的交互逻辑。这个机制在PLCopen运动控制、PackML、SEMI GEM、JDF(印刷行业的作业定义格式)等，都是相同的。

图4-MTP和PackML的状态机机制实现协作的思想

MTP是另一个用于实现边缘层协作的规约，它和PackML具有相同的思想，即，通过状态切换来实现协作的大逻辑实现，如图，MTP的状态机切换与PackML具有相似之处，如图4,。也即，实现边缘侧的连接，可以由MTP这样的状态驱动机制来实现。

4.边缘计算-更大的闭环协作

在底层机器上，是有一个大的“闭环控制”，但是，整个车间、工厂，它仍然需要一个闭环控制—而这个循环它与机器控制的循环不同，它的目标导向是“质量、成本”，那么它需要考量的不是信号控制的响应问题、精度问题—但是，这些问题又和质量、成本有紧密的耦合问题。因此，MES/ERP系统它需要获得现场信息来进行状态的反馈，即，质量是否达标，那么，它的分析和改善策略就需要调整，然后还要下发去执行。

经过这几步，我们慢慢明白了边缘计算，它实际上必须和OT端的数据反馈紧密结合。

为什么边缘计算更多需要智能算法？

这里就会出现问题，因为计算他针对的任务是品质、成本，而这些问题它的时间采样并不需要很快，而且采样精度也比较难以精准的数字衡量。包括牵扯到了复杂的现场耦合关系，使得其大模型难以像“物理建模”那么容易。采用常规的统计或者策略性模型也是很有必要的，如果对于学习、隐性的知识也同样需要学习的方式来获得规律。

图5-机器与产线的不同层级任务

图5中列出了从单机到整线的架构-任务视角来看，在提升效率和个性化方面，需要更多的智能技术来实现支撑。传统的物理建模已经解决到了某个极限阶段-当然，这只是针对较为领先的制造业而言。

这就使得在边缘侧所需的任务，具有与控制不同的—当然了，如果看看现代控制理论的大咖研究的对象，你会发现自动化本身也是需要很多数据驱动（Data-Driven）建模的问题。

前些时日在线听了冯恩波博士关于AI应用的讲座，我觉得其中一个论断也是合理的。对于大部分的制造业现场问题，70-80%采用物理建模来解决，但，还剩下20%的问题就是难以被物理建模来解决的。而“胜负手”往往又在这个剩下的20%的问题—冯博士同时也提到采用数据建模是解决“相关性”的问题，那么这里也会遵循20/80的理论，即，相关性较强的20%问题可能是强相关，影响结果最大，因此，必须在开发中发现这“强相关”部分的问题—就可以解决大部分问题。这也算是一种需要“洞见”的。

边缘计算的关键实现路径

在OT的视角，对于边缘计算的理解仍然是作为一种实现方法和路径-它可以被理解为实现整个工业互联（不特指工业互联网概念），以达到智能制造架构的途径。OT视角仍然还是要回到制造的核心任务。任何技术方法与实现，若不能改善品质、成本、交付能力的话，那么对于制造业来说就会不具有现实意义。而对于企业而言，工具具有“同质性”，究竟什么是企业的核心价值-仍然在于如何发挥这些技术实现的自身功夫。当然，对于边缘计算，采用开放世界的资源，这个路径就整个制造业的演进史而言，必须是要关注的：

1.通信规约问题

对于工业问题，尤其是复杂的长流程制造业，能否实现统一通信规约是第一要突破的难题。最初接触一些工业互联网企业，他们的主要痛苦大概就是问“你们现场究竟有多少种总线？”…我心里想，从网络的种类来说，IEC61158现在都已经到了“IEC61158-28”了。至于在此基础产生的各种通信规约，以及到了垂直行业的规约像PackML、AQDEF、JDF、SEMI、MTConnect、AutomationML等，这就不胜枚举了，毕竟我们了解的行业还是不多，大的行业还可以细分小的，就像印刷还分为凹版、柔版和胶印，他们之间可没有什么关系。

对于机器的集中控制而言，实时以太网已经被广泛采用，尽管TSN尚未被广泛采用-但OPC UA FX致力于将其在有线网络成为标准，并将5G/Wi-Fi6/7作为无线方式的通信标准。但，对于边缘计算架构来说，最为重要的还是在北向和南向数据方面的规约—因为，连接各个模块化的机器则需要统一规约。在这方面，包括像Automation ML、MTP这些都会去扮演这个角色（对他们的关系和异同后续再分析）。

图6-Automation ML关于自动化系统的对象模型

Automation ML则建立了自动化工程的规约，以使得数字化设计、边缘层系统与自动化系统间的这种工程数据交互的结构，这个结构带来的好处在于“简化”工程升级，对于用户而言，它不用担心谁家的控制系统。

很多人都说，这些OT企业都搞这么多总线是为了形成壁垒—但就实而论，可能有失公允。前面提到，OT解决问题它是按照先有问题，再封装为标准化的，因此，从技术上来说，现场总线当时可能只是为了解决这个具体的问题才产生的，或者这一类问题，比如，像仪表类的FF他们就不大强调实时性，但会考虑距离和防爆的要求，但是在离散制造业的这个就必须考虑实时性。因此，这种差异其实很容易理解。

因此，要解决这些问题，从网络底层L1/L2到应用层架构的统一还是有必要的。OPC UA其实算是一个缺乏对手的规约，虽然也有DDS、oneM2M、MQTT，但相对来说，OPC UA还是相对比较靠谱的-当然，戴老师认为这个协议有点“重”，并且缺乏一定的“可视化”—这也是需要在开发中解决的问题。另一个问题就是关于底层网络的问题，APL还是SPE，这个主要考虑的是流程工业对于防爆的要求，SPE也是有支持者，另外就是TSN技术。

2.模型运行与开发平台问题

对于工业而言，最重要的事情是“工程实现”的经济性问题，对于传统集中控制采用PLCopen这个比较容易理解，但对于如何在边缘侧制定一个类似于PLCopen的统一编排语言也是必需的—如果没有PLCopen是否可以编程？

当然可以，只不过，就是会出现公司内部的模块不统一，带来非常多的麻烦。而对于边缘计算或工业互联网而言，没有一个编排的平台可以吗？自然是可以的，你用Java、Python、Docker或.Net是否可以？没有人说不行。

当然，戴老师给我讲了IEC61499，我只好高屋建瓴的理解为这样的意义—即，为边缘侧任务的规划和编程、测试构建一个平台语言。

这也是国内做各种工业互联网的公司号称快速发展的第二个难题，就是没有统一的、自主的开发语言，就把每个工业互联网应用变成了“项目”。这就会导致成为非常狭窄的、应用范围难以扩展的，业务以项目驱动的。而对于自动化领域，经过数十年的积累，反倒是以“可复制”业务为导向，不大愿意涉足这种项目型的“劳动密集型”产业—从各个工业互联网企业的人均营收来看，其实还是项目型市场。

在这个发展中，各个企业应该还是要清晰自己的定位，但是，相信最终会划分为平台工具型、垂直应用型。现在是每个企业都试图建立平台，但是，这种拼凑起来的技术不能称为平台，真正的平台是要经历各个领域的打磨才能具有易用性。而垂直行业则根据这些将自己的应用封装起来。

大的企业是最好不要介入到垂直应用，但可以商业孵化的模式来培养生态伙伴。

3.垂直行业应用的知识积累问题

关于边缘计算的应用场景，其实，边缘问题通常都是与全局性问题相关，它不是在局部寻找最优，因为，局部最优是机器控制已经实现的。或者局部的最优有时候也需要全局观测。

但是，对于制造业而言，纯粹的边缘计算也并不存在，毕竟，它是一个完整的系统，紧密相关。IT系统与OT系统，核心都是要为用户解决问题，如图7所示—对于制造业的转型而言，就其本质而言，还是要回归到自主知识产权的掌握，架构是架构、工具是工具、平台就是平台。真正的价值，仍旧来自于Know-How的封装，而这对于制造业来说-才是竞争力的核心。

通信的建模也是为了降低工程成本，而对于控制而言，机理建模在过去一直扮演重要角色，而在设备连接后，在边缘侧的调度和优化任务则必须基于数据的交互、协作来实现。AI应用于边缘计算，也是采用数据建模的问题—这里最为重要的仍然是需要“行业见地”—对于那些“相关性”的判断，仍然是需要依赖于人的经验和智慧—这就是工程师的价值，在任何时候，一切的竞争归根结底还是人的竞争。

图7-一切归于模型

边缘计算也罢、雾计算、云计算或者网格计算…这世界上概念千千万，但，我们需要一个共识，即，我们一切都是为了“高品质”的制造业，为用户提供更好的产品、更好的服务—技术服务于我们的愿景。在任何时候，我们都不应该忘记“我们究竟走向哪里？”。沉湎于概念没有意义，纠缠于既往的成功也没有意义，仰望星空、脚踏实地—且行且珍惜。

在线交流海报

这文章也写了好久了，感谢机工出版社王颖组织“新书发布会”，今天晚上赶着把这个稿子写完，顺便把这个海报贴在下面，晚上且听各位专家分享对边缘计算的理解。

都是老朋友！欢迎来叙...。

[其他] 自动化视角谈谈边缘计算

本帖子中包含更多资源