I have been reading around the internet for a good explanation of what a node is in OPC-UA. It seems there are libraries out there for it, but none actually explain nodes. What is the purpose of nodes in OPC-UA?
Note: OPC and OPC-UA noob here
I think you are talking about 2 different stuff here.
the node concept of OPC UA: An OPC UA node is like an entity representing information. Some Nodes are Variables, DataType, References, Object, Methods... depending of what they are used for.
By reading the OPC UA Specification you will get a good overview here - Specially Part 1: Overview and Concepts and Part 3: Address Space Model (you need to create a free account first)
NodeOPCUA, which is a Node.js implementation of OPC UA.
Node is a basic conception of OPC UA protocol. It has some unique identifier and represents types, relationships, objects, classes, variables and etc.
If you are a programmer, a good analogy would be an object model in high level program languages (Java, Ruby etc) where types and methods are also instances.
Related
By opc-ua pubsub specifications, DataSetWriterId in DataSetMessage header is optional, and DataSetMessage ordering can be set to Undefined_0, which is when we can't guarantee an order of DataSetMessages in NetworkMessage. How to identify which DataSetMessage we received if there are multiple ones in the WriterGroup?
The OPC UA PubSub specification makes many things optional. Whoever configures the system is then responsible for making choices that make sense. What you have described is just one example of such case. The idea is that if you cannot identify what you need "on the wire", you should not do it. So if you wanted to leave out DataSetWriterId and there would be no other way of getting the same information, you then have to put just one enabled DataSetWriter into the WriterGroup.
There are/will be profiles ("header layouts") in the UA spec that will combine the reasonable and most commonly used options together, with the expectation that most systems will stick to one of the profiles (while still allowing to do something else as long as it conforms with the text of the spec and makes sense).
I have a question on whether or not a particular REST-service design is good or not.
The background is of having an inhouse monolithic system (will call this "the main system") dealing with e.g. customers. Then there are external components that have additional information on persons, which may or may not correspond 1-1 with a customer in the main system.
At present there is no definite specification of what kind of data is or may be associated with a person/customer in these external components.
The proposed design I have been presented with is a REST- service that exposes an API for the external system to call in order to feed the component with this arbitrary data associated with persons.
The idea is that by doing so the main system will have a single place to go to, to get the external data for customers/persons.
A proposed requirement of this REST service is that as new types of data is loaded into it by an external component, this data is automatically made accessible by the service, without it needing to be changed in any way, or redeployed. And "new data" generally means a new type of key value set. E.g. initially the service might provide data for customer identified by a customerId. Then an external component decides to post some kind of data associated to SSN. This should automatically entail that the service can be queried for this data by supplying SSN in the request.
In order to avoid the need to change/redeploy the service I’m assuming the solution will ahve to have a very generic scheme of reference, e.g.
http://url/generic-resource-name/?id=[customerId]&keyType=cusomterId
There is really nothing in the requirements that limits the data to be associated to a person, only that it’s key be made up of one value.
And example use case sequence could be:
So to the question:
Is it a good idea to implement such a general purpose service? And how does it rhyme with the principles of REST: the noun in question that the service will operate on will have to be very generic, really nothin short of “resource” or “data”, which in itself seems like a smell to me.
So to the question: Is it a good idea to implement such a general
purpose service?
I believe not. You are going straight into Inner platform effect antipattern. You must be very careful, or you might end like Vision.
Please also read a chapter "The allure of distributed objects" from Fowler's PoEAA book. Just to be careful.
Hi I am investigating OPC UA for my organization. I am trying to work out an example for a presentation based on an information or data example.
I have one for a on demand read operation and one for a continuous monitor. What I don't quite understand since I am just learning and haven't picked a vendor yet (lean towards United Auto) is how is the data represented?
For example if I have a data struct or object called machineInfo with 13 attributes (data) how would I create that on the server side and show how its done?
How would it fit in the BaseNode, Variable hierarchy? Or am I way off?
I can show high level or just code.
Thanks
MachineInfo would be an Object node (NodeClass of Object), with HasComponent references to each of the 13 attributes, which themselves would be Variable nodes (NodeClass of Variable).
As far as type definitions go, you could start out with just using the BaseObjectType and BaseDataVariableTypes, but if you're going to be using a client capable of taking advantage of more complex types you could create a custom ObjectType for the object. The variable components could be further exposed as AnalogItemType or DiscreteItemType, if applicable...
What programming language/SDK are you leaning towards?
I am building a distributed system which consist of modules/application with interfaces defined by protobuf messages.
Is it a good idea to expose those protobuf messages to a client directly? ... or maybe it's better to prepare a shared library which will be responsible for translation of (let's assume) method based interface to a protobuf based for each module and clients won't be aware about protobuf at all?
It's neither a "good idea" nor a bad one. It depends on whether or not you want to impose protocol buffers onto your consumers. A large part of that decision is, then:
Who are your consumers? Do you mind exposing the protobuf specifics to them?
Will the clients be written in languages which have protobuf support?
My $0.02 is that this is a perfect use case for Protocol Buffers, since they were specifically designed with cross-system, cross-language interchange in mind. The .proto file makes for a concise, language-independent, thorough description of the data format. Of course, there are other similar/competing formats & libraries out there to consider (see: Thrift, Cap'n Proto, etc.) if you decide to head down this path.
If you are planning to define interfaces that take Google Protobuf message classes as arguments than according to this and that section in Google's Protobuf documentation it is not a good idea to expose Protobuf messages to a client directly. In short, with every version of Protobuf the generated code is likely to be not binary compatible with older code. So don't do it!
However, if you are planning to define interfaces that take byte arrays containing serialized Protobuf messages as function/method parameters then I totally agree with Matt Ball's answer.
In Phillip Haller's PhD thesis he mentioned in section (5.1 Future Work) that one of the interesting areas of research would be to extend the framework with ambient references and he cited Van Cutsen's paper.
Excerpt:
The Scala Actors library includes a runtime system that provides basic
support for remote (i.e., inter-VM) actor communication. To provide
support for fault tolerancy (for instance, in mobile ad-hoc networks),
it would be interesting to extend the framework with remote actor
references that support volatile connections, similar to ambient
references [36]. Integrating transactional abstractions for
fault-tolerant distributed programming (e.g., [52, 142]) into Scala
Actors is another interesting area for future work.
And citated paper is:
[36] Tom Van Cutsem, Jessie Dedecker, Stijn Mostinckx, Elisa Gonzalez
Boix, Theo D’Hondt, and Wolfgang De Meuter. Ambient references:
addressing objects in mobile networks. [...] pages 986–997. ACM, October
2006.
Is this what Akka did? If not, do you think it is still relevant to research this area given the fact that Akka exists today?
Yes, this is possible with Akka.
There are 2 ways to achieve this as far as I know:
akka-remote - Provides remote actor ref, but you need to decide where each actor should exsist.
akka-cluster - Provides cluster sharding. Automatically manages actor physical location and ensures that given shard (Actor) is present on at most one node in the cluster.