0924 【万泉河】论PLC程序的可移植性（下）：可移植性是评价程序好坏的标志

曾经写过一篇文章《0426 【万泉河】论PLC程序的可移植性（上）：关于移植的定义》，然后就被很多读者催更下篇。而其实下篇早就写好了，只不过跨度太大，怕很多人接受不了。就没有及时发，一直拖到今天才发出来。

在上篇里，用了一整篇的篇幅，其实只论证了一件事，评价PLC程序可移植性的时候， 与所使用的PLC品牌和系统平台的性能无关。 而只与设计编程的程序员个人有关。即，程序可移植性其实是评价程序好坏的标志。

由此，就可以对等的参考已有的IT行业的大量的关于程序移植性的资料文章，对标到PLC行业，以形成专属于本行业的评价指标体系了。

程序的可移植性

移植是基于操作系统的。但是这个时候，我们需要注意一点：基于各种操作系统平台不同，应用程序在二级制级别是不能直接移植的。我们只能在代码层去思考可移植问题，在API层面上由于各个操作系统的命名规范、系统调用等自身原因，在API层面上实现可移植也是不大可能的。那怎么才能实现可移植呢？ 我们首先来看看现在主流的Windows和Linux平台下代码可移植性。有什么办法解决这个问题呢？答案是：在各个平台之间，基于大部分需求抽象出一个中间层。在中间层中，中间层用了屏蔽底层细节，在我们程序员看来C言语库就是这样一个中间层的作用。在各个平台下，我们默认C标准库中的函数都是一样的，这样基本可以实现可移植。但是对于C库本身而言，在各种操作系统平台下其内部实现是完全不同的，也就是说C库封装了操作系统API在其内部的实现细节。 因此，C语言提供了我们在代码级的可移植性，即这种可移植是通过C语言这个中间层来完成的。

认为什么样的程序方便移植

希望代码工程是分层分文件分函数的，如果不是 那复用肯定受影响，复用所消耗的时间也不小，程序移植注定要改混杂着代码逻辑的文件或函数，出了bug 那这职责就不能全赖程序移植者了。

软件质量模型的六大特性27个子特性（软件质量特性：功能性、可靠性、易用性、效率性、软件维护性、软件可移植性）

六、软件可移植性：从一种环境迁移到另一种环境的能力

1、适应性：适应不同平台

2、易安装性：被安装的能力

3、共存性：软件产品在公共环境中与其它软件分享公共资源共存的软件。

4、易替换性: 软件产品在同样的环境下，替代另一个相同用途的软件产品的能力。

5、可移植性的依从性

从上述这些文章中，可以发现在可移植性方面，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分不算过分吧？