有没有一个通行的标准，可以用以所有的工控场景和工艺要求？
我想，这是没有的，因为每一个行业，每一台设备(项目)的要求都不一样，无法用一个通用的框架来覆盖所有的行业。要是有这个框架的话，那么汽车行业的Sicar和包装行业基于ISA88的PackML的标准就不会存在，也不会在行业中有如此之大的影响。
除了上述的一些行业标准外，也有一些网上的自创的标准方法和架构，这些内容都是合理的，但并不存在一个方法，拥有之后就会无敌一样，能提升多少年的功力和价值。你仔细看这些内容，都是合理的但往往以偏概全，用一些夸大的词汇和夸张的描述宣扬一个点，对于标准架构要达成的目标往往一概不提。甚至再仔细思考就会发现，这些所谓的标准程序要么是基于西门子的程序库改进而来，要么是从PCS7的一些方法转换到PLC编程，用PCS7中的一些套路装扮一下，冠以标准化的外衣进行推销。
PCS7主要用于过程行业，在PCS7实施过程中有个类似”点数”的概念，这些点数的计算都是基于执行元件，比如电机、阀门等等对象，所以一般的所谓的标准化方法中，都是以电机、阀门等作为控制对象考虑的，但将这样的思路用于离散行业，就会发现往往对象不是这么简单。
过程行业中电机的控制只是一些不同模式、不同条件、不同要求下的启停控制、速度控制等。即使有设备接口要求，也是简单的电机之间的互锁等控制内容，所以在PCS中可以看到一类电机的控制接口和参数非常多，引脚特别长，在组态编程的时候需要基于工艺去勾选不同引脚。
但过程行业的控制不会涉及到过多的其他方面的控制，比如基于工艺的前后设备之间的逻辑控制、基于工艺的位置定位控制以及相互同步的控制及相关精度要求……这些控制内容，往往工艺逻辑比较复杂，还是套用PCS7的思路或者架构，很难实现标准化编程。
若以PCS7中的电机、阀门为对象思考的程序，其思维或者标准化的水平还是在Control Module(CM)的层级。
标准化编程不是一蹴而就的，往往在某个行业都是先有基于要求的手动编程开始，逐步对工艺系统化后，开始进入模块化的编程阶段，这也是目前很多公司和工控人士达到的水平。模块化程序结构只是标准化编程的一部分，在模块化程序结构的基础上，增加数据接口、设备接口、状态接口等以及整个架构的数据的自动交互，达到整个架构中，只需要考虑设备工艺程序，并不需要处理数据交互的程序，这些架构中的数据交互会自动生成。
标准化除了上图的内容以外，还不一定能实现标准化，因为程序的管理，测试的流程等都决定了标准化的实施的质量和结果，所以还必须在文档、测试以及整个工作协作方面的流程，才是保证整个标准化实施的关键内容。
那有没有一个标准的程序架构，可以用以大部分的工控场景和工艺要求？
我想，这是有的，因为除了工艺我们无法预知外，我们可以将程序要实现的其他内容进行总结和思考，形成一个标准的程序架构。
对于任意的设备(离散行业)或者项目(过程行业)，我们的控制系统主要实现两部分的内容：
1. 控制柜等硬件的程序
2. 设备、指示灯、按钮等控制对象的控制程序
而对于设备的程序来说，还是以下图的一个模型，实现模型中的内容，包括控制指令的标准化、事件(Event)的标准化、模块化(Identity，设备分层)的标准化、设备性能(Performance)的标准化、参数的标准化以及设备接口(控制逻辑)标准化、HMI报警文本(基于西门子的HMI)的标准化、CM设备的标准化(即目前很多人做的标准库)等内容。
除了上图的设备标准程序模型外，在程序中还需要处理其他数据(最好都是自动处理)，这就需要一个标准的程序架构，用于这些所有数据和设备程序的一个结合体。
在基于CPG程序库的基础上，我已经将其整理成一个可以实际使用的基于上图的设备模型的标准程序架构，如下图所示。
标准程序架构的Main程序都是一样的，主要为三个部分：设备控制程序、事件处理Event、系统信息读取。
上图有两个程序，主要是有两种控制指令标准化的程序不一样。CPG的模式状态机就是基于ISA88的模式状态机的原理，此类设备主要符合如下特征：
1.只有一个UN的设备，也可以理解为单机设备
2.虽然有多个UN的设备，但由于产品特殊性以及工艺要求，所有UN的状态和运行都必须一致，比如一台抽纸叠纸机、飞据设备等等。
3.基于设备管理要求的统一使用符合OMAC标准的设备。
模式状态机的模式状态的切换原理如上图，状态完成是指模式状态机下面所有设备的状态都达到，状态的切换是通过模式状态机程序根据实际状态反馈和控制指令的结合，转换当前状态并下发到UN下面的设备。
模式状态机要求所有设备的状态是一致的，但这在一些项目上和大部分生产线上，按照模式状态机的要求处理的话，设备或者产线的生产节拍就无法提高，有些特殊工艺的产线和设备，还可能会由于不断的一些状态变化导致设备和产品的损坏。
这些设备或者产线，他们设备的状态并不是一起转换的，都是基于自身的控制状态自我切换，所以就有基于CPG的模式控制机的标准架构程序，这个的Event的处理是一样的，只是在模式状态切换部分不一样，这也导致了一些相关的程序有不一样。
模式控制机只负责控制指令的下方，设备的状态切换由设备基于自身情况自我决定，并将所有设备当前状态以或逻辑上传到模式控制机。
模式控制机会基于当前反馈的状态，传递合理的控制指令，如下说明：
启动指令:
至少有一个设备停止的情况下，才能生成新的启动指令
停止指令:
至少有一台设备已经启动，才能生成新的停止指令
复位指令:
至少有一台设备已经产生故障，才能生成新的复位指令用于故障复位
目前，两种不同控制指令处理的标准程序架构已经完成测试并可以用于实际项目，如上图。上次的一个标准程序架构的实际案例速览，也是这套标准程序架构的实际应用，这也会在此系列文章发布后续陆续在公众号发布。
基于这个实际测试后发布的标准程序架构，结合里面的模块化以及事件管理，可以实现工控编程的低代码，实现工控的标准化编程，提高整体的工控编程的水平。整个标准化程序架构说明及使用，在本文的阅读量达到1000(能到5000最好)以后，公众号将会陆续发布。
但标准化编程只是一个技巧，更多的目的是用于效率和质量的把控，这些都是管理范畴，目的是能大批量复制质量可靠的产品，所以对于个体工程师来说，更多需要关注的是硬件知识的学习，只有硬件知识有足够的深度，编程的质量才会越来越好。
比如西门子的开放式用户通信中有TSEND_C的指令，这个指令可以基于TCP/IP的通信，也可以用于UPD的通信，那这两种不同的通信方式下，TSEND_C指令中的DONE信号的意义是不是一样的？
留下一个简单的问题，希望大家明白硬件知识比编程更重要。
