[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [science-iwg] Lab automation tooling
|
Hi:
As has been mentioned, integration is often necessary before you get to control and automation.
As soon as you have more than one device type you tend to have more than one vendor-specific bus or network protocol.
Natl.Instr.’s Data Sockets, IoT’s MQTT, EPICS’ Channel Access, Tango’s Corba-based protocol are all efforts to get to a common network protocol on which you can then base your control and automation. Which one is best for your lab automation depends on several factors.
NI’s Data Sockets basically defines which data goes via the TCP pipe. You could do a similar thing with Google protobufs. Your network clients directly connect to your network servers. That can be all you need if your control system stays within a room.
MQTT, JMS/Apache MQ, .. add a broker. That can be nice for home automation. Use some public broker in the cloud, and now you can control your fish tank and garage door via your cell phone from anywhere.
On the downside, a broker is a bottleneck on your data rates. A public broker could invite network attacks. Or imagine yourself in the driveway, within sight of the garage door, but to open it you need to reach a broker in the cloud, which right now is not accessible because of a pickup at your ISP. For plant automation you’ll thus prefer a local cluster of redundant & load-sharing brokers. JMS/Apache MQ can do that. EPICS’ Channel Access on the other hand does away with a broker. Clients dynamically locate their servers and then connect directly.
All of these approaches have their pros and cons, so you best look around for a little while, and then pick what suits you best.
-Kay
