今天，很多企业开始宣称“软件定义自动化”、“软件定义制造业”。其实，早在2013年，美国著名的媒体连线（Wired）就以更为宏大的叙事制造了“Software Define X”这个词。当然更早的是斯坦福大学在2006年就提出了“Software Define Network-软件定义网络”，然后“软件定义汽车”等各种概念就出来了，今天人们开始高呼“软件定义制造”、“软件定义自动化”。软件定义是有意义的—因为，它的核心要旨在于用软件来应对变化的世界。

记得去年传动网苏姐采访肖博，当时肖博说了句“自动化以后是个吃软饭的行业”—觉得这是个好话题，一直试图去描述这个话题。今天，大家说软件定义制造、软件定义自动化，其实，通俗地说，就是我们自动化行业越来越多靠软件赢得未来的生存。

实际上，自动化早已是一个由RTOS、行业工艺软件、网络连接、HMI、AI、标准化如PLCopen构成的软件系统。而图1则是在十多年前就绘制的一个关于“软件价值”体系的描述。

图1-自动化的软件价值体系

那个时候，我们绘制这个的核心叙事在于“软件构成了核心竞争力”—但这个叙事是给用户来说明，他们的机器中差异化竞争力来自软件，这里核心在“工艺”。也就是之前我和“工业软件”群经常谈到的一个话题，即，除了看得到那些以产品形式存在的工业软件，还有大量尚未受到足够重视的。即，隐藏在嵌入式系统里，每台机器里的软件，以及生成这些软件的软件。自动化行业里，平台工具软件如Automation Studio、Portal、Logix、EcoStructure、TwinCAT等。

之所以软件定义，是因为VUCA这个词所描述的世界正在悄然发生，且更加加剧—以消费世界为例，它的各个维度的改变正在给制造业带来极大的难题—在理想状态下，企业自然希望通过极致的规模化来摊销成本，进而获得极致的成本优势。如图2，VUCA带来了复杂性，需要得到有效的解决，数字化被赋予了重任，这个也就以各种软件的形式来实现。

图2-VUCA时代数字化的意义

在一个产品需求更为复杂的时代，让制造企业，尤其是那些代工企业，他们会必须面对众多的产品需求，这些需求还特别的碎片化。并且，还需求特别的着急，因为人们习惯了明天就能收到货，如果是后天就可能放弃购买。

软件定义制造的不断演进

1.运动控制实现产品变化的生产

所以，一种灵活的、可重配置的产线是迫切的需求—这个通过传统的机械调整，就会非常的慢，且成本高昂。因此，制造业的自动化一直在寻找更为妥善的解决问题的办法。这样，就产生了灵活的机器来改变配置，机器的控制+伺服控制就成为了必然的选择。在30年前，在机器里采用伺服电机，是为了实现更高的加工精度和速度，但在很多机器上，伺服电机并不在同步时工作，而是在机器换单的时候，对机器进行调整。例如，裁切刀的刀辊换成伺服驱动，这样，裁切尺寸变化的时候仅需参数设置即可执行新的裁切任务—当然，这里的伺服电机本身是作为一个同步轴的，它会跟随被裁切纸张的尺寸。但是，在印刷机的斜拉版、压印力调节、机械的机构调节，在瓦楞纸的换刀、书刊胶装/骑马订等场景里，伺服电机仅在需要更换规格时动作。然后不参与同步的电子齿轮、电子凸轮等动作—这里大量伺服电机的使用就是为了灵活的应对产品规格的变化。

同时，为了实现这些机械加工的效率，又实现了连线生产，像饮料的吹灌旋贴，开清棉、长流程的离散制造都在实现这样的连线，中间更多使用机器人、AGV是为了提高效率。因为，必须把换单造成的那些时间损失都得弥补过来—这个时候就需要通过网络来把整个机器连接起来，而不是用硬接线的方式来实现启动同步。通信就成为了实时控制的关键一环，而这些机器可以通过这种统一的通信连接实现同步，在软件层，对这些参数的上下行进行读写就成为了机器配置的关键。

图3-连线生产，从印刷到书刊输出

运动控制的问题是它主要在机器内，例如定位主要解决单点的问题，同步也仅解决多个轴的关系，但它无法解决在机器和机器之间的输送这个难题。

磁悬浮输送解决机器-机器间的可定义性

进一步的，人们发现控制主机实现了软件定义的任务编排，网络实现了数据流动和交互的接口，但机械的输送还是个难题—当年，CIMS/FMS这些其实就因为这个原因，无法被有效的运行。因此，才产生了柔性输送系统，即，现在被称为磁悬浮输送的系统，它打通了最后一个难以被“软件定义”的环节。通过“电-磁”转换，将传输系统转为可以被软件定义的“单件流”、“连续流”—这符合精益对于产线的编排需求，因为它可以实现排队、配合加工等，可以让物料流动、配合加工成为一个被软件快速可重配置的形式。这进一步推进了软件定义制造的可能，如图3所示。

图4-运动控制从一维增加到六维

因此，伺服电机、机器人、磁悬浮输送解决了产线中的局部修改，以及在机器间物料流的解决。

通信-解决协作中的信息流

在软件层面，人们实现了加工过程的状态建模来实现生产的重组—用软件的“编排”来实现生产线的重组。之所以，采用状态模型，就是因为它可以被逻辑编程。像PackML、JDF、ISA-95、IEC61850、Unimat等垂直行业的规范，就是为了能够对这些生产过程进行统一的行规设计—这样就可以快速的参数下发。而新的MTP则是针对自动化系统的统一规范，来实现工厂的管理层任务解析并下发—可以通过OPC UA来实现这些通信的连接与数据的封装，提供了一个统一的框架。

图5-PackML协作横向与纵向的机器联网

物理建模与AI-解决知识的复用问题

对于制造业，如果每次都要对一个任务进行编程，或者对于一些知识都要重新组织，那么工作量还是很大的。为了把知识进行有效的复用，工程师们就开始想在知识封装上下点功夫。

在知识的挖掘的几个典型范式里，人们经常把远古时代的科学发现定义为人的天赋来实现的。而基于笛卡尔的方法论以及牛顿、莱布尼兹这些伟大科学家在第二个阶段，人们开始将物理的公式作为解决问题的思路。而在计算机出现后，这些物理模型的验算就成为了计算机要去干的事。但是，这种基于物理知识的毕竟是有限的，它需要先验知识和已有的数据积累，才能更为精准的模型。而这无法满足越来越复杂的世界对于知识的苛求。那么，新的范式，基于AI就成为了一个必然的选择。

图6-MapleSim的张力控制建模与仿真

再进一步，人们又发现这些系统由于过于复杂，且存在很多“不可见的深渊”—即，在复杂的系统里，他们会产生效率无法被最优的问题。因为，复杂系统，它的路径规划会形成非常多的组合，这无法被人用公式来计算—因为，这是一个“陷阱”，就是被窝在系统里的能力，它无法被有效的发掘。包括引发生产产品品质的干扰因素，例如相关性的、随机误差造成的无法被有效的观测和梳理。这就使得人们寻求通过“数据驱动的建模”来挖掘这些背后的规律。产生了对人工智能的需求—而人工智能，则又是一个软件。

软件的模块化-实现知识复用

用高级语言封装算法，且构建出“高内聚、低耦合”的应用模块，然后让这些模块快速重组，来搭建整个机器的应用程序。这个就是要用模块化的软件开发来实现—但是，自动化它所面对的机电又是一个高耦合的领域，因此，基于物理建模的方法在计算机出现后就开始被大量使用。

图7-软件工程的模块化思想

在软件工程领域，著名的工程师Fredric在70年代，觉得软件正在陷入泥潭—后来随着模块化技术的普及，软件的危机在被解决。在制造业同样如此，人们通过模块化来实现机器的快速软件重组。

AIGC编程-让工程迈入更为灵活的时代

随着系统的复杂性不断提高，我们要面对各种各样的算法、AI分析、界面等，程序会变得越来越复杂。传统的编程即使是增强模块化，仍然不够，因为它的门槛也比较高，尤其是机电工程领域。

AIGC编程就成为了一个潜在的方法，因为，它会继续使用原有的知识、模块来为工程师快速搭建架构，进行“按需”软件设计。尽管它目前尚不是很完善，这里，尤其是指制造领域的机器和产下，但，如果能够定义统一的规范进行约束，那么，相信它的准度、深度进一步发展。其可用性会更高。

据此发展下去，软件未来自动生成软件，自动化工程师则将成为一个顾问，或者一个“桥梁”，它连接用户端模糊、不确切的需求，以及组织复杂的机电工艺之间的“关联”与“架构”。即，未来需要的是机电、工艺系统的“架构师”，而不是“Coder”。

基于建模的开发与模型交互

但是，这个还不够，毕竟，在机电领域里，不如纯软件领域那么方便。太过于碎片化，因此，采用物理仿真的自动代码生成也成为了一种办法-Mathworks就在2008年推出了为自动化领域的工程师们开发的SimulinkPLC,通过C代码的生成来实现模块的生成。Modelica组织则试图在不同的机械软件间进行模型的数据互换，开发了FMU/FMI接口，这个不仅在纯的CAD/CAE软件之间，也在物理建模和自动化软件间进行了这样的接口。当然，后续OPC UA会接续这个模型，使得其更为广泛的连接到不仅基于模型工程（MBE）的领域，如云端系统、垂直领域的软件之间的接口数据统一。

因此，我们可以看到，要实现“软件定义制造”。想吃上软饭，这个链条里的基础操作系统、硬件的嵌入式软件、实时网络到多业务流数据的汇集、行业规范、数字化设计软件、开发工具、AI、云端，这一切都需要进行有效的组织，形成有机整体，这个事情才能真正被实现。

软件定义制造的未来的难题？

软件定义制造，就目前看，还有很多现实的难题需要突破。真正想吃上软饭，还是需要解决一些关键的问题，并非仅仅技术的。

谁为这些软件买单？

软件必须成为一种有效的盈利模式，硬件可以统一设计制造，由OEM/ODM厂商来代工生产。而每个企业的竞争力将由是否能够解决特定问题，实现以软件、服务为主的盈利。

要真正实现“软件定义制造”，就必须确定软件的价值，并将软件成为一种严格封装的，知识产权边界明晰的产品。且，能够独立的运行在跨平台的系统上。

要实现真正的软件定义制造，有几个方面必须做到：

1).软件的独立性，为了解决这个问题，在IT业界采用了包括容器技术、Docker等各种方案，这些方案对于IT系统架构在统一的硬件上而言，相对比较容易。因为，纯软件行业，他们的规范性是足够的—而在制造业，这个软件的标准实现就由于过于强耦合的硬件、操作系统，而难以真正做到隔离。

因此，未来的自动化系统，它应该是操作系统更为通用，例如采用Linux，RT-Linux，且实现与开发环境的剥离。应用软件可以脱离厂商的硬件，在通用的硬件上来实现部署，例如你可以把它部署在嵌入式系统，也可以在PC、服务器、云端。

2).软件必须是可以被独立销售的

这个环境似乎目前还不能看到，只是有些端倪，毕竟，长期依靠硬件吃饭的行业，真的把软件剥离出来，会伤害既得利益者的盈利能力。这是IT业界进入制造业一直试图去颠覆的，尽管这个步伐看上去很难。这也是制造业的特殊环境—因为，可靠性、稳定性的需求是基础需求。

但是，这并非不可完全解决，即，纯粹的硬件厂商+IT的能力，因此，这个时候，自动化和这些试图进入制造现场进行颠覆的人就产生了冲突。那么，这就会看谁更能坚决的带来商业价值。但，作为自动化领域的厂商必须去开放的接受这个事实，依靠硬件或软硬结合的方式肯定是个能吃5-10年的，至于再过10年后，会发展成什么样，就不好说了。

3).统一标准与规范的建立

为了实现各个层级的软件的南北向数据、东西向数据的打通，统一规范是必须的。这个规范究竟是什么？是OPC UA吗？目前这是个选择，但也未必就是唯一的选择，当然，OPC UA可以把各种选择都给纳入它的框架之下。因为，它与IT那些标准规范具有先天的工程思维。

可能制造业会不同，相对比较严格的—现在的很多标准尚未被有效的使用，就是因为在实际的“智能连接”上需求尚未真正达到一致。因此，很多概念仅在前沿的企业那里会看到雏形，或者试验型产线。

在各个软件间形成快速的接口数据交互、以及程序间的交互—就像MTP，如果自动化厂商都遵循MTP，那么，当产线上的数据进行了修改，它也可以被下发给不同的PLC，并且，写入变量中，或自动读取。如果AIGC编程也能按照这个接口标准来定义对象、数据格式，那么是否意味着，即使是它生成的程序，也可以被PLC直接读取呢？这个约束机制，本身就是一个探索过程，但，用“规则”约束自动编程系统。在可行性上可以进行探索—软件自动构造的方法，既可以通过系统建模、语言建模、软件接口、模型接口—至于那种方法更好，可能通过多个接口和机制的联合行动，大家也是可以做到最终的交互。

图8-MTP用于在氢电解槽系统里协作

在图这个架构里，电解槽相关的水处理、变流器、压缩机、电解槽、干燥系统、存储系统之间会形成一个整体。当系统需要更新数据和升级配方，则会统一的数据下发，以实现远程的升级。

这些工具的最佳组合—会被探索出来，例如，在通信接口方面，模型交互方面，其实，不必完全构造，而是让系统学会各个接口规范，并让程序按照这个接口来实现—反倒，这个可能对于推理强的AI更容易掌控局面。因为，我们要做的太复杂的时候，人反倒是难以实现的—但，人可以为机器提供校验，它还会学会你的校验过程。

4).自动化还得是个咨询公司

前面提到，如果我们希望做到软件定义制造，而又有AIGC编程、模型交互、模块化设计，凡此种种。我们也说了，这个能够让机器和系统更快的自动构造。而这个时候，你会发现，最为重要的不再是编程，设计，而是“架构”，即，用户的需求到实现之间的这个桥梁。

将用户需求翻译为机器可实现，这并非易事。因为，人的需求往往是模糊，不确定的，且存在隐藏的、没有被发现的—甚至提出需求的人自己也不清楚。

那么，这个时候，其实特别需要具有“咨询顾问”能力的工程师来解决这个问题。即，它能够梳理需求的逻辑，并能对需求进行精确的定位，并且，能够关联机械设计、电气、工艺、AI分析之间的关系，它能够把它表达为Prompt去给AI系统。让它去实现，然后还能给它的实现进行修正。

这可能不是一个工程师能完成的，而是一个由多个人和跨企业专家构成的团队，但这个团队需要具有咨询顾问的提问、分析能力—它不止于跨学科，还跨职能去实现项目的组织。

5).知识产权保护

要想真正实现软件定义制造，那么，在知识产权保护方面，就必须有非常强的机制。当然，这种机制不一定是法律的机制，也可以是技术的实现方法，配合法律法规。

这里也会牵扯到非常多的权利问题，即，数据权属问题、知识的归属，以及复制的权限。包括信息安全保护机制确保数据资产的安全。

所以，这个吃软饭，能成为一种稳定的饭票，还需要很长的时间发展。从目前来看，这个方向有端倪，但尚未到真正意义“软件定义制造”。

来源：微信号 说东道西