| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112 |
- /**
- \mainpage Open62541 Developer Documentation
- <a href="http://en.wikipedia.org/wiki/OPC_Unified_Architecture">OPC UA</a> (short for OPC Universal
- Architecture) is a protocol for industrial communication and has been standardized in the IEC62541.
- At its core, OPC UA defines a set of services to interact with a server-side object-oriented
- information model. Besides the service-calls initiated by the client, push-notification of remote
- events (such as data changes) can be negotiated with the server. The client/server interaction is
- mapped either to a binary encoding and TCP-based transmission or to SOAP-based webservices. As of
- late, OPC UA is marketed as the one standard for non-realtime industrial communication.
- We believe that it is best to understand OPC UA *from the inside out*, building upon conceptually
- simple first principles. After establishing a first understanding, we go on explaining how these
- principles are realized in detail. Examples are given based on the *open62541* implementation of the
- standard.
- OPC UA, a collection of services
- --------------------------------
- In OPC-UA, all communication is based on service calls, each consisting of a request and a response
- message. Be careful to note the difference between services and methods. Services are pre-defined in
- the standard and cannot be changed. But you can use the *Call* service to invoke user-defined
- methods on the server.
- For completeness, the following tables contain all services defined in the standard. Do not bother
- with their details, yet. We will introduce the different services later in the text. In open62541,
- each service is implemented in a single function. See the \ref services section for details.
- __Establishing communication__
- | Discovery Service Set | SecureChannel Service Set | Session Service Set |
- |-----------------------|---------------------------|---------------------|
- | FindServers | OpenSecureChannel | CreateSession |
- | GetEndpoints | CloseSecureChannel | ActivateSession |
- | RegisterServer | | CloseSession |
- | | | Cancel |
- __Interaction with the information model__
- | NodeManagement Service Set | View Service Set | Query Service Set | Attribute Service Set | Method Service Set |
- |----------------------------|--------------------------------|-------------------|-----------------------|--------------------|
- | AddNodes | Browse | QueryFirst | Read | Call |
- | AddReferences | BrowseNext | QueryNext | HistoryRead | |
- | DeleteNodes | TranslateBrowsePathsToNodeIds | | Write | |
- | DeleteReferences | RegisterNodes | | HistoryUpdate | |
- | | UnregisterNodes | | | |
- __Notifications__
- | MonitoredItem Service Set | Subscription Service Set |
- |---------------------------|--------------------------|
- | CreateMonitoredItems | CreateSubscription |
- | ModifyMonitoredItems | ModifySubscription |
- | SetMonitoringMode | SetPublishingMode |
- | SetTriggering | Publish |
- | DeleteMonitoredItems | Republish |
- | | TransferSubscription |
- | | DeleteSubscription |
- OPC UA, a web of nodes
- ----------------------
- The information model in each OPC UA server is a web of interconnected nodes. There are eight
- different types of nodes. Depending on its type, every node contains different attributes. Some
- attributes, such as the *NodeId* (unique identifier) and the *BrowseName*, are contained in all node
- types.
- <table>
- <tr> <td>ReferenceTypeNode</td> <td>MethodNode</td> </tr>
- <tr> <td>DataTypeNode</td> <td>ObjectTypeNode</td> </tr>
- <tr> <td>VariableTypeNode</td> <td>ObjectNode</td> </tr>
- <tr> <td>VariableNode</td> <td>ViewNode</td> </tr>
- </table>
-
- Nodes are interconnected by directed reference-triples of the form `(nodeid, referencetype,
- target-nodeid)`. Therefore an OPC UA information model is easiest imagined as a __web of nodes__.
- Reference types can be
- - standard- or user-defined and
- - either non-hierarchical (e.g., indicating the type of a variable-node) or hierarchical (e.g., indicating a parent-child relationship).
- OPC UA, a protocol
- ------------------
- The OPC UA protocol (both binary and XML-based) is based on 25 *built-in* datatypes. In open62541, these
- are defined in ua_types.h.
- <table>
- <tr> <td>Boolean</td> <td>Float</td> <td>StatusCode</td> </tr>
- <tr> <td>SByte</td> <td>Double</td> <td>QualifiedName</td> </tr>
- <tr> <td>Byte</td> <td>String</td> <td>LocalizedText</td> </tr>
- <tr> <td>Int16</td> <td>DateTime</td> <td>ExtensionObject</td> </tr>
- <tr> <td>UInt16</td> <td>Guid</td> <td>DataValue</td> </tr>
- <tr> <td>Int32</td> <td>ByteString</td> <td>Variant</td> </tr>
- <tr> <td>UInt32</td> <td>XmlElement</td> <td>DiagnosticInfo</td> </tr>
- <tr> <td>Int64</td> <td>NodeId</td> <td> </td> </tr>
- <tr> <td>UInt64</td> <td>ExpandedNodeId</td> <td> </td> </tr>
- </table>
- The builtin datatypes are combined to more complex structures. When the structure contains an array,
- then the size of the array is stored in an Int32 value just before the array itself. A size of -1
- indicates an undefined array. Positive size (and zero) have the usual semantics.
- Most importantly, every service has a request and a response message defined as such a data
- structure. Their exact definitions can be looked up here:
- https://opcfoundation.org/UA/schemas/Opc.Ua.Types.bsd.xml. In open62541, we autogenerate the
- C-structs to handle the standard-defined structures automatically. See ua_types_generated.h for
- comparison. The entire OPC UA protocol revolves around the exchange of these request and response messages.
- */
|
