The content of this OPC UA Companion Specification is based on the asset administration shell for pumps and vacuum pumps. The asset administration shell and its submodels were modeled to describe the whole life cycle of a Pump.
The organization Plattform Industrie 4.0 published the specification Details [2] of the Asset Administration Shell to define the concept and metamodel for asset administration shells. The specification describes every aspect of asset administration shells in detail and should be used for reference purposes.
Figure 6 shows an abstract example on the composition of an I4.0 component and the content of an asset administration shell.
Figure 6 – Structure of an Asset Administration Shell
An asset administration shell is defined by the Plattform Industrie 4.0 organization as a “standardized digital representation of the asset, corner stone of the interoperability between the applications managing the manufacturing systems. It identifies the Administration Shell and the assets represented by it, holds digital models of various aspects (submodels) and describes technical functionality exposed by the Administration Shell or respective assets. ”
The content of an asset administration shells consists of submodels and properties. “Each submodel refers to a well-defined domain or subject matter. Submodels can become standardized and thus become submodels templates.”
This OPC UA Companion Specification transfers the contents of the asset administration shell for pumps and vacuum pumps into an OPC UA model by defining generic and specific ObjectTypes, VariableTypes and DataTypes. In general, submodels are modeled as subtypes of the 2:FunctionalGroupType of OPC 10000-100. The pump, i.e. the asset administration shell, is modeled as a subtype of the 2:TopologyElementType of OPC 10000-100.
For more information about the asset administration shell metamodel, it is recommended to consult the Details of the Asset Administration Shell specification [2].
In this OPC UA Companion Specification there are several subtypes of the 2:FunctionalGroupType and the 2:TopologyElementType defined. Figure 7 shows the general relationships between the PumpType and the FunctionalGroups.
Figure 7 – Pumps & Vacuum Pumps Information Model (General - Structure)
A Pump has several Ports. While most Pumps have inlet and outlet Ports, the number of other Ports may vary. For this reason, the concept of Ports is introduced. Ports can be used to connect other components or systems to the Pump. In this specification, the input and output Ports, as well as the drive Port for the connection of the pump drive are defined. A port is not part of a submodel and therefore a port is modeled as a separate BaseObject and not, like submodels, as a FunctionalGroup. Figure 8 shows how the Port concept was integrated into this OPC UA Companion Specification.
Figure 8 – Pumps & Vacuum Pumps Information Model (Ports - Structure)
In most cases Variables have the TypeDefinition 0:DataItemType or one of its subtypes. The optional Property Definition can be added to a Variable that uses such a TypeDefinition. This allows manufacturers to store a specific definitions for each Variable.
Variables defined in this specification that have the TypeDefinition 0:BaseAnalogType or one of its subtypes, usually have a predefined unit for the 0:EngineeringUnits Property. If no value is specified, the 0:EngineeringUnits Property should not be instantiated, or the Value Attribute shall be Null. To comply with this Companion Specification, the default values specified should be used for the 0:EngineeringUnits Property. The 0:EngineeringUnits should be sensible to the use of the application.
Variables that use the DataType Boolean are modelled with the TypeDefinition 0:TwoStateDiscreteType. Such Variables have the TrueState and FalseState Properties which shall be used for defining the actual states.
Variables that are children of the SupvervisionType or one of its subtypes represent supervision states. Such a supervision state is active if the Boolean value is True (see example 1).
Variables that are not children of SupvervisionType or one of its subtypes provide defined True and False states in their description (see Example 2).
EXAMPLE 1If the Value Attribute of the Variable RotorBlocked (see section 7.12) is True, this means that the rotor of a pump is blocked. If the Value Attribute of this Variable is False, it means that the rotor is not blocked.
EXAMPLE 2The Variable ClockwiseRotation (see section 7.20) provides in the Description Attribute the Value Attributes for the mandatory Properties TrueState and FalseState. Description Attribute: Direction of rotation in which the shaft is seen to be turning in a clockwise direction when viewing the drive end of the shaft. A "True" status means that the rotation of pump is clockwise and a "False" status means that the rotation of pump is anticlockwise.
Where it made sense, the BrowseName of a FunctionalGroup was taken from the recommendation in OPC 10000-100.
A FunctionalGroup that would have no Variables, Objects, or Methods if instantiated shall not be instantiated.
The manufacturer or system integrator of a Pump may wish to add Variables, Objects, or Methods which are not yet defined by this specification. In such a case the additional Variables, Objects, or Methods shall be added to an appropriate FunctionalGroup of the component. It is important, that the Variables, Objects, or Methods which are added match the description of the FunctionalGroup they are added to. If there is no FunctionalGroup available the Variables, Objects, and Methods fit in, the manufacturer or system integrator shall create a new Object of the 2:FunctionalGroupType.
It is also possible to define a subtype of the 2:FunctionalGroupType or one of its subtypes to define a new collection of Variables, Objects, or Methods. When subtyping, the manufacturer or system integrator should keep in mind, that all Variables, Objects, and Methods of the supertype are also available to the new subtype.
In general, no new Variables, Objects, or Methods shall be created that are already available in this specification. If the manufacturer or system integrator wants to add already existing Variables, Objects, or Methods to another FunctionalGroup, the Organizes ReferenceType shall be used.
When creating new Variables that are not specified by this specification and are representing measurements the 0:BaseAnalogType should be used as TypeDefinition. If such a Variable can be matched to a physical quantity, this Variable should have the additional subcomponent KindOfQuantity that stores the physical quantity information (see chapter 7.32). If the new Variable has a predefined unit, for example hours or meters, the optional Property 0:EngineeringUnits should be used. The Property 0:Definition shall also be used to further clarify the intended purpose of the Variable.