Re: [kura-dev] [science-iwg] Lab automation tooling

["Sridhar, Kanchana" <kanchana.sridhar@xxxxxxxxx>]

Hi Benjamin,

Is there a sample application that is released with the Kura distribution that can be used by new adopters like Intel to get a feel for “Kura Wires” in action ?  This would come in very handy.

Thanks,
Kanchana


-----Original Message-----
From: kura-dev-bounces@xxxxxxxxxxx [mailto:kura-dev-bounces@xxxxxxxxxxx] On Behalf Of Benjamin Cabé
Sent: Saturday, April 30, 2016 7:38 AM
To: Science Industry Working Group; kura-dev@xxxxxxxxxxx; jconlon@xxxxxxxxxxxx
Subject: 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

_______________________________________________
kura-dev mailing list
kura-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/kura-dev