I implemented a client for OPC DA version 2.05, used the OPC Foundation library. I need to tell the OPC server the name of the client. But I can't find the right method or property of the Server object. I'm doing something wrong maybe?
For example, so is done in another library TitaniumAS.Opc
server.Connect();
if (server.IsConnected)
server.ClientName = "MyClient";
Perhaps there is a easy decision to the problem, but I don't see it...
Related
I have Problems understanding best practice around OPC UA.
OPC UA is often called Protocol of future IOT and other positive stuff.
In my understanding, if you want to Provide Information over OPC UA as a Service you Implement SOAP Web services. As far as my Knowledge goes, RESTful services are just better in most Use cases.
I know SOAP REST comparisons that call Rest the better choice and then there are some Industrial Adverts calling OPC UA better then REST …
Pro Rest:
https://spf13.com/post/soap-vs-rest/
Pro OPC UA:
https://www.maintworld.com/Partner-Articles/Why-use-OPC-UA-instead-of-a-RESTful-interface
In my Conclusion, unless there are other Implementations of OPC UA then SOAP. REST seems without hesitation better.
Am I wrong in the Understanding that SOAP is the common Implementation of OPC UA?
Are not most Features of this “Amazing” Protocol behind RESTful standards?
How Comes most Production Related Software Products focus on OPC UA instead of REST?
Thanks for any Advice or Source of Information!
In my understanding, if you want to Provide Information over OPC UA as a Service you Implement SOAP Web services.
Not even close.
Am I wrong in the Understanding that SOAP is the common Implementation of OPC UA?
Yes, very.
The term “SOAP” literally isn’t used in the OPC UA article you linked to. I think you need to go back to step zero and start reading some introductory OPC UA material.
Here’s an overview article that even touches on the fact that there used to be an optional SOAP/HTTP transport defined by the spec, which may be the source of some of your confusion: https://www.rtautomation.com/technologies/opcua/
Newer versions of the spec have deprecated this transport because almost nobody used it. The UA TCP binary transport remains the only transport required to be implemented and the overwhelmingly most commonly used.
I’m new to OPC-UA and came across eclipse milo project. Project seems interesting but there is very little developer help. I am trying to browse code to figure out how to implement Node with historical data. Project has other examples for reference but missing history service example. I tried to modify provided example in ExampleNameSpace.java to enable history on the UaVariableNode but in Prosys OPC UA Client, it doesn't enable "Show History" menu for the Node. Here is what I tried
UaVariableNode node = new UaVariableNode.UaVariableNodeBuilder(server.getNodeMap())
.setNodeId(new NodeId(namespaceIndex, "HelloWorld/Dynamic/" + name))
.setAccessLevel(ubyte(AccessLevel.getMask(AccessLevel.READ_WRITE)))
.setBrowseName(new QualifiedName(namespaceIndex, name))
.setDisplayName(LocalizedText.english(name))
.setDataType(typeId)
.setTypeDefinition(Identifiers.BaseDataVariableType)
**.setHistorizing(true)**
.build();
It will be very helpful if some one who implemented historyService using milo can share example.
UPDATE: Sorry, I should have included other part that I implemented. After reading other stack overflow post, I implemented historyRead function in namespace, which will take care of pulling history reading from datastore. My trouble right now is to indicate OPC client that Node is history capable. Test is to make prosys OPC client to enable "History" menu for the Node. I am probably missing something here.
The Milo Server SDK does not implement historical services for you.
Setting the Historizing attribute is just the tip of the iceberg. Your Namespace also has to override the historyRead (and historyUpdate if you want to support it) methods defined in AttributeHistoryManager and provide implementations. This will be impossible if you're not familiar with how UA history works, which is all defined in Part 11 of the spec.
You'll also have to take responsibility for actually storing the history for any nodes that have their Historizing attribute set, so that the services you implement actually have some data to go and query.
FWIW, developer documentation is a work in progress and should drastically improve in the next couple releases.
History is unlikely to ever be implemented as part of the SDK in such a way that you can just flip a switch and it will start working. It's fairly complicated and an efficient implementation of the services is likely to be coupled to whatever backing store you're using.
Hi I am studying IoT with PLC.
I was looking for a way to poll data from PLC modules, and found OPC Protocol that seems to be the standard.
If I adopt this protocol and make a server that polls data via OPC and mediate that protocol, will I be able to connect to any kinds of PLC?
I saw some solutions and they highlight specific vendor-drivers.
Does this mean OPC is not a standard and I need to see each vendor's protocols?
I need some grasp on this, so please advice on how I should communicate with PLCs with JAVA Server
OPC has multiple different versions.
The major ones you might consider are:
OPC DA ("Data Access"), which is based on Microsoft OLE, COM and uses DCOM as a wire protocol.
OPC UA ("Unified Architecture"), which has a more complex data model and has a distinct protocol specification. There are multiple wire protocols, including an XML based protocol and a compact binary encoded protocol. There are different types of security choices; interoperability means matching everything up.
For PLC access it may be that you are using a gateway between a wire protocol (for example Modbus or a vendor protocol) and an OPC programming environment. In this case you do not need to be aware of the protocol implementation; the driver/gateway is responsible for the conversion into the OPC programming environment.
In a Java environment you could find an OPC UA supplier that provides a Java API and has driver support for the devices you need to use.
Right, so only relatively recently did PLCs start to communicate via OPC-UA natively. Typically, each vendor has their own sometimes open, sometimes proprietary protocol that you need to use to talk to the PLC.
The traditional role of a OPC servers has been to let the vendor of the server worry about all the protocol details for each kind of device while clients just need to know OPC-DA or OPC-UA, which is an open standard.
I have been looking at the OPC UA Specification parts, however they do not give you a list of classes and function and tell you how they work. Is there something like that?
Also the server, the 1st thing it does is creates an Object right?
one of Server ?
what are the steps from the Server point of view ?
You should strongly consider using one of the available SDKs if you're looking to build an OPC-UA server.
That being said, UA Part 6 describes the encoding of the built-in datatypes. A schema describing many of the other structured types is available here: http://opcfoundation.org/UA/schemas/1.02/Opc.Ua.Types.xsd, along with some other useful XML files.
As you can read into the Part 1 : Overview and Concepts of the OPC UA Specification :
OPC UA defines a common infrastructure model to facilitate
this information exchange OPC UA specifies the following:
The information model to represent structure, behaviour and semantics.
The message model to interact between applications.
The communication model to transfer the data between end-points.
The conformance model to guarantee interoperability between systems.
You could get the OPC UA Stack from the OPC Foundation if you are member of it, but this is only the communication part of a Server/Client application.
Then you have to implement your own Server/Client (AddressSpace manager, Session Manager, Subscription Manager, Certificate manager,...) or buy a SDK that already contains all the required features of an OPC UA Server or Client and will allow you to launch a Server/Client with few code lines.
I am currently new in OPC ( OLE for process control). I want to know about the interfaces IOPCServer, IOPCDataItem, IOPCGroup interfaces in the OPC. What are they used for & what is their role in terms of OPC Client & OPC Server & what methods & properties these interfaces conatins ? Can you provide me the answer for the above questions or can you provide me the link through which I can get the knowledge of the above topics ?
You're probably talking about the OPC DA (Data Access) interfaces. You would have to know which version of OPC DA you're targeting (most likely versions are 2.05a and 3.0).
The interface specifications are served by OPC Foundation, and they require a paid membership to download the specifications. See: http://www.opcfoundation.org/Downloads.aspx?CM=1&CN=KEY&CI=274 ; or you might be able to catch a glimpse of the specs for free online, search around, for example see: http://www.doc88.com/p-67617868554.html
Download the OPC DA redistributable package from OPC Foundation (this is free even for non-members). Then you can see the full API definitions in the included IDL files.
Anyway, IOPCServer is the "root" interface through which the client connects and gets the references to all the other objects. Practically it has the semantics of a connection-type object. Its methods provide some basic services (e.g. server state management), as well browsing all the served items and their properties.
IOPCGroup provides a way of grouping data items for collective reads and writes. A group is a collection if items which are read with the same cycle, and have the same deadbands. It contains methods for adding/removing items and reading them synchronously or asynchronously.
IOPCDataItem I have never seen (in DA 2.05 or DA 3.0). Could you be referring to IOPCItemIO, which is the way to read/write items directly without creating groups (in 3.0 only)?