其实，早在2013年，美国著名的媒体连线（Wired）就以更为宏大的叙事制造了“Software Define X”这个词。当然更早的有斯坦福大学在2006年提出的“Software Define Network软件定义网络”，然后，“软件定义汽车”等各种概念就陆续出现了。今天，人们开始高呼“软件定义制造”、“软件定义自动化”——软件定义是有意义的，因为，它的核心要旨在于用软件来应对变化的世界。（原文转载自：“说东道西”微信公众号）

今天，大家说的：软件定义制造、软件定义自动化，其实，通俗地说，就是我们自动化行业越来越多靠软件来赢得未来的生存空间。实际上，自动化早已是一个由RTOS、行业工艺软件、网络连接、HMI、AI、标准化如PLCopen构成的软件系统，而图1则是在十多年前就绘制出的一个关于“软件价值”体系的描述。
那个时候，我们绘制图1的核心叙事在于“软件构成了核心竞争力”——但这个叙事是给用户说明用的，他们机器中的差异化竞争力来自软件，这里的核心在“工艺”。这也就是之前我和“工业软件”群经常谈到的一个话题，即， 除了看得到那些以产品形式存在的工业软件之外，还有大量尚未受到足够重视的议题，那就是隐藏在嵌入式系统里，每台机器里的软件，以及生成这些软件的软件，在自动化行业里，平台工具软件如Automation Studio、Portal、Logix、 EcoStructure、TwinCAT等。
之所以软件定义，是因为VUCA这个词所描述的世界正在悄然发生，且更加加剧——以消费世界为例，它的各个维度的改变正在给制造业带来极大的难题——在理想状态下，企业自然希望通过极致的规模化来摊销成本，进而获得极致的成本优势。如图2中，VUCA带来了复杂性，需要得到有效的解决，数字化被赋予了重任，这也就以各种软件的形式来实现。
在一个产品需求更为复杂的时代，制造企业尤其是那些代工企业，他们必须要面对众多的产品需求，而且这些需求特别的碎片化，并且，需求时间特别的紧急，因为人们习惯了明天就能收到货，如果是后天就可能会放弃购买。

软件定义制造的不断演进
(1)运动控制实现产品变化的生产
所以，一种灵活的、可重配置的产线是迫切的需求 ——如果通过传统的机械调整，就会非常得慢，且成本高昂。因此，制造业的自动化一直在寻找更为妥善的解决问题的办法。这样，就产生了灵活的机器来改变配置，机器的控制+伺服控制就成为了必然的选择。30年前，在机器里采用伺服电机，是为了实现更高的加工精度和速度，但在很多机器上，伺服电机并不在同步时工作，而是在机器换单的时候，对机器进行调整。

例如，把裁切刀的刀辊换成伺服驱动，这样，当裁切尺寸变化的时候，仅需参数设置即可执行新的裁切任务 ——当然，这里的伺服电机本身作为一个同步轴，它会跟随被裁切纸张的尺寸而调整。但是，在印刷机的斜拉版、压印力调节、机械的机构调节；在瓦楞纸的换刀、书刊胶装/骑马订等场景里，伺服电机仅在需要更换规格时动作，并不参与同步的电子齿轮、电子凸轮等动作——这里大量伺服电机的使用，就是为了灵活地应对产品规格的变化（图3）。
同时，为了提高这些机械加工的效率，又实现了连线生产，像饮料行业的吹灌旋贴、纺织行业的开清棉、长流程的离散制造等都在实现这样的连线，中间更多地使用机器人、 AGV是为了提高效率。因为，必须把换单造成的那些时间损失弥补过来——这就需要通过网络来把整个机器连接起来，而不是用硬接线的方式来实现启动同步。通信就成为了实时控制的关键一环，而这些机器可以通过这种统一的通信连接实现同步，在软件层，对这些参数的上下行进行读写就成为了机器配置的关键（图4）。
运动控制的问题是它主要在机器内，例如定位主要是解决单点的问题，同步也仅解决了多个轴的关系，但它无法解决在机器和机器之间的输送这个难题。
(2)磁悬浮输送解决机器-机器间的可定义性
进一步的，人们发现控制主机实现了软件定义的任务编排，网络实现了数据流动和交互的接口，但机械的输送还是个难题——当年，CIMS/FMS这些其实就因为这个原因，无法被有效的运行。因此，才产生了柔性输送系统，即，现在被称为磁悬浮输送的系统，它打通了最后一个难以被“软件定义”的环节。通过“电-磁”转换，将传输系统转化为可以被软件定义的“单件流”、“连续流”——这符合精益生产对于产线的编排需求，因为它可以实现排队、配合加工等，可以让物料流动、配合加工成为一个被软件快速且可重配置的形式，这进一步推进了软件定义制造的可能，如图5所示。
因此，伺服电机、机器人、磁悬浮输送解决了产线中的局部修改，以及在机器间物料流的难题。
(3)通信——解决协作中的信息流
在软件层面，人们实现了加工过程的状态建模来实现生产的重组——用软件的“编排”来实现生产线的重组。之所以采用状态模型，就是因为它可以被逻辑编程。像PackML、 JDF、ISA-95、IEC61850、Unimat等垂直行业的规范，就是为了能够对这些生产过程进行统一的行规设计——这样就可以实现快速的参数下发（图6）。而新的MTP则是针对自动化系统的统一规范，来实现工厂的管理层任务解析并下发——可以通过OPC UA来实现这些通信的连接与数据的封装，提供了一个统一的框架。

物理建模与AI：解决知识的复用问题
对于制造业，如果每次都要对一个任务进行编程，或者对于一些知识都要重新组织，那么工作量还是很大的。为了把知识进行有效的复用，工程师们就开始想在知识封装上下点功夫。
在知识的挖掘的几个典型范式里，人们经常把远古时代的科学发现定义为人的天赋来实现的。而基于笛卡尔的方法论以及牛顿、莱布尼兹这些伟大科学家的第二个阶段，人们开始将物理的公式作为解决问题的思路。在计算机出现后，这些物理模型的验算就成为了计算机要去干的事。但是，这种基于物理知识的毕竟是有限的，它需要先验知识和已有的数据积累，才能更为精准的模型。而这无法满足越来越复杂的世界对于知识的苛求。那么，新的范式，基于AI就成为了一个必然的选择（图7）。
再进一步，人们又发现这些系统由于过于复杂，且存在很多“不可见的深渊”——即，在复杂的系统里，它们会产生效率无法被最优化的问题。因为，复杂系统的路径规划会形成非常多的组合，这无法被人用公式来计算，因为，这是一个“陷阱”，就是被“窝”在系统里的能力，它无法被有效的发掘。包括引发生产产品品质的干扰因素，例如相关性的、随机误差造成的无法被有效的观测和梳理。这就使得人们寻求通过“数据驱动的建模”来挖掘这些背后的规律，因而产生了对人工智能的需求——而人工智能，则又是一个软件。
(1)软件的模块化：实现知识复用
用高级语言封装算法，且构建出“高内聚、低耦合”的应用模块，然后让这些模块快速重组，来搭建整个机器的应用程序。这就是要用模块化的软件开发来实现——但是，自动化所面对的机电又是一个高耦合的领域，因此，基于物理建模的方法在计算机出现后就开始被大量使用。
在软件工程领域，著名的工程师Fredric在上世纪70年代，觉得软件正在陷入“泥潭”，后来随着模块化技术的普及，软件的危机得以被解决（图8）。在制造业同样如此，人们通过模块化来实现机器的快速软件重组。
(2)AIGC编程，让工程迈入更为灵活的时代
随着系统的复杂性不断提高，我们要面对各种各样的算法、AI分析、界面等，程序会变得越来越复杂。传统的编程即使是增强模块化，仍然不够，因为它的“门槛”比较高，尤其是机电工程领域。

AIGC编程就成为了一个潜在的方法，因为，它会继续使用原有的知识、模块来为工程师快速搭建架构，进行“按需”软件设计。尽管它目前尚不是很完善，这里，尤其是指制造领域的机器和产线，但，如果能够定义统一的规范进行约束，那么，相信它的准度、深度将进一步发展，其可用性会更高。
据此发展下去，软件未来自动生成软件，自动化工程师则将成为一个顾问，或者一个“桥梁”，它连接用户端模糊、不确切的需求，以及组织复杂的机电工艺之间的“关联”与“架构”，即，未来需要的是机电、工艺系统的“架构师”，而不是“Coder”。
(3)基于建模的开发与模型交互
但是，这还不够，毕竟在机电领域里，不如纯软件领域那么方便，太过于碎片化，因此，采用物理仿真的自动代码生成也成为了一种办法——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直接读取呢？这个约束机制本身就是一个探索过程，但，用“规则”约束自动编程系统，在可行性上可以进行探索——软件自动构造的方法，既可以通过系统建模、语言建模、软件接口、模型接口——至于哪种方法更好，可能通过多个接口和机制的联合行动，大家也可以做到最终的交互。
在图9这个架构里，电解槽相关的水处理、变流器、压缩机、电解槽、干燥系统、存储系统之间会形成一个整体。当系统需要更新数据和升级配方，则会统一的数据下发，以实现远程的升级。
这些工具的最佳组合会被探索出来，例如，在通信接口方面，模型交互方面，其实，不必完全构造，而是让系统学会各个接口规范，并让程序按照这个接口来实现——反倒，这个可能对于推理强的AI更容易掌控局面。因为，我们要做得太复杂的时候，反倒是难以实现的——但，人可以为机器提供校验，它还会学会你的校验过程。

(4)自动化还得是个咨询公司
前面提到，如果我们希望做到“软件定义制造”，而又有AIGC编程、模型交互、模块化设计，凡此种种，这能够让机器和系统更快的自动构造。而这个时候，你会发现，最为重要的不再是编程、设计， 而是“架构”，即，用户的需求到实现之间的这个“桥梁”。将用户需求翻译为机器可实现，这并非易事。因为，人的需求往往是模糊、不确定的，且存在隐藏的、没有被发现的——甚至提出需求的人自己也不清楚。
那么，这个时候，其实特别需要具有“咨询顾问”能力的工程师来解决这个问题。即，它能够梳理需求的逻辑，并能对需求进行精确的定位，并且能够关联机械设计、电气、工艺、AI分析之间的关系，能够把它表达为Prompt去给AI系统，让它去实现，然后还能给它的实现进行修正。
这可能不是一个工程师能完成的，而是一个由多个人和跨企业专家构成的团队，但这个团队需要具有咨询顾问的提问、分析能力——它是一个不止于跨学科，还跨职能去实现项目的组织。
(5)知识产权保护
要想真正实现“软件定义制造”，那么，在知识产权保
护方面，就必须有非常强的机制。当然，这种机制不一定是法律机制，也可以是技术的实现方法，配合法律法规。
这里也会牵扯到非常多的权利问题，即，数据权属问题、知识的归属，以及复制的权限等，也包括信息安全保护机制，来确保数据资产的安全。
所以， 自动化行业的“吃软饭”要能够成为一种长期稳定的“饭票”，还需要很长的时间发展，从目前来看，这个方向在行业内出现了某种端倪，但尚未达到真正意义的“软件定义制造”。