故事作者:万泉河

最近创作

看看TA的故事

【万泉河】《S7-1500 程序设计规范指南》与标准化编程的关系

已锁定

万泉河

  • 帖子

    10885
  • 精华

    132
  • 被关注

    892

论坛等级:至圣

注册时间:2003-06-06

钻石 钻石 如何晋级?

【万泉河】《S7-1500 程序设计规范指南》与标准化编程的关系

2289

6

2021-11-02 22:20:48

【万泉河】《S7-1500 程序设计规范指南》与标准化编程的关系

 

近日,西门子官方网站SIOS重磅推出了中文版的《S7-1500 程序设计规范指南》,立刻引发关注,成为网络热点。 几乎同一时刻内,众多公众号转载并发文分析。

 

我则是第一时间收到了文档原文。来源是我们标准化学习营的某位学员,可能同时也参加了西门子的培训课程, 从相关的社群中第一时间收到信息,就下载了发到了***中。

 

这个文档在官网的下载链接是:

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


 

这次发布的其实只是其中的中文版,是对原有的英文版的翻译。我们早在很久之前就关注看到过这篇文档。只不过这回中文版发表,读起来更容易。所以我在5分钟之内就匆匆读完了。

 

然后想组织标准化学习营的学员进行讨论,然而响应并不热烈。我自己从中摘取了几个论点,并自己做了些评价,但仍然没引起多少波澜。 总的来说,由于与我所主导的标准化的理念相差甚远, 学员们见到这样的规范,甚至有些不适应了。 不能理解它所主张的观点, 目的是什么。

 

而众多同行对此文档同时关注的主要原因,我猜大家是把它当成西门子官方所推出的标准化编程指南了。 有的公众号就开门见山介绍规范是开启程序标准化的大门了。

 

所以,我就自然有义务帮助分析一下它与标准化的关系,同时也算表个态,以避免产生更多的误会,让很多原本对我宣扬的标准化编程原理方法不甚理解的同行,误解为我一直在兜售的只不过是一本规范(或者成为风格指南)

 

这篇文档的中文版的题目叫设计规范,然而打开官网后的题目又叫做风格指南。


 

我个人也认为,叫做风格指南更为精确,更不容易带来歧义。 因为规范二字显得太正规,好像在给受众提出了一种强制限制。

 

而其实在全文中,最主要的观点就是提出了风格要统一,比如变量名等,文档中提出了多种可以采取的规则,然而,重点指出要统一,只能遵循其中一个规则,而不要同时全都遵循。

 

这种观点当然非常支持。 如果一个团队中,多个工程师平行协作,同时开发各种库应用,当然用同一个风格规则写成的程序,更有利于管理,维护和重用。

 

然而, 这样的团队,规模得是相当大了。 我在新书《PLC标准化编程原理与实践》中的分析统计,作为最底层的设备,比如电机类,各种接口形式的都算作一个类型的话, 整个行业的应用种类很容易会超过100种。 而如果局限于一个公司所专业从事的某个行业,就会迅速减少到不过区区十几种了。

 

由此,扩展到其它所有设备类型, 加起来不过几十种,如果考虑工艺设备,可能最多也就100个库足矣。

 

而对于PLC这种应用层级的设备库,逻辑通常都是简单到极点, 通常被专业的IT程序员鄙视根本算不得什么逻辑的。所以开发的工作量实在不可能动辄由几十乃至上百人来承担。

 

况且,所有的库函数一旦开发成熟,以后基本很少再升级改进,只需要被不断重复调用使用,就谈不上什么风格了。所以对一个成熟的公司的开发团队,需要的专职的研发工程师,数量肯定少之又少了。

 

我总结的传统的PLC设计架构的分工与标准化架构的分工的区别:



 



同样以6个定员来比较,标准化架构下,主力负责核心研发的工程师只剩下一个了。 甚至最低级别的从事简单重复工作的成员, 都不需要具备很多技能基础,所以自然也不需要进行什么风格约定。 他们要做的只是经过简单培训, 按照给的操作说明书,进行工作量输出即可。

 

所以如果还是采取的是传统的项目负责制,九龙治水,各管一方。那么风格统一自然相当重要,对公司内部人员互相协作,已经项目的维护等等,都不可或缺。 然而这个时候,要实现风格统一,难度就非常大。 《指南》中给出了很多互相不兼容的规则,公司内同样级别的高级工程师,谁也不服谁,有人选择A,有人偏爱B,都有道理,都符合指南规范,同时谁也没法指责对方违反规范,那么谁来做主摆平他们之间的矛盾呢?

 

据我所知,大部分的公司以九龙治水模式推行的标准化,只能被迫在项目执行过程中一再妥协, 每个项目都以能完成调试,顺利验收为目的了。 而风格统一则只能退居其次了。

 

然而,即便我举例的团队成员达到6人的情况,大部分的自动化设备公司,都很少能达到。 很多设备公司,设计团队规模都很小,而电气专业的工程师少到只有1-2人。 对他们来说与其矛盾重重地强调风格统一,还不如用立体架构替换原有的平行分工。

 

通过合理的立体结构的分工模式, 实现设计流程的标准化,设计流程实现标准化之后,可以融入到企业的生产管理流程,通过流程作业方式实现项目的设计生产和交付,而不再高度依赖工程师个人。

 

所以,总结《指南》中提及的标准化, 指的是团队生成的程序代码的标准化。

 

而我所推行的标准化方法,指的是生产流程的标准化。 更大意义上已经渗透到工厂的管理领域,而不仅仅是代码本身。

 

当然, 代码之中的规范, 绝大部分我是支持的,有一些也是我也在坚持和遵循的。但我从来不以此要求和约束跟我学习的工程师。比如许多工程师英语不算很好,我就鼓励他们在语法支持的前提下,尽量使用中文命名的各种变量,符号等等。而不会指责批评他们。只要有利于工作效率的提高,别的都不重要。

 

况且,我们做的标准化架构,程序逻辑高度内聚,接口极度简单,逻辑内部的实现方法,根本不需要其他人关心,而且也找不到人关心。 即便想找人帮忙CODE REVIEW,都没有条件呢!

 

这是他们看到了《指南》却无感的原因。

 

 

 

 


【万泉河】《S7-1500 程序设计规范指南》与标准化编程的关系 已锁定
编辑推荐: 关闭

请填写推广理由:

本版热门话题

网友专栏

共有3227条技术帖

相关推荐

热门标签

相关帖子推荐

guzhang

恭喜,你发布的帖子

评为精华帖!

快扫描右侧二维码晒一晒吧!

再发帖或跟帖交流2条,就能晋升VIP啦!开启更多专属权限!

top
您收到0封站内信:
×
×
信息提示
很抱歉!您所访问的页面不存在,或网址发生了变化,请稍后再试。