【万泉河】工艺是分层的， 库也是分层的

这观点其实很浅显的，我甚至一度猜想在某些系统控制理论中有过描述。也怀疑说不定早就是大家心中约定俗成的常识了。

不过就我自己来说， 一直以来都没有严格分清。 唯有这次标准化方法编程实践中，才坚定的区分。在把做好的程序分享给同事的时候，首先第一步的交接工作就是先把《工艺是分层的， 库也是分层的》的基本思想灌输给他们，便于阅读理解程序框架，也便于以后在此基础上升级改造应用。

简单说，就是哪些程序块不允许你们改，或者改动的时候需要获得同意。哪些程序块允许改，调试中遇到问题可以改，应用中根据需要可以随时改，大家要有共识。 这样才不至于互相乱改， 都改乱了。

一个库函数， 你改一下我改一下，你在你的项目中这样改， 我在我的项目中那样改。 都有道理， 都有必要。 但经手人不同， 目的不通， 三五个项目下来，库函数就交叉衍生出十几个版本来，还标准化呢， 光忙活这些函数的兼容性都成了大问题了。

所以， 这问题上来必须先厘清。

其实也不是什么难懂的道理。

先用例子说话。

比方说，一台电机，带的一个水泵，给一个罐体供水， 保证其液位在一个允许的范围内。

那么， 这个电机的运行条件，或者说在运行中，发生哪些故障信号时，电机必须停止运行， 以保护某些设备，材料，环境，乃至人员生命安全。简单列举一下：

1，电机过流，超温，变频器故障等；

2，源水水压低， 缺水保护；

3，液位超高限。

等等

在传统的继电器逻辑中，上面的逻辑， 一行LAD自保逻辑即可完成。简单画个图：

但在标准化编程的框架下，程序就不能这么做了。

仔细分析一下，上面列举的故障信号的性质， 其实属于不同的工艺层。

第一类信号属于电气系统级别的， 仅仅是保护电气到电机的设备安全的。

第二类信号属于设备级别的， 保护水泵设备安全。

第三类信号属于工艺级别的， 满足生产工艺需求，或保护工艺设备安全。

那么很显然， 在进行程序设计时，也要把这些不同工艺层级的功能， 分开放到不同的工艺库中，才最合理。

如果在电气级别的库函数中， 加入了高水位，缺水等工艺保护功能， 那么这个库函数就失去了通用性。比如这个电机库函数原本还可以用于传送带电机，水位条件在里面就非常扯淡了。

反过来， 如果在编制工艺逻辑中，还时时刻刻强调电机过电流了要停机，要停机！那估计谁也没好心情做出好的工艺逻辑来。 早被烦死了。 

我曾经经历过的事情，有一个接近完工的项目交给一个同事配合验收，客户提出了一些信号逻辑下要停机的要求。我没怎么在意，让他自己去做了。

过了3-4年， 另有一个无关的项目要做，想到前面这个项目曾经一样的S7-1200的CPU，想这里的函数可以借来用。 打开归档程序以后，发现库函数不能用，被改的面目全非了。哥们把客户的增加的要求直接给加在最底层的库函数里面了。  心里面那个别扭劲是不用提了。

怪我在交接的时候没把允许他改的范围交代清楚，反而出于信任把库函数的修改密码告诉他了。当然也怪自己当年做的时候，思想上并不足够成熟，没有严格按照工艺的分层来对库函数进行分层。

给大家看一眼即将分享的程序的结构：

这些库函数FB，是分到3个层里面的，其中L1内的库函数是直接从西门子官方的例子中摘来的，除非万不得已，不会去动它。对它们的定义也是通用型的底层库，可以应用于所有工业控制领域， 所有行业。

而其中的L2层的库函数，有的是对L1库改造升级的， 有的是调用L1的库进行了再次封装， 还有的是专门编写的，总体定义是针对本行业的通用函数。 将来同一个行业另外的项目可以直接使用。而且升级过程中要保持延续性。

而其中的L3层的函数， 则仅仅针对本次项目，不具备任何通用性。将来的同行业项目，会有很大程度的接近，甚至相同，那也只是借用，完全可以在调试中根据工艺需求进行修改， 而不需要有任何兼容性方面的顾虑。

最后，这些函数只是作为库的存在。 尽管没有使用TIA的库功能。 在项目中调用的部分在另外的目录树中：

简单说，OB1中调用了从A10到A40内的所有FC, FC中调用了需要的不同层的库函数，而每个库函数FB被调用的背景实例分处于各自的目录中。

从我对工艺函数的分层方式，有人很容易联想到PCS7里面的PLANT VIEW下的工厂分级。是的， 有一定的联系。 但我在这里强调的是库函数的通用性问题。 作为库函数，体量上来说还是小多了，还到不了一个库函数对应一个车间或者工厂的程度。所以，总的说来，不是一回事。

参考文章：

还有更多文章， 请关注本公众号之后， 翻阅历史消息