 |
UA Ansi C Server Professional
1.3.1.232
|
|
UA Ansi C Server Professional
1.3.1.232
|
This lesson explains how to create a UA Server Address Space in order to describe a real world system with UA.
Content:
The real world example used for this getting started lesson is an arbitrary machine that contains a heating element and a temperature sensor. Figure 2-1 shows the object types and their variables in the OPC UA notation.
This lesson only creates the object types and object instances with data variables and properties. Additional features like methods and events are added in the following lessons.
Figure 2-1 gives you an overview of the OPC UA object types MachineType and TemperatureSensorType. Both are directly derived from the BaseObjectType. The variable types of the different variable components are indicated in the figure.
Providers are responsible for managing a set of nodes for one OPC UA Namespace and for processing UA service calls concerning the provider's nodes. See SDK Tutorial - How to create a new data provider for detailed information. In this example we create a new provider called CustomProvider.
Initialization function
For integrating the provider into the server, all it needs to have is an initialization function of the type UaServer_pfInitializeProvider. This function is called by the SDK on startup of the server.
In this function we store the provided parameters for later use. The provider interface is filled with pointers to the functions that will handle the according service calls for the nodes of the provider. For that we use generic functions that check if the UA service call affects any of the provider's nodes and call the SDK's internal convenience functions to process the service call. Details about these handlers will follow in Step 5: Handling UA Service Calls .
Register address space and initialize provider
We also want to create some nodes, so we need to register an address space in the SDK. The namespace index returned by this function must be used for our new nodes, so we also store it. The size of the address space is chosen very generous and might be reduced if the numer of nodes that will be created is known at this point.
Finally the provider's nodes are created and the it's subscription management gets initialized:
Integrate the provider into the server
For adding the new provider to the server's list of providers, we add following code into the main startup sequence, right before UaServer_Providers_Initialize is being called:
For all of our nodes we use numeric NodeIds, starting with an identifier of 1. All node creation functions have a parameter a_pStartingNodeId that is incremented for each node, this way we can assure that the NodeIds used are unique in our namespace.
For creating the type and instance nodes the example provides some convenience functions. The first ones, CustomProvider_CreateMachineType and CustomProvider_CreateTemperatureSensorType, create all needed object types in the types tree of the server.
Create type nodes
For creating a new node, we need to pass the parent node as a parameter to the create function. In our case the new node will be a child of the BaseObjectType in the server address space, so we get the OpcUa_BaseNode representing this node. After that we can create a new ObjectType node called TemperatureSensorType in the address space.
Append properties
Our new object type should have a property Temperature which will represent the sensor's temperature. This property is created as a child of the previously created type and a default value is assigned.
Add modelling rules
Finally, a modelling rule reference is created between the type and the property to define that every instance of the type needs to have this property.
Creating the MachineType follows the same steps as Step 2: Creating the TemperatureSensorType, with one exception: all machines should contain a TemperatureSensor object.
Add instance declarations
For this we need to create a TemperatureSensor instance as child of the MachineType and mark it as mandatory.
Now that the object types we want to use are created, we can instantiate them in the server. For that, the convenience function CustomProvider_CreateMachine is used, passing the names of the nodes to create, the NodeIds of the object types we created in the previous steps and a pointer to the node which should be the parent of the newly created machine.
The new machine instance is placed in a folder 'Custom provider' that is created for grouping all nodes of our provider.
The UA service call handlers of the provider are generic functions that work on the OpcUa_BaseNode nodes managed by the SDK. For providers using these nodes, the SDK provides helper functions for processing the service calls. The following code uses the Read service as an example, the other service calls are processed similarly.
Prepare the SDK to receive one callback
The UA service handlers of a provider can process the calls asynchronously, this is why every call context has a member nOutstandingCbs. The provider increments this value by the number of callbacks it will send before processing the request and decrements the value when it has finished. In our case one callback will be sent as the processing is done synchronously, so we increment the value by one.
Check if the request needs to be processed
The next step is to check if we are responsible for processing the request. This is the case if the namespace index of a node is the namespace index of our provider. If this is true, we retrieve the OpcUa_BaseNode represented by the NodeId for working with it.
Test access rights and process the request
Now we can check if the node is readable by checking the AccessLevel of it. If this test is passed, we call the SDK's helper function UaServer_ReadInternal to process the service call for us.
Send callback
Now we must call the callback function of the SDK to inform it that we are finished with processing the call. After all expected callbacks have been sent to the SDK, it will trigger sending the response to the client.
