There are several popular and proven full-stack solutions
available like EPICS, Tango (http://www.tango-controls.org/) etc.
and several of them have multi-language bindings for client
applications.
But I would assume that in most environments the actual control
bus/system is already in place, and as an application provider you
don't get to define the complete architecture.
Encapsulating control & communication protocols is a
traditional discipline in the integration and automation space
also for large research environments.
It seems IoT, with its many device types and protocols and very
ambitious goal to connect everything, has become an umbrella for
collecting and evolving know-how, tools and architectures for
distributed systems. It is also reaching inside traditional
domains now like factory & research automation, control etc.
(industry 4.0, smart factories etc)
So a close collaboration, integration and exchange of ideas/tools
between the Science and IoT WGs would be great!
cheers
erwin
Op 29/04/2016 om 21:22 schreef Ian
Skerrett:
Eclipse
IoT WG is doing lots in this space. I took at quick look at
the EPICS summary presentation and Eclipse NeoSCADA seems to
be the closest. https://eclipse.org/eclipsescada/
If
you want some simple messaging capabilities I would look at
our MQTT projects: Paho http://www.eclipse.org/paho/
and Mosquitto http://projects.eclipse.org/projects/technology.mosquitto
If
you are looking for device management, I would suggest you
look at our LWM2M project: Leshan http://www.eclipse.org/leshan/
and Wakaama http://projects.eclipse.org/projects/technology.wakaama
I
hope this helps.
Ian
Has anyone looked
at the work IoT are doing (https://projects.eclipse.org/projects/iot)?
Presumably they’re trying to accommodate millions or billions
of devices in a very distributed manner. Seems like there is
some overlap here.
Greg
Hi:
while
you know that I am doing scripting a lot, most
scripts in our
company need to communicate with lab equipment
(oscilloscopes, power
source units, waveform generators, ...). We are
doing this using VISA,
IVI and typically National Instruments drivers.
We are accessing all
this stuff from EASE scripts, using a self
written intermediate layer in
C# to access hardware busses like GPIB. I am
wondering how the other
science group members do this as I guess some of
you will have similar
requirements. Are you all building your own
stuff or is there a common
approach available already?
Not sure about a good/easy/obvious answer for
basic lab automation.
On a larger scale, we use EPICS (http://aps.anl.gov/epics)
to perform the control, automation, logging,
remote display, ...
Slides with details from a local training session:
https://ics-web.sns.ornl.gov/kasemir/train2013/
But that's for larger setups with 100000+
network-accessible devices, requiring reliable
operation for years, 24/7.
It's a big step from a PC running LabView, talking
to a signal generator on the same table, to
"PlantView".
Still, one key idea is that you will likely soon
need a distributed system.
Starting with for example LabVIEW, it's easy to
combine device access, automation, logging, user
interface all in one program.
Perfect as long as it all fits on your table, but
doesn't scale.
Plus what if somebody closes the "user interface"
-> The "automation" is also gone.
What if two people want to open the "user
interface", for example two people each in their
office -> Is the automation now running twice,
for example each incrementing something, which as
a result rises twice as fast as intended?
Pretty soon a distributed setup makes sense:
Front-end computers, often without
keyboard/display/hard drive, talk to your hardware
and make the information available on the network.
Can be Raspberry Pi, Linux server in some rack,
maybe RTLinux or some other real-time OS.
Some automation like PID control runs directly on
these front-end computers. Or via the network on
other computers if you can accept the network
latency and instead want more flexibility like
update the higher level automation without
affecting the faster PID control that's on the
front-end.
In EPICS, the above functions are called
Input-Output-Controller (IOC) and the network
protocol is Channel Access.
Python can also be used as a Channel Access client
and/or server to read and transform raw data into
more interesting information, or to perform
automation.
Then you have tools like CS-Studio for the user
interface. Ideally, it's just the user interface:
One or more people can open it to see what's going
on, push buttons or enter new values which are
then sent via the network to the IOCs or
python-based servers.
Automation, logging, .. are fully functional even
while nobody's looking.
So the basic suggestions would be:
Python is likely a very good choice for
automation.
But don't put it into the user interface.
Allow the automation to run independent from the
user interface, ideally on a different computer so
an end user crashing the display computer doesn't
affect the rest of your control system.
Tie the front end, automation, user display
together with a network protocol.
EPICS' Channel Access has been in production for
decades on almost every continent, but you can
also google for internet-of-things related ideas
like the MQTT protocol.
Cheers,
Kay
_______________________________________________
science-iwg mailing list
science-iwg@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/science-iwg
_______________________________________________
science-iwg mailing list
science-iwg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/science-iwg
|