山东淄博市西门子（授权）总代理---华北地区西门子（授权）一级经销商

那么，在jizhi的情况下，一旦对某个工艺设备的逻辑开发成熟，后面的工程就不再需要工程师到现场出差，现场的安装工人按照设计部门给付的设计资料，稍微整理下装程序即可。下装后程序逻辑即可可靠运行，不再需要试车， 不再需要现场调试。 
当然，上面所述是zhongji目标。在zhongji目标达到之前，工程师可能还需要偶尔出差，有可能只是为了到场安抚客户，让习惯上看着工程师调试动辄一个月的客户心理有些安全感。然而这时候的出差，对工程师来说基本上就是商务旅游了，没有什么压力， 去了以后大部分时间也就协调配合。时间也极短，原本一个月两个月的调试时间， 现在3-5天就完成了。 
然后， 原本一个工程师，一年能干5-6个项目的，现在一年干20-30个也不在话下。而且劳动强度还降低了。这种情况下，这样的高效率，老板如果不给涨工资，合天理吗？

标准化编程方法，其实不是一种什么思想，他的实现方法很简单， 4个字，面向对象。如果懂的人自然早就已经懂了。

然而标准化编程，其实是一种能力。 
拿我自己来说，我在十几年前就开始研究琢磨标准化编程的方法，然而自己一直没能全部打通。10年前在s7-300中已经做到了程序中不使用m和t，然而系统还是需要长时间的现场调试，因为疏忽造成的bug显著减少，返厂次数少了。然而总体效率提高并不明显。 
这个时候我整体技能还不成熟， 同时也缺少一个关键点的推力。然后在5年前开始使用s7-1500, v13, v14,v15。到v15的时候， 突然发现它可以比以前更好的支持面向对象了！然后如开挂一般，除了搞出了s7-1500标准化应用，甚至还倒回去在s7-200 smart中实现了标准化架构。 
按说s7-200的标准化与s7-1500根本没有关系。s7-200早就存在了20年，我早用的滚瓜烂熟，为啥之前我搞不出呢，为啥在s7-300时搞不出呢？还是自己能力不够嘛！
我在上一个公司上班时，公司别的部门成立项目组要搞标准化，那个时候公司用的是s7-300。我自己既然没有这个能力，自然也帮不上什么忙。我认为搞不出，他们也不相信。然后就由他们自己搞了。 
上个月， 我问了一下以前的那位同事，你们当年搞的标准化，怎么样了啊？

回答说， 搞了一堆函数库，但根本没人用。废弃。
我说， 这很正常。以我当年的认知，都自认为没有能力搞成， 我也顶多给公司做个样板工程，给同事们打个样，以后同样工程可以参考而已。你们技术部都没有现场调试经验的，仅凭临时学一下step7，不会的地方还要逐步向我请教的，就能一步到位做出标准化开发？天方夜谭呢！
所以看出来了吧， 能力以及能力的成长才是第一主要的。 

标准化的程序架构，在整个行业前面发展的40年里，是从来没有出现的。所以，所有同行，之前并没有见过这样的项目案例，所入门学习的参考资料，全都是过去传统模式的架构。所以自然有很多很多人持怀疑态度。 

怀疑者的心态，我猜有两种。
第一种，不相信在plc行业能做出标准化的程序， 甚至有的人都一直不相信可以做出不使用全局变量的程序。 
第二种，相信客观世界能，但不相信我有这个能力做出来，或者不相信我所做的标准化程序和他们以往所做的和见到过的程序有什么不一样。 
这两拨人，总是一副挑战的心态，以激将法来问我要程序。说什么你敢拿出个例子程序来吗，除非你拿出来给我看了我才相信你。 

经过本文的分析，大家现在应该都明白了吧，标准化是企业的标准化，是每位自动化同行所在的公司的标准化，与plc厂家没有任何关系。企业是否做到标准化，与工程师个人的效率，工作量，出差辛苦程度，薪资水平这些所有加起来的痛点有关系，而与我并没有多少直接关系。 

像开始的故事里， 那位离职的工程师，在外面飘了2年之后，又回来跟老板联系，有意再回公司工作，继续出差也愿意。然而被老板很冷淡的拒绝了。他当初是和另一个工程师几乎同时辞职的，现在，这样的岗位不缺人了。因为他们实现了标准化设计，就那些老是大同小异的重复性的工程项目，一个工程师足够了。有一些小项目，电工在现场也就干了。都不需要工程师去了。
所以，这其中效率提高了多少， 大家都能基本有数了吧！