Re: Simple Components 4.12 with MQTT implementation released

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

Le samedi 16 avril 2016 10:12:47 UTC+2, Dmitry A. Kazakov a écrit :
> On 2016-04-16 00:18, slos wrote:
> > Le vendredi 15 avril 2016 18:31:00 UTC+2, Dmitry A. Kazakov a écrit :
> >> On 2016-04-15 17:47, slos wrote:
> >>
> >>>> 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
> >>
> >> It is not a device, it a SBC with an OPC stack in it. We have that too,
> >> an ARM board with OPC UA server, no problem whatsoever. Anybody can have it.
> > You have read the data sheet too fast. May be you should consider to read it again.
> > Not only you have OPC UA or MQTT but also on the same medium EtherCAT, Ethernet/IP or PROFINET.
> 
> Of course I read it. It is exactly what all other vendors do, including 
> the firm where I work. Neither the concept nor the hardware is any new. 
> For example, how is it different from an antique SPS equipped by an OPC 
> server and PROFINET?
> 
> The idea of middleware, predating by decades the "newly discovered" idea 
> of IoT is different. It is getting rid of the gateways like yours:
> 
>     Application <--OPC--> Hilscher <--PROFINET--> ADC terminal
Well, this is not correct.

The netIoT is a gateway that gives OEM connectivity :
Analog   |          |PROFINET-------|SPS Control
Digital  |--netIoT--|Ethernet/IP----|OPC----|Cloud
Computed |          |EtherCAT-------|MQTT---|Applications
Com      |

Our customer WANTS this kind of connectivity because they SELL their hardware to SPS users who want to get the supposed benefits of Industry 4.0 or IIoT.
They may exchange their SPS for your middleware if you go visit them.

> 
> to be replaced with:
> 
>   Application <--DDL--> ADC terminal
> 
> The ADC terminal is a device or "thing" in the IoT Newspeak. The idea is 
> to talk right to the thing. No gateways, just interconnected things.
If no gateway is used the ADC has to implement the protocol, whatever it is.

> 
> Now, the point I am making is that neither OPC nor MQTT is suitable to 
> serve as the DDL (data-distribution layer) for a middleware stretching 
> from application to the automation devices. Both were originated under 
> impression of desktop office applications rather than real-life process 
> control.
I agree. That's why they are used on the upper levels.
For process control, real time protocols are used.
And when you only need to collect data like temperature from large networks protocols like MQTT have some advantages.

> 
> > So real time data is exchanged via real time protocols and relevant
> > data for cloud application is exchanged with OPC UA or MQTT.
> 
> q.e.d.
> 
> >> Now try to sample 8 10kHz channels and subscribe to them through OPC,
> >> get the data to a PC and log them with time stamps and no losses.
> > OPC was never designed with this kind of needs in mind.
> 
> Ergo, unsuitable for automation and control.
Again, I have already agreed on that and by the way never said the contrary.

> 
> >> How does EtherCAT operate with other protocols?
> > You could use Ethernet over EtherCAT.
> 
> Tunneling is not "operating with". You need a gateway, like Hilscher 
> box,  to bridge OPC and EtherCAT. Hence, OPC and EtherCAT are not 
> interoperable.
> 
> >>> They allow multiple vendors to propose products fitting well
> >>> together  and it works pretty well since years.
> >>
> >> Clearly, any protocol is interoperable with itself. This is not
> >> interoperability, when multiple vendors can implement it, IMO it is
> >> openness.
> > Please could you give your definition of interoperability?
> 
> Wikipedia: "Interoperability is a property of a product or system, whose 
> interfaces are completely understood, to work with other products or 
> systems, present or future, without any restricted access or implementation"
This is exactly what open protocols standards are created for.

> 
> >>> The middle of what ?
> >>
> >> A middle between an application logic and the
> >> devices/actuator/sensor/data source logic.
> > So Ada from hardware to application.
> 
> Are you talking about the language of API? The middleware will have API 
> in all languages used in the application area. Most of middlewares do.
> 
> The language of the implementation is only of the vendor's interest. For 
> us it will be Ada.
> 
> > Gnoga allows an Ada application to talk to the browser and provide a GUI to the application.
> > That does not make the Ada application an application running in the browser.
> 
> Parts of it are certainly running in the browser.
No. No Ada code is compiled to be executed in the browser.
Gnoga is not an Ada to JavaScript compiler.

> 
> >>> I think one of the problems of Ada community is a kind of
> >>> sectarianism or elitism.
> >>
> >> Ada community consists of competent engineers, that shapes it this way.
> >> Is it a problem? Maybe it is, but I prefer this problem to others.
> 
> > Other communities have also competent engineers. They don't write
> > their code in the Ada language but that alone does not make their
> > creation a crap.
> 
> Now you are switching the topic towards quality of the software designed 
> in different communities.
> 
> I am not ready to pass judgment without knowing who are "they" you are 
> talking about. Some "they" produce excellent quality software, other 
> "they" produce exclusively garbage.
> 
> When "they" = all software developers in the world, then the picture is 
> quite grim, as expected.
> 
> > I am just a support guy interested in development.
> 
> I see, less protocols would mean less support work. Worrying about your 
> business? (:-)) Do not. It is a very long way to go, alas...
I don't worry about my business. If I could convince you to connect your middleware to our cifX driver you would be able to talk to most devices of the automation field.
Your middleware could interest more people since being more capable.
And Hilscher would sell more boards. Not me. ;-)

When you need some training or support I will be glad to provide it to you.

Let's be friends, no enemy.

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

BR,
Stéphane