Dear Christian,
As Jay says we are working quite a bit
on control systems at
Diamond
Light Source. For instance we are adding developments to
the
Control Systems
Studio product which is a collaboration for large scale
control front end, for example we use it driving EPICS. Kay
has already given some advice about this which I agree with as
far as I am familiar with the subject. We also have a group
for data acquisition which combines control with scientific
requirements, the group where I work. A third group provides
data analysis which is mixed with the acquisition to provide a
scientifically relevant front end.
There must be synergy with IoT and
science groups for controlling hardware and completing higher
level science. One possibility might be the recent workflows
developments with
Triquetrum,
perhaps actors could be written for IoT devices?
At Diamond Light Source we will shortly
propose a new science project to do part of this bridging;
called Scanning. This scanning project will provide algorithms
for coordinating hardware and visualising scientific results.
It will depend on the January project for its data layer. It
allows any hardware to the driven, so things like MQTT devices
and EPICS motors can be integrated along with a host of
detector devices. It incorporates a NeXus writing layer for
creating binary data files.
NeXus
is a self-describing open data format based on HDF5. The files
that can be visualized and analysed by many different program
DAWN
and to some extent
ICE do; there are many others. It incorporates a python
layer for running the scans and connects to commercially
available control devices such as the new
Zebra box
which combines an FPGA with an ARM processor.
I appreciate these things are a bit out
of your field. However the group offers a friendly way to
discover what people are doing and to learn more.
All the best,
Matthew Gerring
Diamond Light Source
-----Original Message-----
From: science-iwg-bounces@xxxxxxxxxxx
[mailto:science-iwg-bounces@xxxxxxxxxxx] On Behalf Of
Benjamin Cabé
Sent: 30 April 2016 15:38
To: Science Industry Working Group; kura-dev@xxxxxxxxxxx;
jconlon@xxxxxxxxxxxx
Subject: Re: [science-iwg] Lab automation tooling
FWIW the Eclipse Kura IoT project is
currently looking at leveraging WireAdmin to do exactly what
you described :) They call it "Kura Wires"
The idea is to use WireAdmin on top of
the existing many services that Kura includes for accessing a
system’s GPIOs, communicating using IoT and Industrial
protocols, configuring components, etc.
My understanding is that it’s available
in a branch of the project right now, but they are working on
documenting what’s there so that people can give it a try.
See https://github.com/eclipse/kura/issues?q=is%3Aissue+is%3Aopen+label%3AWires
I’ve also cross-posted to the developer
mailing list of the project.
Benjamin –
Le 30/04/2016 16:27, « John E. Conlon »
<science-iwg-bounces@xxxxxxxxxxx
au nom de jconlon@xxxxxxxxxxxx> a écrit :
>One should also consider the OSGi
WireAdmin specification. It is a DAG
>Dataflow programming model and was
intended for devices, sensors and
>actuators (aka IoT). It has been
astonishing to me with all the talk
>of IoT, that very few people have
noticed this important specification
>and implementation. OSGi Components
utilizing WireAdmin, ConfigAdmin,
>MonitorAdmin and Declarative OSGi
services make very nice decoupled
>plugins that can be wired together
by the user to create DAG dataflows.
> With these existing
implementations and a simple controller to do
>the wiring I successfully
implemented a lab automation project and
>other sensor/actuator projects.
Have this working within an RCP or in
>a standalone Server. The RCP based
implementation utilized a Zest
>viewer to visualize the DAG and the
statistics generated from the different
>plugins. For a lark I called it
the Information Router aka - iRouter.
>
>If there is an interest I would be
happy to make the source code
>available. Again this is mostly
pure OSGi.
>
>As a counter argument I am looking
at the Apache NiFi which also uses a
>DAG Dataflow model - and unlike my
iRouter and WireAdmin currently has
>a very big user community.
>
>
>
>John
>
>--
>{ name : "John Conlon",
> title : "Principal
Consultant",
> phone : "(608)620-4938 x100",
> cell : "(608)620-8867",
> email : "jconlon@xxxxxxxxxxxx",
> web : "http://www.verticon.com"}
>
>
>On 04/30/2016 06:15 AM, Kasemir, Kay
wrote:
>> 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
>>
_______________________________________________
>> 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
_______________________________________________
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
This e-mail and any attachments may contain
confidential, copyright and or privileged material, and are for
the use of the intended addressee only. If you are not the
intended addressee or an authorised recipient of the addressee
please notify us of receipt by returning the e-mail and do not
use, copy, retain, distribute or disclose the information in or
attached to the e-mail.
Any opinions expressed within this e-mail are those of the
individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or
any attachments are free from viruses and we cannot accept
liability for any damage which you may sustain as a result of
software viruses which may be transmitted in or with the
message.
Diamond Light Source Limited (company no. 4375679). Registered
in England and Wales with its registered office at Diamond
House, Harwell Science and Innovation Campus, Didcot,
Oxfordshire, OX11 0DE, United Kingdom
