发表于：2022/4/27 9:09:56
#0楼
0426 【万泉河】论PLC程序的可移植性（上）：移植的定义
程序移植的概念同样来自IT行业，把一套程序功能移植到另一个系统平台。
PLC行业与IT行业有一点极大的不同，即，PLC行业中有很多图形化的编程界面。 许多所谓的程序，其实是一些图形化的符号。因而并不像IT行业一样都是文字形式的源代码。文本类型的源代码可以直接通过复制粘贴的方式从源复制到目的，然后根据两套系统语法或性能的不同，就可以探讨程序如何移植，以及程序质量的好坏， 是否可移植可识别了。
PLC系统的图形化的编程语言，通常遵循IEC 61131标准，有梯形图LAD， 功能图FBD，顺序功能图SFC等等。
我在文章《【万泉河】PLC编程中的IEC61131-3标准》有过介绍。
IEC 61131-3对这些图形化语言标准作了定义，但却没有对存储这些语言的文件格式进行约定。即各厂家可以自行定义符号语法，只要最终能在用户层面实现程序显示，编辑和存储即可。
因而导致各厂家不同平台之间， 貌似相似的图形语言， 比如都是LAD的程序，并不可以直接复制粘贴。
甚至，同一厂家的不同平台，也都不能直接兼容。
比如，最简单的一段串联逻辑：
这是在SMART200中的程序。如果要复制到TIA PORTAL中，虽然同样都是西门子的产品，也不可以复制粘贴，如果要移植，也只能参照着重新抄一遍（画一遍）。
针对这种状况，近些年，国际上又成立了PLCOPEN组织，旨在推广IEC61131-3的标准化应用，增强各厂家之间接口的兼容性。然而，此项工作难度极大， 并没有那么容易一蹴而就。 如我在前一篇文章中所述， 各厂家都自己握有巨大的话语权以及自身的经济利益的考量， 所以不管是标准还是国际组织，都没那么容易驯服他们乖乖听话。
所以，我们如果简单从加入的厂商名录作为判断兼容性的依据，肯定是远远不够的。 这些厂商还需要长期的磨合，博弈，才有可能逐渐实现。现在对PLCOPEN比较热心的厂家， 大部分都是CODESYS阵营的。 而原本在CODESYS框架下， 程序语言使语法都是通用的，而如果要大范围的兼容， 首先要看西门子的态度。 从明面上看， 有说西门子已经加入PLCOPEN阵营，也有说并没加入。
然而从结果看，西门子和CODESYS都是使用XML标记语言表示图形化元素，即各自的图形化程序语言都是可以导出到XML文本代码， 然而各自的语法定义大相径庭，完全不相兼容。这是当下的实际状况， 也会是未来很久时间内保持的状态。
所以，在图形化程序不可以直接通过剪贴板复制粘贴不可行的情况下， 如果编程语言支持了XML导出，那就放低目标，如果能导出到XML格式之后再到目标平台导入可行的话， 也算是可以实现顺利移植。
然而即便这样的低目标，在当下的PLC行业， 也是不容易实现的。
然而，只能叫做不容易， 但绝非不可能。 假如， 如果，未来有一家公司，或者某位极客爱好者， 完全充分解读两个不同厂家的XML语法定义，并作出自动处理的程序转化软件工具，将一套系统中导出的XML文件，翻译转化为另一套可识别的XML文件，再导入到目标系统中，即实现了程序导入和移植。
所以，在工具未面世之前，贸然判断程序不可移植，是不恰当的。
所以，我们在探讨程序的可移植性的时候，不应该因为工具的有或者无，而摇摆不定，须臾改变观点。
就好比，探讨人类是否可以在火星或者别的星球生存的话题，应该主要的精力关注于火星的气候，资源， 水，空气，能源供给等客观条件。 而不应该被航天载人工具牢牢限制了思维。
比如问， 人类能否在火星生存生活？答：航天飞机飞不到。 再问：研制个能飞往火星的航天飞机如何？反问：研制了做啥用，火星上人类都不能生存。形成死循环而永远裹足不前了。
到PLC行业就成了：我们探讨下跨PLC平台程序移植的可行性？移植不了，没有工具，不支持。
所以， 首先需要对移植的定义本身，达成一个共识。
我在多个场合，专栏文章里，以及在专著《PLC标准化编程原理与方法》多个章节，反复强调的一点，设计工作中，凡是在动手做之前就可以知道结果的，工作只是重复性质的工作量问题的，都会想方设法研发或者外购现成的工具软件来实现。
而针对程序的移植，我们会有相似的观点，如果一套控制程序需要从一个平台迁移到另一个平台，如果目标程序的答案结果是确定的， 哪怕即便暂时没有自动迁移工具，只要规则是清晰的明确的， 如果可以找一个完全没有行业技能的外行，比如一个文员、实习生甚至中学生， 对他们进行简单的规则培训之后，由他们人工进行程序的迁移。迁移的过程没有技术难度，有的只是重复劳动的工作量，那么我们就可以认定这个程序做的还不错，可以实现跨系统跨平台的移植。
这时候， 程序的可移植性与平台的功能无关，更与是否存在第三方辅助工具无关。 只取决于程序作者的编写程序的架构和方法，所写的程序是否可以更好地支持移植。第三方辅助工具不存在的时候人工做，有了工具之后随时可以换由工具实现。
这才是真正的PLC程序的可移植性的概念。
概念清晰之后，下一篇文章会重点论述评估PLC程序的可移植性的准则，以及编写可移植性高的PLC程序的原则和方法。
程序移植的概念同样来自IT行业，把一套程序功能移植到另一个系统平台。
PLC行业与IT行业有一点极大的不同，即，PLC行业中有很多图形化的编程界面。 许多所谓的程序，其实是一些图形化的符号。因而并不像IT行业一样都是文字形式的源代码。文本类型的源代码可以直接通过复制粘贴的方式从源复制到目的，然后根据两套系统语法或性能的不同，就可以探讨程序如何移植，以及程序质量的好坏， 是否可移植可识别了。
PLC系统的图形化的编程语言，通常遵循IEC 61131标准，有梯形图LAD， 功能图FBD，顺序功能图SFC等等。
我在文章《【万泉河】PLC编程中的IEC61131-3标准》有过介绍。
IEC 61131-3对这些图形化语言标准作了定义，但却没有对存储这些语言的文件格式进行约定。即各厂家可以自行定义符号语法，只要最终能在用户层面实现程序显示，编辑和存储即可。
因而导致各厂家不同平台之间， 貌似相似的图形语言， 比如都是LAD的程序，并不可以直接复制粘贴。
甚至，同一厂家的不同平台，也都不能直接兼容。
比如，最简单的一段串联逻辑：
这是在SMART200中的程序。如果要复制到TIA PORTAL中，虽然同样都是西门子的产品，也不可以复制粘贴，如果要移植，也只能参照着重新抄一遍（画一遍）。
针对这种状况，近些年，国际上又成立了PLCOPEN组织，旨在推广IEC61131-3的标准化应用，增强各厂家之间接口的兼容性。然而，此项工作难度极大， 并没有那么容易一蹴而就。 如我在前一篇文章中所述， 各厂家都自己握有巨大的话语权以及自身的经济利益的考量， 所以不管是标准还是国际组织，都没那么容易驯服他们乖乖听话。
所以，我们如果简单从加入的厂商名录作为判断兼容性的依据，肯定是远远不够的。 这些厂商还需要长期的磨合，博弈，才有可能逐渐实现。现在对PLCOPEN比较热心的厂家， 大部分都是CODESYS阵营的。 而原本在CODESYS框架下， 程序语言使语法都是通用的，而如果要大范围的兼容， 首先要看西门子的态度。 从明面上看， 有说西门子已经加入PLCOPEN阵营，也有说并没加入。
然而从结果看，西门子和CODESYS都是使用XML标记语言表示图形化元素，即各自的图形化程序语言都是可以导出到XML文本代码， 然而各自的语法定义大相径庭，完全不相兼容。这是当下的实际状况， 也会是未来很久时间内保持的状态。
所以，在图形化程序不可以直接通过剪贴板复制粘贴不可行的情况下， 如果编程语言支持了XML导出，那就放低目标，如果能导出到XML格式之后再到目标平台导入可行的话， 也算是可以实现顺利移植。
然而即便这样的低目标，在当下的PLC行业， 也是不容易实现的。
然而，只能叫做不容易， 但绝非不可能。 假如， 如果，未来有一家公司，或者某位极客爱好者， 完全充分解读两个不同厂家的XML语法定义，并作出自动处理的程序转化软件工具，将一套系统中导出的XML文件，翻译转化为另一套可识别的XML文件，再导入到目标系统中，即实现了程序导入和移植。
所以，在工具未面世之前，贸然判断程序不可移植，是不恰当的。
所以，我们在探讨程序的可移植性的时候，不应该因为工具的有或者无，而摇摆不定，须臾改变观点。
就好比，探讨人类是否可以在火星或者别的星球生存的话题，应该主要的精力关注于火星的气候，资源， 水，空气，能源供给等客观条件。 而不应该被航天载人工具牢牢限制了思维。
比如问， 人类能否在火星生存生活？答：航天飞机飞不到。 再问：研制个能飞往火星的航天飞机如何？反问：研制了做啥用，火星上人类都不能生存。形成死循环而永远裹足不前了。
到PLC行业就成了：我们探讨下跨PLC平台程序移植的可行性？移植不了，没有工具，不支持。
所以， 首先需要对移植的定义本身，达成一个共识。
我在多个场合，专栏文章里，以及在专著《PLC标准化编程原理与方法》多个章节，反复强调的一点，设计工作中，凡是在动手做之前就可以知道结果的，工作只是重复性质的工作量问题的，都会想方设法研发或者外购现成的工具软件来实现。
而针对程序的移植，我们会有相似的观点，如果一套控制程序需要从一个平台迁移到另一个平台，如果目标程序的答案结果是确定的， 哪怕即便暂时没有自动迁移工具，只要规则是清晰的明确的， 如果可以找一个完全没有行业技能的外行，比如一个文员、实习生甚至中学生， 对他们进行简单的规则培训之后，由他们人工进行程序的迁移。迁移的过程没有技术难度，有的只是重复劳动的工作量，那么我们就可以认定这个程序做的还不错，可以实现跨系统跨平台的移植。
这时候， 程序的可移植性与平台的功能无关，更与是否存在第三方辅助工具无关。 只取决于程序作者的编写程序的架构和方法，所写的程序是否可以更好地支持移植。第三方辅助工具不存在的时候人工做，有了工具之后随时可以换由工具实现。
这才是真正的PLC程序的可移植性的概念。
概念清晰之后，下一篇文章会重点论述评估PLC程序的可移植性的准则，以及编写可移植性高的PLC程序的原则和方法。
PLC标准化编程
