随着AMAZON云服务的成功，许多人知道了BEZOS在AMAZON内部推广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 |
我们可以看到，对这3个FC的调用不涉及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，以及输入输出变量要怎么设置。
下面是AMAZON的WEB 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! |