I am trying to determine the main differences between the latest three revisions of the OPC UA specification. I'm working on testing out some OPC SDKs and have been asked to make sure they work with OPC UA 1.03. To do this, I need to know what the differences are between 1.01, 1.02, and 1.03.
I've read that 1.02 added HTTPS and 256 bit encryption support, and that 1.03 adds a Pub/Sub model, but I can't find a concise list of features.
I have tried looking through the documentation at OPC Foundation, but it is quite verbose and doesn't nicely show what has been added each revision.
Can someone list the differences between the versions or point me to a resource that does?
At least starting with 1.03, each of the specification part documents has a "highlights" table for that revision number.
Also, FWIW, Pub/Sub is coming in 1.04. It's not part of 1.03.
If there's a "release notes" style list somewhere for each version I'd love to know also...
That being said, you shouldn't need to know all the differences in order to make sure the SDK you're evaluating supports a certain version. Just ask the vendor/author what version it supports. They'll know.
Related
I am a student studying reverse engineering
I mainly use C and Perl, and I think this is a good choice
However, python is still being developed for ida, but idaperl says development has been discontinued (github). I have two questions.
Has idaperl development stopped?
github supports ida 6.5. Can this be used informally in 7.0?
The repo README.md says it's been discontinued,
note: I am not actively developping this plugin anymore, since i myself now mostly use idapython for scripting.
I have been looking for active forks, but there seems to be none. So your best bet might effectively to use IDAPython. It's anyone's guess whether this version supports 7.0, but you might want to downgrade to 6.5 if you effectively want to use that. There seem to be some tools that support reverse engineering in CPAN; depending on what you want to do, one of them might be useful if you're keen on using Perl.
I have an application whereby I need to read data from a PLC into a database and whereby I need to develop my own application to do this. I just need to read 5 values from the PLC and log it to a DB. I have a demo OPC server running and can access it via UA or DA.
After looking at many different approaches I settled on using an OPC server to connect to the PLC and then to write an OPC client to interface to the OPC server and then write the data to the DB from my app. My language of choice is C# with .Net and the only licence fee I am able to pay for is for the OPC server from my PLC vendor.
What I am however finding extremely frustrating is getting the right info on OPC to get started. I dont want to buy any stacks but would prefer an open source stack. The information seems very fragmented and all over the place. Most of the info about OPC seems to be hype about how easy it is to use etc.
The best post on Stackoverflow that I could find is: Noob guide to OPC: how to write a C# Hello World client? and some of the links are not active any more.
My question is therefore are there any good tutorials showing how to build and OPC client from scratch in .net and what is the best open source SDK to use without having to buy a vendor's stack?
Is DA also worth learning or should one stick with UA?
The big question is why is OPC so frustrating when its marketed as being so easy?
It would also be nice to have a nice high level guide on the theory that one needs to know to build a client. I do realize that with time its possible to eventually figure this from the resources available but with limited time to make sense of all the scattered resources a quicker guide would be helpful.
Stick with OPC UA.
Luckily for you, the OPC Foundation's C# reference implementation has the capabilities of both stack and SDK, whereas other language reference implementations are typically just stack functionality.
The code is available on GitHub: http://opcfoundation.github.io/UA-.NET/
If you're not a member of the foundation the code is available under GPL2.
As for your concerns about the ease of use and marketing... I assume it's because OPC UA is marketed towards end users, who will just be hooking up various OPC UA compliant applications, which is easy. As a developer I think its fair to say there's a little more assumed about your ability to figure things out... from code examples, the specifications, books that are available, etc...
This question is regarding OPC UA specification design for a industrial application. I am a beginner to OPC UA terminology and wondering what is the process of designing a OPC UA specification. I searched online for tutorials, tools and went through the standard textbook of OPC UA. I have got information in bits and parts but never a structured approach.
Questions
Do we have any open source tools that can used to design a OPC UA specification?
Do we have any standard document describing the process of designing a OPC UA specification
Any Small clue reasoning to a approach is much appreciated. Thank you
I think you're a little confused. You don't want to design an "OPC-UA specification"; these specifications already exist, are maintained by the OPC Foundation, and define what OPC-UA actually is.
More likely, you need to develop an application that conforms to or is compatible with OPC-UA in some way. In that case, we'll need to know what it is your application is doing (is it a client or server?) and what language you're planning to develop it in. From there you can determine whether or not you need open source or commercial tools to move forward.
Basic bulding blocks for information models are found within the UA companion specifications. A range of working groups develop these for various domains of interest. Standard semantic models are defined to provide interoperability.Look to OPC Foundation site. Provided a companion spec, you might as UA client imediately recognize the adresspace content of a servér you have never seen before. As UA you may provide data to some client you currently not know, but it might recognize the content anyway. And when you connect to another UA that complies with the same companion spec, you might recognize that content to with very little extra effort.
A friend has asked if I could implement a data historian. I am busy doing research, googling around, reading UPC Unified Architecture - but it's a lot to get through, so I will ask if anyone here has ever gone down that road (while still continuing my research).
Approx how many man months for a 20+ year developer (or two) to get at least a demonstrable working prototype - and how long to completion?
Which programming language? Is C++ good, or what?
What resources are available to me? (I thought I saw an Open OPC framework, but can't find it again). Any FOSS, libraries or free code which I can base upon? Maybe a sourceForge project?
How best to test?
Any other hints?
In my company we use mostly to brand of Historian, PI developped by OSISoft and GE Profecy Historian. Ge Profecy now offers a 25 tag version of their latest Historian 4.5. The way it works is you got an historian server that collects from data collector pc's. Depending what piece of equipment you are communicating with you'll need different OPC driver.
Matrikon and Kepware are the 2 references in that field. At Matrikon you'll find almost anything related to OPC. We mostly use Kepware, cause we felt their solutions are more stable on the long run.
Depending of your knowledge of the PLC's you have in place and the number of point you want to acquire. It might take a day to a week implementing an historian. I'll be more than happy to help you if you provide us with more details.
It would be interesting if you can do a write up of your project when you complete it.
For OPC libraries your pretty limited, but OPC Connect has a good list of UA development kits otherwise you'll need to be a corporate member with the OPC Foundation.
This is an old topic, but I'm interested in the subject.
There is a Python library for OPC: openopc at SourceForge.net (I use a proprietary OPC client because it is provided by my automation supplier, Yokogawa.)
For short-term data grabs you can use a delimited text file, but for a historian you ought to use a database. I use SQLite for speed, size, and portability. Other DB solutions have advantages. Of course if you collect 400 points every second then over time your DB grows quite quickly, so efficient data storage is important.
Language used is influenced by your choice of OPC package. OpenOPC for Python is, well yes, for Python. I've used Graybox's free OPC client with .Net. The OCX I use at work is easiest to use with VB6. Not sure about others.
The time required to build a historian depends entirely on how complete the application needs to be. You can probably put together a data grabber in a few hours. A long-term historian with interfaces to view data, to add and delete points, to maintain data integrity, to handle bad data and interrupted communications gracefully -- all that will take days, not hours.
I'm investigating using either Memcached or Velocity for distributed caching over a cluster of servers after reading Scott Hanselman's answer to this question. Does anybody know of a Microsoft web site that uses Velocity for its caching? If Microsoft aren't using it then does anybody know of any relatively popular web site that's using it?
It would be pretty foolish for any substantial site to go live (in production) on a CTP of a product (edit - good point in the comments - this isn't a hard rule... there are exceptions, for example stackoverflow). Velocity is currently in CTP2, which is good for building out proof-of-concept and planning for product releases, but that's all. Once it is a supported product, I'm sure we will see plenty of usage. Follow the Velocity product team blog (http://blogs.msdn.com/velocity/) for details.
As far as memcached vs Velocity, they have somewhat overlapping but ultimately different purposes. Memcached is not reliable. That is spelled out very clearly in the documentation and by the authors. It is intended to be blazingly fast, cheap to run and simple to administer. Velocity, on the other hand, is much more familiar to the formal enterprise software crowd. It is complex, with a robust API and is better for a more formal data environment.
memcached is not natively supported on Win32. There is a project that aims to port memcached to Win32
http://jehiah.cz/projects/memcached-win32/
And while they have been successful, they lag a couple of versions (point versions at this point) behind the main release line. So if you're on Win32 I think your best bet would be Velocity.
So while I dont have an answer to your question (what sites use Velocity) I think you're better off going with Velocity over memcached.