发表于：2023/11/25 15:44:20
#0楼
1125 【万泉河】永远不要做设备寿命排序
经常遇到有人咨询如何做设备寿命排序的问题。 或者另一种问法，如何得到最长运行时间和最短运行时间的设备编号。
而问一下目的， 通常就是恒压供水，多泵运行，有运行有备用，担心有的泵过度使用而提前寿命到期，或者有的泵长期闲置不用而搁坏了。末了还要加一句，客户要求的。
我因为素来反对这种控制策略，所以大家看我做过了那么多例子，但却从来不做寿命排序的问题。 不是做不出，其实按照模块化的框架，要增加这样的算法易如反掌。 恰恰就是因为担心我做了这样的例子， 会诱导行业走向这样的歧途。
因为，上述的要求， 哪怕是客户白纸黑字的亲口要求，其实是伪命题。
让我们来分析下这个所谓的客户需求。
在寿命排序策略里， 在每一次加减设备操作时，比如系统的压力低于了设定值，判定需要增加一台泵才可以满足系统需求， 那就挑选空闲泵之中的运行寿命累积最短的那一台。 而如果压力高过了设定值， 满足了减泵条件， 那就挑选在运行设备中累积寿命最长的那一台停止。
这个策略看起来完美。 但实质却未必如想象般美好。
我们所作的控制系统，其预期寿命肯定要大于机械设备的寿命的。 假设系统完工后10年，或者20年后， 真的有其中的某台设备寿命到期了，需要整体更换， 那么更换完成后， 这个运行策略还能满足吗？
换上了一台新泵后，这个位置的泵的寿命计数要不要清零？
如果不清零， 那设备的寿命累积值就不准确了。 而如果清零，那么清零后，按照既有的策略，既然它最年轻， 那么后面的工作就只有它努力来干了。它一直干下去， 直到和其它的叔叔伯伯一样老态龙钟之后，大家才终于全部心安理得平等了。
而这种按寿命排序的均衡策略，根据系统的特点不同，切换周期会不同，比如如果大致每天切换一次的系统， 那么最终各泵的运行时间都会相差24小时以内。 一次启停， 排序结果的两台泵， 哪怕寿命累积只差1分钟， 也一定会是小一分钟的这台被选中。 一秒也不行。
这让我想到了地图导航刚出来的时候，那个算法叫一个差劲，给你计算的最短路线可真的丝毫不差的比较出来了最短。 长途驾驶，国道一个大圆弧绕过了一个村庄，它竟然都会指挥你从国道下来，进入村庄内部， 抄村里的那条直线胡同。
上面分析的是某台泵偶然寿命到期先挂掉的情况。 而如果没有偶然情况，并且恰好这些设备的制造一致性非常好，寿命都能大差不差的同时挂掉。 那么你维持了他们相同的运行寿命的时候，那么其中一台挂掉的时候， 说明另外的N台也都差不多该同期寿终正寝了。有可能也就在这一两天。
而这种不管是恒压供水多用多备的系统，通常都是非常重要的系统， 在损坏的设备更换期间， 还要心惊胆战担心边上的哥们也随时可能挂掉，而这种系统的设备通常个头又很大， 比如几十吨，需要复杂的起吊设备， 一次更换要个把月才能完成。 如果真的在此期间连续发生泵损毁的情况， 那产生的灾难谁受得了啊！
而对维修部门来说， 一年或者半年内对同一个系统的设备马不停蹄连续更换，那也够忙的了，公司别的事都不用干了。
所以我们回到客户要求的寿命排序的时候， 其实要的不是严格的挑选最长最短，而只是大致均衡。 多台之间， 只要寿命累积差的不是太大即可。
而这其中最简单的策略就是跑马灯一般轮转。
把设备一次1，2，3…n , 1，2, 形成轮转， 正在运行的设备形成一条龙， 而需要增加的时候龙头方向前进一步， 而需要减少的时候， 龙尾部分也前进一步。
这样长久下来，只要所有设备都投入就绪， 那么它们的出力总是大致均衡的。 而即便有个别设备因为维护，错过了几个月的运行而显得寿命累积略少，但在寿命这个尺度上，这点时间根本不足以考虑。
而如此策略的实现思路，我早就在前面的文章里讲过了。
0609 【万泉河】宁做小白勿做小黑，一道测试题检测你是否适合做程序员
0707 【万泉河】更具程序员思维的U8轮巡题目答案
可以直接套用到这样的应用场景。
咱们再回过头看所谓的客户需求。
理论上讲， 咱们做技术的工程师与销售人员工作性质不同， 销售人员是跟人打交道的，而技术工程师面对的是冷冰冰的机器。那么你在做一台设备或者的时候，满足的并不是客户公司的某个个人的需求， 而是这台设备本身的客观需求。
设备需要咋样的策略和运行效果， 是一个客观问题， 是设计者和使用者共同面对的问题。从专业角度，客户的设计能力当然是比不上专业的设计工程师的，那么对需求的描述理解也并不见得就是最终的终极答案，设计者并不可以将纸面的需求简单作为设计参考标准， 而是需要消化吸收后再反馈确认。
所以，客户并不见得就是上帝， 并没有一言九鼎的威权，相反，大多数时候客户是需要被培训，需要再教育的。 通常情况下，只要是讲理的客户， 你只要把道理充分讲解给他们，他就一定会理解，接受。
从另外一个角度，我们有许多同行， 经常抱怨客户的要求总变，不能一次性把需求描述清楚，也是源于设计者对所设计的系统理解不够专业，把客户的需求当成了不可违背的指令。归根到底，责任其实还是在自己。
总而言之，客户这个上帝没那么威严，也没那么全能。
经常遇到有人咨询如何做设备寿命排序的问题。 或者另一种问法，如何得到最长运行时间和最短运行时间的设备编号。
而问一下目的， 通常就是恒压供水，多泵运行，有运行有备用，担心有的泵过度使用而提前寿命到期，或者有的泵长期闲置不用而搁坏了。末了还要加一句，客户要求的。
我因为素来反对这种控制策略，所以大家看我做过了那么多例子，但却从来不做寿命排序的问题。 不是做不出，其实按照模块化的框架，要增加这样的算法易如反掌。 恰恰就是因为担心我做了这样的例子， 会诱导行业走向这样的歧途。
因为，上述的要求， 哪怕是客户白纸黑字的亲口要求，其实是伪命题。
让我们来分析下这个所谓的客户需求。
在寿命排序策略里， 在每一次加减设备操作时，比如系统的压力低于了设定值，判定需要增加一台泵才可以满足系统需求， 那就挑选空闲泵之中的运行寿命累积最短的那一台。 而如果压力高过了设定值， 满足了减泵条件， 那就挑选在运行设备中累积寿命最长的那一台停止。
这个策略看起来完美。 但实质却未必如想象般美好。
我们所作的控制系统，其预期寿命肯定要大于机械设备的寿命的。 假设系统完工后10年，或者20年后， 真的有其中的某台设备寿命到期了，需要整体更换， 那么更换完成后， 这个运行策略还能满足吗？
换上了一台新泵后，这个位置的泵的寿命计数要不要清零？
如果不清零， 那设备的寿命累积值就不准确了。 而如果清零，那么清零后，按照既有的策略，既然它最年轻， 那么后面的工作就只有它努力来干了。它一直干下去， 直到和其它的叔叔伯伯一样老态龙钟之后，大家才终于全部心安理得平等了。
而这种按寿命排序的均衡策略，根据系统的特点不同，切换周期会不同，比如如果大致每天切换一次的系统， 那么最终各泵的运行时间都会相差24小时以内。 一次启停， 排序结果的两台泵， 哪怕寿命累积只差1分钟， 也一定会是小一分钟的这台被选中。 一秒也不行。
这让我想到了地图导航刚出来的时候，那个算法叫一个差劲，给你计算的最短路线可真的丝毫不差的比较出来了最短。 长途驾驶，国道一个大圆弧绕过了一个村庄，它竟然都会指挥你从国道下来，进入村庄内部， 抄村里的那条直线胡同。
上面分析的是某台泵偶然寿命到期先挂掉的情况。 而如果没有偶然情况，并且恰好这些设备的制造一致性非常好，寿命都能大差不差的同时挂掉。 那么你维持了他们相同的运行寿命的时候，那么其中一台挂掉的时候， 说明另外的N台也都差不多该同期寿终正寝了。有可能也就在这一两天。
而这种不管是恒压供水多用多备的系统，通常都是非常重要的系统， 在损坏的设备更换期间， 还要心惊胆战担心边上的哥们也随时可能挂掉，而这种系统的设备通常个头又很大， 比如几十吨，需要复杂的起吊设备， 一次更换要个把月才能完成。 如果真的在此期间连续发生泵损毁的情况， 那产生的灾难谁受得了啊！
而对维修部门来说， 一年或者半年内对同一个系统的设备马不停蹄连续更换，那也够忙的了，公司别的事都不用干了。
所以我们回到客户要求的寿命排序的时候， 其实要的不是严格的挑选最长最短，而只是大致均衡。 多台之间， 只要寿命累积差的不是太大即可。
而这其中最简单的策略就是跑马灯一般轮转。
把设备一次1，2，3…n , 1，2, 形成轮转， 正在运行的设备形成一条龙， 而需要增加的时候龙头方向前进一步， 而需要减少的时候， 龙尾部分也前进一步。
这样长久下来，只要所有设备都投入就绪， 那么它们的出力总是大致均衡的。 而即便有个别设备因为维护，错过了几个月的运行而显得寿命累积略少，但在寿命这个尺度上，这点时间根本不足以考虑。
而如此策略的实现思路，我早就在前面的文章里讲过了。
0609 【万泉河】宁做小白勿做小黑，一道测试题检测你是否适合做程序员
0707 【万泉河】更具程序员思维的U8轮巡题目答案
可以直接套用到这样的应用场景。
咱们再回过头看所谓的客户需求。
理论上讲， 咱们做技术的工程师与销售人员工作性质不同， 销售人员是跟人打交道的，而技术工程师面对的是冷冰冰的机器。那么你在做一台设备或者的时候，满足的并不是客户公司的某个个人的需求， 而是这台设备本身的客观需求。
设备需要咋样的策略和运行效果， 是一个客观问题， 是设计者和使用者共同面对的问题。从专业角度，客户的设计能力当然是比不上专业的设计工程师的，那么对需求的描述理解也并不见得就是最终的终极答案，设计者并不可以将纸面的需求简单作为设计参考标准， 而是需要消化吸收后再反馈确认。
所以，客户并不见得就是上帝， 并没有一言九鼎的威权，相反，大多数时候客户是需要被培训，需要再教育的。 通常情况下，只要是讲理的客户， 你只要把道理充分讲解给他们，他就一定会理解，接受。
从另外一个角度，我们有许多同行， 经常抱怨客户的要求总变，不能一次性把需求描述清楚，也是源于设计者对所设计的系统理解不够专业，把客户的需求当成了不可违背的指令。归根到底，责任其实还是在自己。
总而言之，客户这个上帝没那么威严，也没那么全能。
PLC标准化编程
