0924 【万泉河】论PLC程序的可移植性（下）：可移植性是评价程序好坏的标志
曾经写过一篇文章《0426 【万泉河】论PLC程序的可移植性（上）：关于移植的定义》，然后就被很多读者催更下篇。而其实下篇早就写好了，只不过跨度太大，怕很多人接受不了。就没有及时发，一直拖到今天才发出来。
在上篇里，用了一整篇的篇幅，其实只论证了一件事，评价PLC程序可移植性的时候， 与所使用的PLC品牌和系统平台的性能无关。而只与设计编程的程序员个人有关。即，程序可移植性其实是评价程序好坏的标志。
由此，就可以对等的参考已有的IT行业的大量的关于程序移植性的资料文章，对标到PLC行业，以形成专属于本行业的评价指标体系了。
程序的可移植性
移植是基于操作系统的。但是这个时候，我们需要注意一点：基于各种操作系统平台不同，应用程序在二级制级别是不能直接移植的。我们只能在代码层去思考可移植问题，在API层面上由于各个操作系统的命名规范、系统调用等自身原因，在API层面上实现可移植也是不大可能的。那怎么才能实现可移植呢？我们首先来看看现在主流的Windows和Linux平台下代码可移植性。有什么办法解决这个问题呢？答案是：在各个平台之间，基于大部分需求抽象出一个中间层。在中间层中，中间层用了屏蔽底层细节，在我们程序员看来C言语库就是这样一个中间层的作用。在各个平台下，我们默认C标准库中的函数都是一样的，这样基本可以实现可移植。但是对于C库本身而言，在各种操作系统平台下其内部实现是完全不同的，也就是说C库封装了操作系统API在其内部的实现细节。因此，C语言提供了我们在代码级的可移植性，即这种可移植是通过C语言这个中间层来完成的。
原文链接：https://blog.csdn.net/qq_38216239/article/details/84500704
认为什么样的程序方便移植
希望代码工程是分层分文件分函数的，如果不是 那复用肯定受影响，复用所消耗的时间也不小，程序移植注定要改混杂着代码逻辑的文件或函数，出了bug 那这职责就不能全赖程序移植者了。
原文链接：https://blog.csdn.net/quanquanxiaobu/article/details/115773843
软件质量模型的六大特性27个子特性（软件质量特性：功能性、可靠性、易用性、效率性、软件维护性、软件可移植性）
六、软件可移植性：从一种环境迁移到另一种环境的能力
1、适应性：适应不同平台
2、易安装性：被安装的能力
3、共存性：软件产品在公共环境中与其它软件分享公共资源共存的软件。
4、易替换性: 软件产品在同样的环境下，替代另一个相同用途的软件产品的能力。
5、可移植性的依从性
原文链接：https://www.cnblogs.com/zzm-blog/p/11518968.html
从上述这些文章中，可以发现在可移植性方面，PLC程序和IT程序还是可以有极大的共性。只不过双方是完全不同的领域，所以对方的一些特定的名词概念，需要稍微加以替换和修正。
一个很容易被误解的前提，很多PLC同行会认为PLC行业的系统平台比IT行业的平台要多，因为除了CODESYS阵营之外，几乎每个PLC厂家都有自己的系统平台。而当我们对IT行业稍微了解，他们的系统平台一点都不少，甚至可能会更多，更令人眼花缭乱。我们甚至没有能力把这些系统平台的谱系描述清楚。有微软的.NET平台，有JAVA，有WINDOWS，LINUX， 以及IOS等等，。
而总结所有的观点， 要实现可移植性的基本方法是分层。即把基于操作系统平台的部分逻辑功能封装，而主程序的逻辑部分则完全不依赖于系统硬件特性，因而才可以实现移植。
这部分观点在PLC行业仍然通用，然而貌似有点目标过高，大部分同行还没有能力一步到位实现。
我们可以把此作为一个终极目标，作为最高级别的满分100分，然后从低到高整理分析不同的级别，给出一个评级表。
而评级表的起点是多少， 最低从0开始吗？
好像还不是。
我们讨论可移植性的时候， 指的是跨系统平台， 比如一套控制系统，原本使用西门子S7-1200完成，现在因为缺货的原因或者其它的原因， 需要更换到三菱， OMRON，或者 台达，汇川等品牌，原有的程序需要移植到对方的控制系统平台上。
如果这套程序完全没有可移植性，即整个程序所有模块单元， 全部都需要从头设计。即便旧的工艺逻辑有部分可以借鉴，然而必须工程师亲自来逐行编写， 没有办法借由软件工具或者由完全不懂PLC的文员助理协助完成，那么这套程序的可移植性等于0。
然而，行业中当下的现状是，相当一大部分的PLC程序都不要说跨系统平台了。即便PLC型号不变，仅仅是换了个项目， 或者非标设备功能参数有改变，原有的程序逻辑直接复制过来都不能使用。还需要做一些修改和替换。包括：
逻辑涉及的物理通道地址需要替换
用到的M点、定时器、DB数据等系统资源，需要重新分配并更改。
这些工作，除了工程师本人，外人是没有能力协助的。而即便工程师自己，在办公室内改完了以后，也不敢直接宣布此部分程序功能已经完成移植，还仍然需要下载到设备后，在线运行调试确认。因为总有某些细节，在修改的时候有可能疏忽，带来新的故障。所以， 其实和完全从头新写一个程序并没有什么两样。
这是过去二十年，我自己和大部分同行做的工作中的大部分的工作。
即， 在领导看来我们是在搞自动化高科技，而实际上我们只是在不停地为自己的粗心大意埋单。而这个粗心大意又是不可避免的，因为是所选择的程序架构方法所带来的必然后果。
即便到现在， 大批的同行，一个公司内做久了，同样类型的项目重复一次次的做，然后在各个项目现场无休止地出差，调试服务，所做的工作内容大部分也都是这些乏味的，令人懊恼的，而不是每次都有创新，每次都因为实现了新功能而有收获有满足感吧！
那么，这样的程序应该打多少分呢？给-20分不算过分吧？
下一主题
