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: Tue, 19 Apr 2016 18:39:06 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <6d3b7ac5-8fc6-406c-8aac-947d25a78249@googlegroups.com> <7e104831-cec6-4b04-8671-17e8bdcdae9c@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: 7bit 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-Mozilla-News-Host: news://news.aioe.org X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:30198 Date: 2016-04-19T18:39:06+02:00 List-Id: On 19/04/2016 15:43, hanslad@gmail.com wrote: >>>> 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. >>>> >>>> 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. >>> >>> I can't see what in the OPC UA standard from OPC Foundation that >>> doesn't make this possible? >> >> So far it cannot. > > The case was reading data from 8 10KHz channels into a log . Nothing > in the OPC UA protocol that hinder this. No, the data are read into the local system and handled there. They also are distributed among the remote systems (remote subscribers). Some remote systems log data, without loss. >>> Having in mind that OPC UA is just a protocol standard and given >>> that you have hardware to cope with the problem, there should be no problem >>> to create a subscription with monitoring items on the items that holds >>> the value of the channels(In my lack of understanding what a channel is, >>> I have regarded this as something with a value, represented as a double, >>> changing 10000 times a second). >> >> Sort of. It is a value and a time stamp, because data are oversampled. >> There is no way a conventional OS could respond to each change at this rate. > > OPC UA is not tied to any OS platform. Our stack works fine on VxWorks, for instance. That does not change much, of course we have VxWorks as one target. But VxWorks could not handle that either. It is not so drastically better than say Linux in terms of latencies. Oversampling is a very special case but it illustrates the services a middleware must provide. > Well that is exactly how OPC UA works, you request data with a > required sample rate, published at a required rate. Who requests data? An OPC client? The problem with actual OPC UA is that it is in the pull mode. There is no chance to get almost anything working in automation and control through pull without hard time synchronization, with is of course, impossible in a loosely coupled networking system. >>> That's not to difficult to handle for any system? >> >> That depends on the method of handling. You cannot handle it if you >> react to each change synchronously. One of the differences of the >> middleware we use to OPC servers is that producers are never blocked and >> practically nothing is serviced synchronously. All variables are >> "history" data in OPC terms (if they make it working some day). > > For the logging purpose, why should you react synchronously? As long > as the system that generates the data has buffers to handle data storage > between each OPC UA publish request response, this will work fine. It is the DDL which has to buffer published state changes for the subscribers, not the application. The application must get all changes if it requested that level of QoS. >>> Also, there is pub-sub is added to OPC UA in the upcoming 1.04 >>> version of the standard. I cant' see why OPC UA shouldn't bee fit for >>> device todevice communication, both real-time-, information model-(for >>> interoperability) and security-wise? >> >> OPC is about 20 years old and still does not do basic stuff. There is a >> lot of details how publishing-subscribing service has to be implemented >> to deal with the use cases of automation and control problems. > > You are mixing classic OPC and OPC UA, I think. They failed each other attempt, why should they succeed now? OPC UA started with a wrong architecture and wrong assumptions right away. I don't believe it can be fixed, because there is too much power behind OPC. OPC is sold and accepted as an overall solution even if it is not and never was. Nobody cares, why should anybody improve anything if the thing is already sold? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de