0710 【万泉河】从标准化的烟台方法到标准的生产流程规范

标题里面有2个关键词， 标准化和标准。

这是2个完全不同的词汇。有着不同的含义。

然而，有很多人就分不清这两者之间的区别。 经常大家在讨论标准化的时候，就有人跳出来宣读他曾经学习过的IEC 61131标准，以及PLCOPEN等组织标准。

另外，经常有一些公司，在领导有意向把自动化系统的设计调试工作标准化的时候，就会有一些高手，把自己调试成功的项目程序拿出来，以他个人的设计为模板，制定为公司标准，限制要求所有工程师同事遵守照做，然后就号称实现了标准化。

遇到过有搞标准化需求的公司，不知道从哪里搞来了一套相近行业的程序，再配套上一套还算完整的程序说明，就算完成了对公司的标准化辅导。 而这边公司的工程师对这套程序资料完全看不懂哪里标准哪里优秀，所以无从下手。而对方早就拿到钱，不管了。 导致这个公司的标准化推广工作还没起步，就直接夭折了。而老板因为有过失败的投资经历，伤了心，不再相信自动化系统能搞成什么标准化了。

标准， 是一套统一的规范约定，约定这个规范的目的是为了方便后端的使用者使用，提高互换性。通过统一的规范，可以实现简单互换重复使用，而不需要每次应用都要重新学习研究开发定制，从而实现了高效率。

标准化，是制定，生成标准的过程。 把原本杂乱的，无序的设计生产过程， 通过科学有效地方法，找到合理的优化路径，最终设计生成简单易用的标准规范。

关于标准与标准化的关系， 知乎上有一篇文章《“标准与标准化”讲解得如此透彻，我听了不下十遍！》 讲的非常透彻，文章名字不是我起的，但我确实看了不止十遍，也推荐过很多次了。 以后有机会还会尽量推荐。

读者们可以去找到阅读下，我这里分享它的链接二维码，不知道能不能被允许。我也会尝试直接复制引用全文，发在今天的文章下面。

那篇文章提及的是家具行业的标准和标准化我曾经想过对他的文章模仿修改，对找到工控行业，然而发现除了其中的家具等几个词汇之外，全文几乎不需要修改。因为其中大部分的管理思想是通用的，对照到非标机械自动化领域仍然完全适用。 

标准化生成的标准简单易用是一个非常重要的指标。 如上面提到的以某个个人喜好为模板硬性设计的规范，最终能理解使用这套模板的仍然是水平几乎相当的工程师， 仍然需要大量经验丰富的工程师进行设计编程以及在现场调试的工作，这从人员效率来说，几乎没有什么提高。

而烟台方法的目标却绝不止这些。我们的目标是，对于一种工艺成熟的非标设备或者系统， 设计者完成开发后，可以通过制定标准规范的方式，把设计编程调试的每一个环节都用规范固化下来，规范的结果，对使用者没有门槛要求， 只需要按照流程指导书逐步操作，就可以完成一个新的设备项目的设计工作。

即， 如果一个公司分为设备研发部和生产部，那么， 研发部门研发一套新设备，调试完成工艺成熟之后，就可以制订这套设备的生产工艺流程和规范，除了机械设备部件的加工工艺、电气盘柜的制造工艺之外，自动化软件系统也包含其中。当然这其中指的是每台新设备设备设计和程序都完全不同的非标设备的情况下。 如果是批量生产的软件程序都完全相同的设备，程序都不需要任何修改，那属于标准设备，不在本文探讨范围内。因为相信所有标准设备的生产厂家很容易早就实现了生产过程标准化了。

由此， 制造流程规范下发到生产部门，生产部门按照合同订单的配置，根据规范的指导，进行设备元器件的采购加工之外，软件程序部分也根据规范的要求，逐步生成。由于程序的内容都是模块化的，拼装式的，所以程序的生成过程不需要有任何创新和调试，所以不需要专业工程师亲自操作，只需要普通的技术工人，经过简单培训后就可以胜任。

由此， 从此以后，公司针对这个类型的设备所签订的所有订单，只要研发部门部署下发的规范足够完整，研发部门的工程师就不再需要过问，甚至到极端，公司签订多少个新订单都不需要知道。 生产部门按照规范标准，对照具体客户的需求约定的配置情况，就能完成。除非有个别新项目，增加了新功能新需求，需要研发工程师协助更新仓库部件，并修改更新发布新的规范标准。

经过一定时期的更新迭代之后，设备的制造流程会逐渐成熟，彻底定型。 不再需要研发工程师介入。 从此以后，研发工程师可以全部的时间和精力投向公司新业务新设备的研发工作，公司业务逐渐增长，效益规模越来越好，越强，越大，形成良性循环。当然， 这个时间跨度会非常长，有可能长达几年，也有可能在设备的整个生命周期内，就一直有改进。那么即便公司没有新设备研发任务，研发工程师也不必担心没有事情可做。当然，有能力把自己的工作开发成果稳定到无事可做，也是对公司的业绩贡献。除了自己生活工作状态可以优雅轻松之外，任何一家正常的公司老板，大概率应该考虑给你升值加薪了。

80工位双联开关和80模拟量批量处理的例程发布后，有网友下载了，学习了，也学懂了其中的编程技巧方法。然而不明白有什么意义。前来问我：

万老师，你的程序看了实现起来是很简单很优雅，然而有什么用啊？与我们平常方法写的程序有什么区别？

嘿嘿， 区别就在于简单啊，把复杂的功能逻辑封装在模块内部，而在应用层面一目了然的简化到极致的简单， 实现的过程简单可复制，不需要任何技能就可以实现，因而可以通过编制生产指导规范的方式实现技术传承，可以形成公司内部的生产流程标准化。

好吧，那我就以80系列的例子为基础，假想为工程项目，做一个操作指导书，下发给假想的生产人员。 从此以后，相似功能要求的项目， 不管数量是79还是81，70，90，甚至800， 8000， 生产人员都可以按照操作指导的步骤一步步完成项目的设计流程全过程。 现场的安装调试以及售后服务，也不再需要研发工程师参与。

在开始动手之前， 先讲解一下例子的概念问题。 咱们做例子的目的，是为了最大程度的模拟真实的工程项目现场。 而真实的工程项目中，设备类型都非常多，点数分布都非常凌乱没有规律。 咱们这里预设一个例子工况的时候，简单描述了有80个开关或者80个模拟量，然而并不代表这80数值代表了某种规律性。反而反复告诫，这没有规律可言，不要试图去总结得到这里的规律，然后用特殊性的规律去讨巧实现。这里所谓80或者79，81， 只是项目签订后，统计设备点表得到的数量。

反过来讲， 如果我做例子，总是先预设整齐有规律的规律性，然后做出来完全靠巧合拼凑而成的程序，学习者学习之后，发现根本没办法应用到自己的工程项目中，那么这个例子就属于完全的废物一个。

所以为了使得这次的演示例子更具真实性， 把前面两套例子糅合到一起，咱们假设项目中既有旋钮开关和指示灯，也有模拟量。他们的数量也都不固定。指示灯的数量也为多个。

首先把原本的两套程序拼接到同一个CPU中，会发现，拼接的过程就是简单的拼接。 程序模块和变量表复制过来。原本OB1中调用一个模块，增加到2个。仅此而已。

因为我们的80例子程序如我4年前文章所约，未使用任何全局变量。 （在所有平台中都是如此，所以这里的描述覆盖了所有品牌平台）

所以简单复制并不会发生变量冲突，所以也不需要做任何调试。唯一有可能的是，FB/FC的编号有可能冲突， 那是因为编号原本就是系统自动从小到大分配的，而对于PORTAL这样智能的系统，复制的时候如果有冲突，会自动提示。然后只需要手动改一个上临的空白编号即可。

所以，程序的这部分工作的难度，需要的技能和工作量都约等于0。所以主要的工作内容还是在文字处理方面。

具体的设计流程会是如下的操作指导书：

80+80系统PLC程序操作指导书

S1，根据合同技术附件内容和甲方交付的技术资料，统计IO点表

S2, 示范项目另存到新的工程项目，原有变量表删光，硬件组态按照新项目配置完成。

S3, 将位号、通道和注释列的内容复制到PLC变量表中，与实际的模块通道对应

S3, 检查程序页面数量正确，如有多余，则删除，如有欠缺行，则拖拽公式生成。

S4, PLC程序，FB801变量声明中生成第一列的实例数据，第二列的程序内容复制到SCL段落中。完成后取消注释。  

S5,同样操作完成开关部分程序到FB802中。

S6, 编译， 程序完成。 下载到PLC中。

S7, HMI中程序和画面。。。。。。。完成修改，联机调试，打点，完成。

这里只是简单给出了与程序相关的操作指导，实际应用中还可以对电气配盘，接线、上电过程，打点方式，异常错误处理等能想得到的细节一一给出经验性指导。都是常规知识，然而知识积累足够丰富之后，生产操作人员不需要懂得专业知识， 遇到问题也不需要去专门查阅专业技术资料，也可以当场解决把常见问题。

由此，可以极大地提高了效率。

而当这些细节技术内容统一规范成为公司标准之后，就成为公司积累的财富。成为公司在行业中的核心竞争力，因而也会成为核心机密。

所以，总有人问我烟台方法的标准化啥时候可以普及的时候，我拿这里的例子反问一下， 换你们公司，如上般辛辛苦苦研发积累的经验规范流程的内容， 会舍得免费分享给同行竞争对手吗？

你们舍得就行，与我还真没多大关系。在这个标准生成的过程中，即便有我参与，我也只是个培训辅导老师。