关于我

<2018年4月>
25262728293031
1234567
891011121314
15161718192021
22232425262728
293012345

最近来访

留言簿(0)

文章分类

文章档案


最新评论

1. re: 一颗螺栓的旅程
好文章,简洁明了,期待博主对于工厂其他系统的介绍,比如PPS等,期待中--shufeng437
2. re: 美国公路系统对IT系统的借鉴
分析的不错&nbsp;谢谢!--xixihahahehe

阅读排行榜

评论排行榜

随着AMAZON云服务的成功,许多人知道了BEZOSAMAZON内部推广WEB SERVICE的故事,从而佩服他的技术眼光和执行力。

如果说AMAZON.COM的成功是因为长尾理论,是对万货商店的技术实现,那么从某个层面来说,AWS(AMAZON WEB SERVICE)是另一种形式的长尾,只不过它销售的是IT服务而不是物理产品。

BEZOS基于SOA的思想,通过网络接口和服务打通了AMAZON内部的各种子系统,他把基础设施的接口进一步对外开放,从而形成了AWS的基础功能。

那么,SOA的思想,对于PLC编程有没有借鉴意义呢?

我认为是有的,尤其是对于具备MES复杂功能的IT PLC

本文以ANDON功能为例予以说明。

比如说1条线有20个工位,每个工位有1个拉绳、1个灯,每条线对应1套音乐播放系统。

那么基本逻辑过程应包含:

  • FOR循环遍历每个工位,找到每个工位拉绳//喇叭对应的I/Q地址。

  • 在工位逻辑里,找到拉绳的状态,并触发亮灯和播放音乐。

调用结构为:

FC-LINE                                //  线FC

---- FC-ST[1..20]                  // 工位FC

 

由于在工位FC里,I/Q寻址和读/写操作混杂在一起,因此工位FC没有和拉绳//喇叭的处理逻辑实现接口隔离。

如果我们分别针对拉绳//喇叭封装成3个服务接口FC

接口

输入变量

输出变量

说明

FC-I-ROPE

ROPE_ID

ROPE_FLAG

通用拉绳FC

FC-Q-LAMP

LAMP_ID


通用灯FC

FC-Q-SPEAKER

MUSIC_ID

SPEAKER_ID


通用喇叭FC

 

我们可以看到,对这3FC的调用不涉及I/Q的地址,从形式上看起来更象是逻辑服务函数,而对I/Q的寻址是FC内部的逻辑,不需要暴露在接口中。

经过上述转换后,程序的调用结构为:

FC-LINE                                                                               //  线FC

---- FC-ST[1..20]                                                                // 工位FC

-------- FC-I-ROPE(ROPE_ID, ROPE_FALG)                   // 拉绳FC

-------- FC-Q-LAMP(LAMP_ID)                                        // FC

-------- FC-Q-SPEAKER(MUSIC_ID,  SPEAKER_ID)       // 喇叭FC

 

我们可以看到,工位FC更加专注于业务过程,拉绳//喇叭FC更加专注于I/Q/写处理。

这样处理以后,不仅程序结构清晰容易理解,而且开发和维护都更加方便。

因此我们在开发PLC程序时,也要有SOA的意识,在开发一些功能或功能块时,要思考能不能将功能写成可供外部调用的FC,以及输入输出变量要怎么设置。

 

下面是AMAZONWEB SERVICE法则:

Amazon Web Service Laws:

1) All teams will henceforth expose their  data and functionality through service interfaces.

2) Teams must communicate with each other  through these interfaces.

3) There will be no other form of  interprocess communication allowed: no direct linking, no direct reads of  another team’s data store, no shared-memory model, no back-doors whatsoever.  The only communication allowed is via service interface calls over the  network.

4) It doesn’t matter what technology they  use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter.

5) All service interfaces, without  exception, must be designed from the ground up to be externalizable. That is  to say, the team must plan and design to be able to expose the interface to  developers in the outside world. No exceptions.

6) Anyone who doesn’t do this will be  fired.

7) Thank you; have a nice day!

 

 


发表于: 2016-12-14 19:59 阅读(216) 评论(0) 收藏 好文推荐

本博客所有内容,若无特殊声明,皆为博主原创作品,未经博主授权,任何人不得复制、转载、摘编等任何方式进行使用和传播。

作者该类其他博文:

发表评论(网友发言只代表个人观点,不代表本网站观点或立场。)

您尚未登录,请先【登录或注册