标准化编程的一点实践

论坛里有几篇关于标准化编程的帖子

把工艺理解并拆分成，位于不同层级的抽象设备（单元化的逻辑块）之间的，自顶向下的调用结构。凡逻辑皆设备，没有存在于设备之外的逻辑。这包括最底层的硬件设备、小工艺单元，大工艺单元，一条生产线等等，看你的项目有多大和工艺层级的数量需求。

一般来说，程序员把某一部分逻辑单独提取出来做个块（抽象设备）相对容易。但经常遇到的情形是，抽象设备之间存在互锁关系，例如：设备x1、设备x2的状态都要启动，且设备x3、设备x4等的状态都要停止，设备y才能启动，否则停止。

互锁关系中，前置条件设备的数量是不等的，但他们的状态无非是常开和常闭中的一种。有时候会遇到数值大小的前置判断，可以在抽象设备内部转化为开闭状态输出。

把互锁这种关系结构，也抽象成一个设备，写成一个块。

这个块，比如有10个常开和10个常闭引脚输入（根据自己的业务情况，引脚数量足够用就行）。常开引脚默认值是1，常闭引脚默认值是0。在块里面写一句话，把所有这些常开常闭串联起来，然后线圈输出。

在各种不同的互锁场景下，调用这个块的时候。把有关联的前置设备状态，按照是常开还是常闭的区别，分别关联到引脚上。因为数量不定，必然会有一些用不到的输入引脚闲置，它们的数值或者是1或者是0，在运行中保持不变，等于不存在，就不会影响整体互锁逻辑输出。这个块的输出就关联到被调用设备的启停引脚。

这样可以一个通用的方式来处理，千差万别的工艺被分解后的单元之间的纠葛。会简化整体工艺分解的思路和迭代效率。

 嘿嘿，你的帖子看的比较舒服。

来开开眼界

学习了，感谢分享

我觉得面向对象， 重载思想的解放， 如果搞出一个固定的套路，不过是陷入另一个窠臼。 着实不可取。

关于提高代码质量的文章， 到处都是。 重在吸收其思想， 而不是扔掉旧的枷锁，又套上新的枷锁。 

标准化啊？

按我的理解，Modbus通信就是一种上位机与下位机通信交换数据的标准吧。标准化只定义了硬件层、数据结构、通信逻辑而已。至于应用层怎么使用？怎么实现通信逻辑？交换什么数据？完全由用户自己发挥。别想着用Modbus标准后标准就会自动为你交换数据？做梦呢。

标准这种东西，不要被别人铺天盖地的洗脑带歪了，别人说的标准不一定适合你。难道不用别人卖的标准就程序就不能用了么？不是的，只是大家的标准不同，目的都是实现功能而已。标准对于应用并不是必须的。

只是有了标准，可以减少错误、可以节省ROM、可以使程序逻辑更直观、标准成熟后可以节省大量的时间精力、可以让程序员更专注与实现应用而不是浪费时间在实现“Hello World”，好处太多。代价嘛就是需要不少额外的RAM以及不能随心所欲的写程序了。

没有别人的标准，世界依然多姿多彩阳光明媚，条条大道通罗马。

10多年前公司花几万到西门子楼宇培训时，就是标准化编程。这下年下来，结果就像4楼大佬说的，只是从不停的套上枷锁罢了。现在嘛，都随心所欲算了。西门子提供这么多的库、这么多的FC、FB，根据应用封装一下更通用些，不想再套枷锁了。

如果不懂4楼大佬说的？建议认真学习C++，学懂了C++后不需要别人的标准，你自己累计下来的标准更适合你。

至于老万的都是说很表面的东西？我没钱没看过没买过，不清楚实现细节不折腾这些咯，我不想套枷锁咯。

ps:算了，都不知道胡扯什么乱七八糟的了。

大佬这样说，可能我们说的不是同一个东西。

我说的标准化比如：SMART的IO不提供In.m这种直接的变量，而是只提供像S_ITR这类的IO库，然后S7 200跟SAMRT的库接口又相互不兼容，然后自己根据官方库封装的库又不能直接用到更新的硬件平台上之类的？？

不为了标准化而标准化，

软件的标准化还是很难，我们公司提了十几年，期望通过标准化，来提高程序的复用率，减少开发时间。但总的来说，效果不好。

不同的行业应用不同，我是做非标设备的，每一种产品开发一次最多生产不超过两台。几乎每天都在开发的路上。对于我来说标准化只能是增加工作量。

给你点攒，目前我也是用类似的构架，回头整理下

 标准化，感觉有时必须的

项目树的结构应该与工艺无关，而是体现设备分类。工艺块按照设备对待并分组。

这样不管是天差地别的项目，只要用的电器设备是相似的，项目树结构就大体一致，尽量不因行业领域不同和工艺变化而变化。

这样的想法是因为：不管有多少种不同的行业和应用，大家用的具体电器设备无非就那么多种类。应该用共性来构造基础管理结构，以求管理框架的稳定和普遍适用性。具体要看你自己在项目经历中，积攒的设备单元库有多丰富和庞大。如果这世上所有的电器设备都已经被你用遍并封装入库了，那你能建造适应所有项目的项目树，这个夸张是为了说明追求的效果。

众多IO应该按照现实中的物理状态，封装成对应的设备块，比如指示灯、变频器。尽管各自的IO种类和数量不同。指示灯，一个开关，也要封装吗？因为有可能不同的单元都会用到这一个开关，这就出现了耦合纠缠。你可能说在当前项目中它只有一个用途，但这里说的是标准化，不能排除任何未来视野中的可能性。一个阀门因为不同的工艺纠缠，它在什么时候可以打开或不能打开受到多种耦合制约，这是常见的场景。我自己是用一个FC封装了开关设备，这样很多简单的开关类型设备就用这一个FC就行了。至于它在具体项目中到底代表什么，就看它管脚关连的DB变量的不同了。

每个物理设备和工艺单元，都有自己单独的DB。DB是分割整体工艺和封装分割后的工艺单元块之间耦合的地方。工艺格局细节体现在DB中，也就是对应到诸多FB和FC的接口分割。工艺的变化体现在：新的FB或FC出现并被分组；DB中新的子结构出现；也就是为新的FB或FC定义了接口。

各个单元块，无论物理设备还是工艺，都有自己专门处理与其它单元之间耦合的标准结构。工艺的差别体现在与这个标准结构衔接的变量不同。

关于IO可以分成两类来理解。一类是我们常见的底层设备IO，包括与设备的通信都算。另一类是与第三方节点比如触摸屏、上位机，云等等，之间的数据往来行为。对于PLC而言，它与设备IO之间的数据往来，与它和上位节点之间的数据晚来，没有区别，都是数据交换。这意味着PLC与HMI之间的衔接单元可以被当成具备IO能力的一种抽象设备来封装对待。

每一个PLC中的设备块和工艺块，都应该有自己的一个专门负责向上位接口进行数据交换的块。这样你可以在触摸屏上把PLC中的每一个设备块或功能块之间的耦合断开，进行单元调试。也可以在HMI上选择把不同范围的单元块关连起来，进行分片分区的工艺联动调试。这样单独设备或单独工艺片的问题可以被分离和分不同层次在界面上分别观察。即使工程师不在现场，工人也能调试，并能准确反馈问题所在。

现场可以先在HMI上选择把所有工艺耦合断开，测试单独的阀门、电机，传感器等物理设备是否正常工作，验证现场电气连接和机械连接的正确性。等把所有的单独硬件验证完毕，可以关连第一层工艺范围内的单元，进行局部联调。

这个局部联调就是在验证某个工艺块。因为一个工艺块就是多个下层设备块或子工艺块的协调工作的封装。如果所有单元之间的耦合全断开，就没有任何工艺会被执行了，尽管工艺块都在。第一层验证之后，是第二层，更高层，一直到系统整体联调。

封装既是提取隔离了共性，也是隔离封存了变化，这怎么理解？一个封装好的单元，不管你把它放到任何行业和工艺中，它就是它自己这种功能块，这是它的不变性。但是一个功能块的内部功能是可以演化的，比如它对应到同一种设备的不同品牌上，会带来功能的差异化。它所有的自身变化被封存在内部。

上面这段废话的意思是说，工艺块之间的耦合变化同样可以找到合适的标准结构来封装，而这才是框架稳定的核心

写的还行啊

点赞，标准化不仅仅是面向对象

标准化后的整个项目由若干个平行单元构成。单元分组，用不同的Loader加载到OB。

Loader内部的每个Region是一个单元。可以是设备单元，可以是工艺单元。

从项目树的管理方式看不出工艺到底是什么。工艺是通过各单元之间的耦合体现的。

每个单元里面，都是一个5层结构体：

• 界面输入层（外部数据输入PLC内部）

• 耦合层（单元之间的关连，也就是系统工艺）

• 命令状态层（单元实体的控制，包括局部工艺）

• 设备或工艺实体层（单元实体的执行）

• 界面反馈层（PLC内部数据输出至外部）

集中处理的东西，比如报警、PLC内外交互接口等，可以分散在不同单元的相同层里。

整个标准化结构已经完成，与工艺和行业无关，细节还需打磨润色。目前工作内存比之前非标准做法多出20%。

学习一下！有些行业好像不好标准化吧！

工艺分为两种

1、系统工艺，它是多个单元的联合使用。它并不依赖于某个特定单元存在，所以它自己适合做为一个独立单元存在。

2、局部工艺，它是某个单元的特定使用方式的封装。它依赖于某个特定单元存在，所以把它放进所属单元内部的第三层，做为某个单元命令的扩展实现。

由于单元都统一为五层结构，实践中会出现大量相似的处理手法。这些共性会生成一些通用的工具，用来描述界面接口，单元耦合，命令方式等。

标准化的核心在于仔细品味事物之间的关连特点。

比如：有的时候，一个单元会启动另一个单元，之后会主动停止它。但有的时候只是启动这个单元，不会主动停止它，这个单元会自己停止。也有可能一个单元只是去停止另一个正在工作的单元，比如出现报警了。也有的时候，一个单元的输出需要等一段时间才触发另一个单元的工作，等等。

这些各种关连场景仔细研究分类之后，可以通用化的手段把他们都包含进来。

在实践中感觉最有意思的一点是：以前的工艺中，哪怕是非常简单的一个功能，也就是随口的一句话，都被分解为多个的单元耦合。分解后的画面更纯粹了，看着很舒服清澈。越是非常熟悉的东西，它的底层的内部的真相，未必一定如习以为常的想象的那么必然。都是相对的，可以变化的。因此项目中所有的细节元素都被多次换角度再质疑、思考、提纯。

好文好帖

KEEP GOING

消息上浮，这是我在标准化结构中嵌入的一种机制。效果不错。

含义：任意单元A的正常运行状态或者故障报警，都会通知到所有直接或间接依赖于A的其它单元。尤其当A是主要被调用或唯一被调用单元。当出现故障，这些A的上级单元也要被通知和同步禁用。

每个单元的操作都受到其它单元状态的不同影响。每个单元内部根据这些消息的重要性，可以选择是否继续上浮消息。

比如一个单元B调用了5个其它单元，其中某个单元C出现了故障。如果C是次要功能，不影响B的核心工艺，可以选择不继续上浮。如果C单元很重要，消息必须上浮，这会导致B也会被禁用，或者进一步B的上级调用单元也会被禁用。单元状态消息，就是在这样的必然性网络中传播的。

这样任何一个单元引起的变化会同时向上向下传播。任何一个单元随时了解它所调用的单元的当前状态。实现了信息对称性。