quote:以下是引用一天到晚游泳的猪在2014-04-14 22:13:39的发言：


谢谢指教，有些观点我非常赞同，比如标准化的问题、客户便于维护的问题

先谈谈标准化吧，从05年开始我在同事的影响下开始注重标准化，当时只是简单的认为是开发一些通用的FC/FB，后来慢慢的觉得程序结构、变量定义等等可以适当标准化，而且标准化的范围可以推广到Scada软件的开发。我写的一些FC/FB被部门里面其它同事用在了很多项目中（同事们也在按照我的程序结构去编程），甚至我还碰到有两个客户单位的项目（不是我公司做的）也用了我写的模块。——当然，这只是一个公司、一个部门中的、小范围的、自己的标准化，跟pcs7这种系统性的标准化是不能比的。

pcs7采用系统的标准模块的做法我是理解的，因为我也做过其它DCS，也是基本上采用系统自带的功能模块（同样的问题，那个DCS里面自定义功能块相当困难，一个块只能写50条语句）。感觉这样编程，基本上就是机械的调用系统的模块，谈不上“编程”了，我们这种自控工程师存在的必要性必然会越来越弱了，也许以后自控软件发展到苹果手机那么傻瓜化和易用，工艺工程师就可以胜任了甚至干的比我们还好（因为他们更理解工艺！）——扯远了

但是西门子不可能包揽所有的模块，比如流量补正模块，在我做过的项目里面就需要好几种：理想气体、湿煤气、蒸汽（过热和饱和）。再比如一种电液阀门，我在两个客户的项目中就碰到了两种控制需求，直接导致我写了了两个FB。

再说说客户的维护问题，这点确实让我有些苦恼：早期我写的一段报警处理程序，每个报警点调用一个FB，用户很容易看懂并修改，后来我写的一个报警批处理模块采用SCL循环处理所有报警点，一旦需要增加/删除/修改报警点就要修改SCL源码，而客户往往只懂一点LAD而已，只能我来帮着改，过了几年我自己都要认真读一读源码才敢修改。后来我修改了程序结构，把报警批处理程序分解成两个模块：报警点赋值和报警处理，一旦需要变动的话只需要修改报警点赋值语句，这个对于用户来说就比较easy了。我现在写程序，不仅仅考虑程序的模块化、通用化问题，同时也会充分考虑维护的便利性问题。

另外，很多客户的技术能力非常有限，往往能做到按照我电话指示去修改程序我就很满足了，所以，呵呵

这段时间自驾游去了，最近又出差了，所以过段时间我再静下来钻研下APL开发，感觉就差一层窗户纸了

---