1015 【万泉河】PLC程序中也可以有中间件

我们认为，自动化行业是无限接近IT行业的，然而又是个相对独立和小众的小行业。

所以， IT行业中的大部分理念和思想，大都可以对标到自动化行业中， 找到相应的影子。

所以，当我们对前方的路看不清的时候，不妨抬起头来观摩参考下隔壁，他们都在做什么， 怎么做的， 做的东西使用的方法是不是我们可以拿来借鉴，有多少程度可以借鉴。 远比我们自己拍脑瓜闭门造车要容易的多。

我已经写过很多相关的文章了，介绍IT行业的理念， 以及我自己的思考与实践，把这些理念方法应用到PLC行业。

比如，面向对象的程序方法，code review, 软件架构师，高内聚低耦合，编程规范，程序移植等等。

当然PLC行业还是存在一定的特殊性，也相对封闭， 有自己的行业特点，所以隔壁好多思想方法并没那么容易直接拿过来套用。 也所以，我好多相关文章写出来， 很多人读不懂， 不理解。

比如，前面一篇程序移植的文章发表后，后面的跟帖中有一位抬杠专业户的质问，按照烟台方法做的程序，程序从一个PLC平台移植到另一个厂家的平台，移植前后， 代码相同部分有多少？而不同之处有多少？

如果顺着这位杠子手的逻辑回答， 那显然只能按他预设的答案回答了。 不管用不用烟台方法，结果都是一样的，相同部分几乎没有，而几乎全部都是不相同的。

比如我做的西门子之外的各个品牌的标准化程序，不管是CODESYS倍福，还是三菱欧姆龙，尚不提最新的信捷等小PLC，就单看三菱的程序， 把BST的库函数移植到三菱GX2平台，SCL程序代码复制到三菱ST语言之后，每行都要包含2-3个错误，一个MOTOR块，如果一字不改的话， 错误要超过1000个。 而把错误逐个修改之后，你要问相同部分有多少？严格来说，没有一句相同的！

所以，按照这位提问者的逻辑，他显然是赢了。赢了他自己。

而显然，这位是不晓得软件编程中有个中间件的概念的。

对于中间件，其实都不需要什么名词解释，因为很容易理解，名词本身就是词义。 当然也可以从网络搜索到标准的名词解释。

中间件是一类连接软件组件和应用的计算机软件，它包括一组服务。以便于运行在一台或多台机器上的多个软件通过网络进行交互。该技术所提供的互操作性，推动了一致分布式体系架构的演进，该架构通常用于支持并简化那些复杂的分布式应用程序，它包括web服务器、事务监控器和消息队列软件。 [2]
中间件(middleware)是基础软件的一大类，属于可复用软件的范畴。顾名思义，中间件处于操作系统软件与用户的应用软件的中间。 [2]
中间件在操作系统、网络和数据库之上，应用软件的下层，总的作用是为处于自己上层的应用软件提供运行与开发的环境，帮助用户灵活、高效地开发和集成复杂的应用软件。在众多关于中间件的定义中，比较普遍被接受的是IDC表述的：中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源，中间件位于客户机服务器的操作系统之上，管理计算资源和网络通信。 [2]


然而，这个概念又与我提到的其它词汇一样， 不能直接对标找到PLC行业的解释。 甚至，之前也无人正式针对性的介绍过。 或许，未来，网络搜索关键词“PLC” + “中间件”，应该主要会搜到万某的本文。

所以，在PLC行业，怎样才叫中间件，需要单独去思考和定义。

打个比方，比如控制一个工件的移动， 会使用伺服或者步进电机，通过驱动它们，位置模式，或者速度模式，或者速度+位置的模式，达到工艺需要的结果。

抛开步进电机或者其它的代用方案不谈， 只谈伺服电机本身，就可能有多种控制方案，控制器可以有多个品牌，通讯方式也可以有多种，脉冲方式或者DP, PN, ETHERCAT等多种工业总线。 甚至具体的控制方式也可以多种，工艺对象和EPOS等。

然而， 你可以把所有的方式都各自封装为单独的中间件，而放给工艺逻辑的只有接口指令，比如在工艺逻辑中， 只包含对伺服的位置指令或者速度指令。

那么，未来的工艺实现，就可以与具体的伺服选型方案无关了。 比如工艺要求步骤1， 定位移动到相应位置，2，以设定速度运行，等待结束条件；3， 给定目标位置，达到位置。

按照工艺要求完成调试后， 哪怕未来更换了伺服电机品牌， 甚至不再使用伺服电机， 比如油缸。而上述的工艺逻辑代码不需要修改，可以继续使用。

甚至，即便PLC的型号品牌更换了， 也只是根据其语法规范做一些替换移植， 而不需要被具体的内部控制方法困扰。

这就是中间件的意义。

一定有人一眼就看懂了，讲了半天， 这不就是FB吗！FB就是中间件的话， 那我早就会了啊！

没错， 中间件当然要通过FB功能块来实现，但你做的FB是否能达到中间件的功能， 你的工艺逻辑中是否夹杂了所使用的伺服方案特有的指令和方法模式，在面向移植需求的时候，能否简单实现移植？

或者， 去回答一下楼上那位杠子手的问题， 代码移植前后的相似度有多少？

我在做信捷等小PLC的标准化开发的时候， 最头疼的便是其伺服实现。 伺服通过脉冲控制，而每个脉冲输出靠系统变量来控制，使用的系统变量各不相同。 想做成一个统一的FB块，都非常困难， 更何提中间件了。

当然， 在某位学员的帮助下，绕了很多圈子，最后还是实现了。 但实现过程不够简洁。

而我所见过的所有品牌的项目程序，相关部分应用都深度耦合成一锅粥，离本文所预期的中间件目标都还相差很远。

不过，最后还是提一下，如果未来这个行业足够成熟，标准化架构方法普及之后， 中间件倒是可以成为一个不错的中间产品，甚至可以形成一定规模的交易市场。任何做项目的一方， 需要什么中间件的时候，市场上巡视一番， 找到合适的买回家，简单使用拼接，自己的工艺项目就完成了。

以这样方式描述未来愿景，比以往高内聚低耦合的语言，是不是更亲和，更容易理解了？

当然啦， 不要误解歪了， 烟台方法不卖任何中间件， 也不倒卖中间件， 我只传授制作中间件和使用中间件的方法。 烟台方法的学员们之间，可以互相交流交换中间件，因为方法是通用的，他们之间交流没有障碍。

而非烟台方法的学员，目前看来就很难了。