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 14:43:45 +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: bqgfK7NL3xTHnr0WRaLl4g.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 6.1; 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:30192 Date: 2016-04-19T14:43:45+02:00 List-Id: On 19/04/2016 13:51, hanslad@gmail.com wrote: > I think the OPC UA discussion is interesting. Possibly not the right forum but anyway: > >> >> 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. > 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. > Setting up a subscription with the > requested sample rate and, say, a publishing interval of 1 sec gives a > close to 16 MBit/s binary encoded stream. I don't understand what you mean. In the systems we deploy there is no publishing interval. Updates are sent to the subscribers when become available. Due to oversampling it is usually several updates per channel at once (if the QoS of subscription requires this). The DDL protocol ensures ordering and time stamping, so that the subscriber can sort out the data, e.g. for logging or other processing. > 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). > 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. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de