2016年11月20日

PLC编程再思考之二:SOA


随着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套音乐播放系统。
那么基本逻辑过程应包含:
1)       FOR循环遍历每个工位,找到每个工位拉绳//喇叭对应的I/Q地址。
2)       在工位逻辑里,找到拉绳的状态,并触发亮灯和播放音乐。
调用结构为:
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!



Rethink PLC Programming (1) - MapReduce


We know that MapReduce is one of the 3 key success factors of Google(the other two are PageRank and BigTable), and now it has been widely used in Web App development and Corp System development.
This article is to describe usage of MapReduce in PLC Programming.
Now PLC and Automation technology are key factors in MES application, which enables MES to integrate to Control Layer and Device Layer. In some vehicle manufacturing plants, IT PLC or Master PLC is setup to integrate PMC/ANDON/AVI/EPS modules, and to read/write thousands of I/Q devices such as ropes and lamps.
In that case, for the purpose of MES business, key factors of IT PLC are business logic processing, and lots of I/O read/write.
Due to above reasons, lots of FB/FC will be running inside IT PLC, and will cause confusions if they are called by OB1 directly, and that requires us to design program structure carefully.
This article uses example of an ANDON demo, to show how MapReduce can be referenced in PLC Programming.

First, Map.
Map includes 2 segments: Program Structure and Relation Definition.
The below graph shows a very clear Call Relationship, and we only need to write business module statement in OB1:


We also need to define relationship, such as Line & Station, Station & Rope/Lamp.
The below graph shows, Array is used to build relationship between Line and Stations, and Rope Id/Lamp ID are configured as attributes of specific station:


So we can get all stations by tracing through Array, and get Rope ID and Lamp ID for each station.

Second, Reduce.
After ANDON Main FC(FC40000), we can find these business process:
-          Dealing with Line.
-          Dealing with Station.
-          Dealing with Rope.
-          Dealing with Lamp.

And we can write 4 FCs for them:
-          FC40100 for Line, including variables of: Line ID and Station Quantity.
-          FC40101 for station, including variables of: Station ID.
-          FC40111 for Rope, including variables of: Rope ID, Rope Flag.
-          FC40121 for Lamp, including variables of: Lamp ID.

After that, we get a very simple Call Structure:


With detail process:
-          FC40000 calls FC40100 for each line.
-          FC40100 calls FC40101 for each station.
-          FC40101 calls FC40111 of Rope.
-          FC40101 calls FC40121 of Lamp, based on Flag of Rope FC.

In conclusion, key factors of MapReduce in PLC Programming:
-          Clear and organized Call Structure.
-          Defined relationship in DB via Array and other tools.
-          Parameterized and reusable business FC.



PLC编程再思考之一:MapReduce


大家知道MapReduce是奠定GOOGLE成功基础的三大技术法宝之一(另外两个是PageRankBigTable),现在MapReduce方法论已经在网络开发甚至在企业开发中得到广泛的应用,而本文则探讨MapReduceMES PLC编程中的应用。
目前PLC和自动化技术在MES的应用中非常关键,通过对PLC的集成,MES得以打通执行层、控制层、设备层,在一些汽车制造公司,甚至专门搭建IT PLCMASTER PLC,以实现PMCANDONAVIEPS等高度复杂的业务模块,以及数以千计的外部设备(拉绳/按钮/)的集成。
因此,对于MES业务而言,IT PLC的重点不是过程控制,而是复杂业务逻辑的处理,以及大量I/O设备的读写。
由于上述原因,IT PLC内部运行的FB/FC就会非常多,如果不认真规划的话,OB1里调用关系就会非常混乱,因而需要对程序的结构进行严谨的设计。
本文试以ANDON为例,说明MapReducePLC编程上的借鉴。

首先是Map
Map应体现在两个方面,一是程序结构。
如下图体现了非常清晰的调用关系,在OB1中只需要做一些业务模块的声明:

第二个方面是配置关系的定义,如线和工位的对应关系,工位和拉绳/灯的对应关系。
如下图所示,可以用数组建立线和工位的对应关系,然后把拉绳和灯的编号作为工位属性配置:


因而我们可以用遍历数组的方式得到线对应的所有工位,然后根据工位属性得到对应的拉绳编号和灯编号。

再来看Reduce
FC40000 ANDONFC以下,我们又看到了以下几类业务处理过程:
1)       对于线的处理
2)       对于工位的处理
3)       对于拉绳的处理
4)       对于灯的处理
我们可以分别编写4FC来进行相应的处理。
1)       FC40100处理线的逻辑,包含两个变量:线编号和工位数量。
2)       FC40101处理工位的逻辑,包含变量:工位编号。
3)       FC40111处理拉绳的逻辑,包含变量:拉绳编号和拉绳状态。
4)       FC40121处理灯的逻辑,包含变量:灯编号。

经由以上处理,我们就得到了一个非常简洁的调用结构:


具体过程为:
1)       FC40000依次调用各条线FC40100
2)       FC40100调用本线对应所有工位的FC40101
3)       FC40101调用工位对应拉绳的FC40111
4)       FC40101根据拉强绳返回的状态值FLAG,决定是否调用灯的FC40121

总结一下,本文中用MapReduce处理PLC程序结构的要点:
1)       OB1/FC的结构要清晰、有层次。
2)       业务模型通过DB中的数组等结构体现关系。
3)       业务过程FC要参数化、可重用。