From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Simple Components 4.12 with MQTT implementation released Date: Sat, 16 Apr 2016 10:12:30 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <6d3b7ac5-8fc6-406c-8aac-947d25a78249@googlegroups.com> NNTP-Posting-Host: LMk7+sG0YqgPmReI4fVkAA.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:30153 Date: 2016-04-16T10:12:30+02:00 List-Id: 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