Re: Simple Components 4.12 with MQTT implementation released

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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

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.

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.

> 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.

>> 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"

>>> 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.

>>> 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...

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