也聊聊“标准化”

从个人角度，简单说说论坛里面经常讨论的标准化，不喜勿喷。
这里所说的标准化一直在强调面向对象的思想，为了严谨点，特地百度了下，找了个个人感觉优缺点总结的比较好的说明，如下：
假如要乘出租车去机场。

面向过程的方式是：告诉司机，按照启动、右转、左转、停止等单独的接口去机场。这种方式需要乘客对自己的行为负责，乘客需要知道每个城市去机场的路线。

面向对象的方式是：告诉司机，请载我去机场。显然这种方法比面向过程的方法要容易得多。

在面向过程编程时，由于主程序承担的责任太多，要确保一切正确工作，还要协调各个函数并控制它们的先后顺序，因此经常会产生非常复杂的代码。很多时候变化是不可避免的，而功能分解法（面向过程思想）却又无法应对可能出现的变化。一旦修改代码，则bug越来越多。

因此，面对复杂的软件开发时，主程序不能做太多的事情，必须通过分离关注点进行职责转移。在上面的例子中，尽管具体实现在广州、北京或上海等不同城市中是不同的，但在任何城市都可以这么说，因为司机知道怎么去机场，这就是职责转移。

这个主要是面向高级语言的思想，这里面的对象太多，“万物皆对象”。
但是在自动化现阶段来说，常规设备用到的对象，一般包含：伺服电机（旋转、直线、DD）,电机（变频、调速、步进），气缸、油缸、电缸、机械手、阀门等执行机构。光电、模拟量、视觉、限位开关、测距等检测机构。
那么面向对象，以伺服电机、气缸为例。
先把伺服电机功能标准化，电机的检测，上下限位，近点信号，急停信号；电机的控制，点动，原点回归，点对点定位，连续轨迹定位，插补控制，同步控制，凸轮控制；电机的反馈，当前值，当前速度，定位完成，报警，报警代码，各种控制状态等。
气缸功能标准化，气缸动点，原点输出，动点、原点检测，动点、原点延时，报警延时。

那么总结下来，标准化，就是先把设备中用到的对象功能统一编程，然后根据设备工艺去调用。下面几张图是几个不同设备的简单截图，不能准确的说明面向过程和面向对象，但是可以简单的看出一些区别。

1、2、3/面向对象  将常用对象针对设备工艺用到的功能模块化编程，然后主程序根据设备工艺去调用。



4/面向过程   所有的动作都在主工艺流程中编写。

大家看了上面的程序分类是不是觉得这个其实没有这么复杂，就是自己经常用的编程方法。其实大部分工程师在工作当中，已经潜移默化的使用了面向对象的编程方式，因为“面向对象程序设计方法是尽可能模拟人类的思维方式，使得软件的开发方法与过程尽可能接近人类认识世界、解决现实问题的方法和过程”。

所以我个人理解的标准化，是根据设备工艺，将设备对应的执行机构根据设备需求，模块化（做成对应的功能块或者函数），然后主流程根据工艺调用执行机构的控制，监视执行结构的反馈或者检测部分，从而完成设备程序的编制。最终程序结构清晰，方便阅读，方便后续增改，方便别人手，方便同样工艺设备引用即是标准程序。

如果说一个标准化“思想”可以说在任何设备使用，在任何平台使用，那么没问题！
如果说一个标准化“程序或者功能块”可以在任何设备使用，在任何平台使用，那么多半是吹嘘骗人！
气缸不说了，太简单。就以伺服电机这个对象的标准功能为例，首先脉冲伺服上面，各个品牌控制的指令都是不同的，无法程序通用。总线伺服上面，西门子，AB，三菱，安川，贝加莱，倍福主导的EtherCAT系，底层协议不一样，程序更无法通用。
就以一个品牌来说，以三菱为例，你编制一个通用的伺服控制功能块的前提也要说是脉冲的FX系列、还是中大型PLC的*D75P(D)模块，还是Basic网络伺服系列，还是光纤总线伺服系列。另外一个通用的伺服控制功能块，如果包含所有功能（点动、定位、回原、插补、同步、凸轮），也是有弊端的，会使程序臃肿，不使用的部分占用大量PLC内存空间，使PLC的处理变慢。所以一个标准的功能应该根据设备工艺需求，编制对应功能的、精简的标准块。
所以建议大家如果要标准化，还是根据自己所使用的工控产品品牌，根据自己的设备工艺，花时间做出基础功能的标准块库。这项工作，在液晶、3C的设备大厂里面已经开展了多年，所以他们几百个电气工程师，人员流动很大的情况下，仍然可以保证设备开发的效率和基本稳定性。
以上仅代表个人观点，谢谢。