转载自网络！

感谢分享

做维护的，感觉标准化距离我比较远....

有些东西要细思，要细品，包括这个论坛

一条PLC标准化程序编写后，要实际运行一段时间，反复论证改正不足，最后才能应用。

谢谢楼主分享，也是想着手做这个，很好的思路

,提供了一个很好的思路

，这个需要时间来验证的，分不同工种吧，学习了！！！

结合工作经验，分享下我的模块化之路

1、入门

很幸运，一毕业就接手BOSS的IFIX项目，这个项目奠定了我的思维高度。

入门啃了一个月的vb，终于能上手。IFIX的开放性和灵活度确实非常好，作为组态软件，我认为比wincc好用很多。程序里有很多函数、模块，比如有连接数据库、关闭数据库、登录、操作记录等等公用模块，标签组实现faceplate。那时还没有模块化的概念，只是觉得应该这样做，程序架构很清晰，非常好维护。

2、对PLC模块化的疑惑

早期参与了几个PLC项目，其中一个是用AB的1756做的污水处理，里面开泵开阀、异常判断有很多代码，但都是针对一个个任务，直接输出到IO点，调试的比较麻烦

3、模块化的启蒙

应该是西门子有个示例代码，里面有step7和wincc的一些模块案例，逐渐对模块化有了理解。

2009版本的找不到了，这个类似：

https://support.industry.siemens.com/cs/cn/zh/view/66839614

4、尝试与应用

后来逐渐在项目里应用，尝试自己做些模块化的程序。

不论是施耐德unity pro、ABB AC800M、AB 1756这些plc还是AB SE、IFIX、Wincc flexible、国产的力控组态王这些组态软件。

印象里大概是10年，有一套s7-300+力控的项目，做完后仪表阀门数据刷新非常慢，后来查明原因：力控和s7-300通讯的背景DB太多（采用了一个仪表一个DB），不知道现在力控的驱动是否已经优化了。

5、提高与深入

做的第一个PCS7项目，那时刚出8.0，研究了APL，对APL丰富的功能感到惊讶，在项目自定义了很多APL风格的库。可以说PCS7的帮助非常大：

基础的原则、控制策略、体系化、模块化、结构化、标准化

6、疑惑

PCS7、APL很强大很复杂，博大精深。但能用的到的只有少数和基本的功能

PCS7没有很好的解决流程问题，虽然有SFC和SFC Type、Batch

不容易解决定制化的需求，毕竟没有APL源代码

还是结合行业特点，做自己的库和模块，才是解决之道。

7、优化

由于有跨平台的需求，因此采用SCL，在PCS7、TIA、Step7项目里都建立了核心代码基本一样的模块，减少项目团队的学习成本。

慢慢做到模块公用，比如开关阀、调节阀、工频电机、变频电机这些的核心逻辑是类似的，我就把她们共用了一套模块，包括facepate，减少维护量，应用时只要简单的配置。

基础的流程、顺控、状态机等，也统一用SCL做标准的模块，自己搭，比SFC灵活好用

8、标准化

模块化和标准化是并行的。

我们现在所有人用一套模块、一套架构、一套开发原则和一套质量标准。这个对公司会很有帮助。

程序模块依然在不断打磨、升级

9、拓展

单元级别的模块化：

有几个项目，特点是同类型单元很多，每个单元的工艺流程、仪表阀门配置基本一样，针对这种，我们把整个装置视为一个模块，类似于PCS7里的unit class type，在TIA里实现了几十个装置共用1个模块和1个画面，极大地提高了效率。

可配置和柔性化：

这是正在做的。很多相似的单元、流程，做成可配置的模块化。项目里做配置，不需要修改原始模块代码。要真正发挥效力，不仅仅是软件，也包括硬件、设备、管道，以及用户水平。

标准化模块程序是经历过现场和时间检验的好用和规范的程序。

一般是一个团队或集团工程师的智慧。

这种程序经过时间的再检验往往也有修改的空间。

       个人感觉，标准化每个公司都在做，但正如楼上几位大侠说的一样，需要一个团队或是经验非常丰富的人去长期优化，结合现场应用去调整。单个人，觉得更多的是提高标准化，模块化的意识，这样对于个人的高度就会有提高！

这个观点非常认同，个人只能提高意识，搞体系只能是公司层面去推动，除非你是一个标准化绝对的权威，大家都认同的权威，那样才能去推动公司级别推广！

但往往标准化也只能参考，每一个公司每一个行业都有各自特点，所以没有放之四海而皆准的所谓绝对权威的标准化！

 标准化，模块化，事半功倍。

程序是有一个标准的   但各个地方厂自己也会优化   时间长了就变了    如果某些标准块不允许修改   只允许修改部分应该是会好点

普通公司采用得设备有多种型号，不同plc厂家，所以标准化还是大型公司来搞比较好，特别是能源，电力，水利这样设备系列种类相对固定的厂家

感谢分享，标准化之路，随着行业的不同而不同，随着科技的发展也在不断发展。

标准化的东西需要更多的有多年工作经验和多年现场经验，和对系统优化简化能力的人，一个团队共同完成的，既精简又实用，上手也快，但是实际操作还得实践中来到实践中去，合理化是个漫长曲折的过程，基本上在一个行业中深耕的技术人肯定开始做了。

理论是很好的，但是实际上很多情况下确实每个厂家都有各自的一套办法，或者本身有些起点也不高就觉得编程很容易的，导致各种程序BUG也好，不规范性操作也罢的问题都存在。做i为设备使用者表示，真的伤不起。。。

对于非标行业来说，有点难。各类工艺，各类产线需求，傻瓜自动化……

在座的诸位，难道写程序不是从“标准化”来写的吗？或者说通用化。难道写的程序只能用到这一类设备上？我想诸位都在用FB FC写程序吧，没有用个类国产之流的长筒筒来写程序吧。那么你辛苦写的FB只能用一次？不能用在其它的设备上？

个人标准化成套设备，维护，大型项目建设都做过，目前在做项目建设，个人认为标准化固然重要，但使用起来还是要更多的配合工艺需求，毕竟我们是辅助。

对于目前很多成套设备厂家来说，由于很多工艺的保密原则，很多控制技巧是不对外开放的，厂家也都根据自己的需求对自己产品的常用功能的控制程序进行了自己公司内部的标准化和模块化，毕竟生产效率对于传统制造业来说是很重要的。

对于维护人员来说，标准化最好，但是对于日常维护来说，条条大路通罗马只要能短时间内很好的解决工艺需求就是一个很好的维护人员了。因为能读懂程序架构，再能读懂细节对于很多现场维护人员来说很不容易。如能更好的了解大的架构程序就需要从建设期调试一直跟着厂家工程师并且深度参与，但这一点很多企业的决策者是认识不到的。

由于工程建设是一个系统工程，工厂建设决策者们认识不足，很多时候不能够把工艺和自控仪表很好的结合，更不用说工艺标准化了。由于在精细化工，个性化订单制造中，工艺标准化也是不现实的，所以也就很难程序标准化了，很多时候连个原则都没有，这就涉及到了工程管理，组织流程等更多问题

对于深耕每个行业的企业来说 模块化，标准化，任重道远，但是又 势在必行。

做出适合自己的标准块，主要是方便自己的工作，但是要推广适用广泛的标准化程序，就需要一番努力了，仅仅是思想的改变，就很困难~

标准化真不难么简单，我们用的国外的Omac架构，用在高端的运动控制器，现在想做个S7 1200的程序，本来设备也简单，然后架构套进去，随便写写PLC程序，工作存储区写满了，只能换1500，但是这种一般设备真没必要上1500，后面标准化那块不断删减，怎么简单怎么来，1200运行扫描时间还短。还有就是西门子写的TCP IP 的标准通讯块LCom库太大了，自己把那几个指令拉出来用省很多的工作存储区。所以还是要根据设备工艺来。