Log In
Home
04/17/2015
Offline
When developing an OPC UA server and information model in an agile way, it means releasing new versions often.
Lets take an example:
Version 1 of the information model defines a VehicleType with subclasses TruckType and CarType.
In the next release of the model we want to add a new property Color to VehicleType.
We have considered adding Color as an Optional component or subclassing VehicleType into Vehicle2Type.
Questions:
- Are there any guidelines about adding new variables/objects/methods to existing type definitions in new versions of a model?
- Are there rules in OPC UA describing allowed changes in major or minor model version updates? For example is it allowed to add a new Mandatory property to an existing type in a major version update?
05/30/2017
Offline
Changes to information model must be backward compatible.
Adding optional components are fine.
You can never add new mandatory components.
If necessary you must add sub-classes that make an optional component from the parent mandatory.
There are no major/minor versions. Only the PublicationDate in the NodeSet.
If an is designed against a model with PublicationDate=X it should work for any PublicationDate>Y
04/17/2015
Offline
Thank you for the quick reply.
This does seem to be incompatible with the agile workflow: frequent releases of the server and model are done with incremental updates. For servers of industrial machines with a long life-cycle (+20 years) maintaining and being able to extend the interfaces is an important aspect of the design.
The technique of sub-classing at first seems a good idea but quickly results in a complex/unmanageable type hierarchy. Consider the following situation:
V1
VehicleType
|_ CarType
|_ TruckType
V2 Number of doors added to CarType
VehicleType
|_CarType
|_Car2Type
|_NumberOfDoors
|_TruckType
V3: Color is added as a Vehicle property
VehicleType
|_CarType
|_Car2Type
|_NumberOfDoors
|_Car3Type?
|_Color? (is not the same Color property as at the Vehicle2Type, only the same name)
|_TruckType
|_Vehicle2Type
|_Color
|_Car4Type?
|_NumberOfDoors (is not the same NumberOfDoors property as at the Car2Type, only the same name)
|_Truck2Type
As you can see both solutions have some mayor disadvantages. Mixing “real” sub-types like a Car and “version” sub-types ends up in very complex type hierarchies.
The other concept is to add new optional components to a type. If every extension developed over many years are optional, client developers will be confronted with an almost entirely optional hierarchy so handling all different combinations becomes complex for the client.
Is there a way to achieve that e.g. after a version 5.0 a client developer can be sure that a certain marked set of the components will certainly be there? So that the client developers can trust that every server supporting version >= 5.0 of the model has the marked components .
Except for adding mandatory/optional components or “version” sub-types does there exist an other concept of model version extensions in OPC UA?
E.g. adding comments or annotations in the specification indicating that a component has to be supported after a specific version; is that a known concept for OPC UA companion specifications?
1 Guest(s)
Usage Policy