[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [kura-dev] [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
