Re: Simple Components 4.12 with MQTT implementation released

[hanslad@gmail.com]

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

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

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

Well that is exactly how OPC UA works, you request data with a required sample rate, published at a required rate. 

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

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

Regards
Hans Petter