Re: Simple Components 4.12 with MQTT implementation released

[slos <new.stephane.los@gmail.com>]

Le vendredi 15 avril 2016 17:05:56 UTC+2, Dmitry A. Kazakov a écrit :
> On 2016-04-15 12:06, slos wrote:
> 
> > We share some of the vision.
> > "Ada for Automation" is a framework with which one can build his own
> > control application using Ada. I would not call it a middleware.
> 
> Why not?
> 
> > And MQTT or OPC UA would just connect it to some SCADA or cloud based
> > application like one using IBM BlueMix.
> 
> Neither is good for SCADA, especially regarding safety requirements and 
> performance.
> 
> >> Note that without OPC UA everything could work far better and require
> >> far less resources. E.g. having all process data the OPC cannot access
> >> because it is too slow to pace with the middleware capable to deliver
> >> data at less than 1ms rate and does not properly support
> >> push-subscriptions, does not support distributed time stamping, physical
> >> units, error states etc.
> >>
> > I agree that OPC UA does not fit where EtherCAT, Sercos III or PROFINET IRT would.
> > OPC was created for office and SCADA / GUI applications access to
> > PLC  data, not for IO processing.
> 
> Why SCADA or DB server should ever use some other middleware protocols? 
> The point is that one middleware can stretch from the ERP levels down to 
> the field.
Well, in this case this is no more a middleware. It's an everyware...

> But when the middleware is OPC or MQTT you cannot not put it 
> into a device and expect that working.
Yes you can :
http://www.hilscher.com/fileadmin/cms_upload/en-US/Resources/pdf/netIC-IOT_Datasheet_10-2015_EN.pdf

> This is the reason we must live 
> with EtherCAT, ProfiNET down there, which are nightmare to any system 
> integrator.
That is not the case. Those standard protocols are designed with lots of goals, among them performance and interoperability.
They allow multiple vendors to propose products fitting well together and it works pretty well since years.

> That defeats the very idea of a middleware.
I don't see why. The middle of what ?
Architecture is made with layers and middleware can sit between any two of them.

> The real advantage of Ada is that it is scalable from heavy duty to hard 
> real-time embedded.
Yes, hence my choice for "Ada for Automation".

> The ugly protocols like XML, HTTP, OPC etc only 
> hinder developing of safe and efficient systems.
Yes but they allow interoperability, and the web and talking to each other whatever browser or platform we use.

I think one of the problems of Ada community is a kind of sectarianism or elitism.
I agree that Ada has great qualities and could be used with huge benefits in most applications but there is an ocean of already available stuff that is not written in Ada and work anyway.

That's what I am trying to do with "Ada for Automation" : gather software components, integrate them in something consistent for a control engineer and create sample applications to start from.
If I find components written in Ada, that's great. If they are in C, that's fine too for me.
Anyway my day job is C programming and I've been programming PLCs for decades too. Ada is my night language... which I am still learning.

> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

BR,
Stéphane