The MotionDeviceSystemType provides a representation of a motion device system as an entry point to the OPC UA device set. At least one instance of a MotionDeviceSystemType must be instantiated in the DeviceSet. This instance organises the information model of a complete robotics system using instances of the described ObjectTypes.

Figure 12 – Overview MotionDeviceSystemType

Table 11 – MotionDeviceSystemType Definition

Attribute	Value
BrowseName	MotionDeviceSystemType
IsAbstract	False
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
Subtype of the ComponentType defined in OPC Unified Architecture for Devices (DI)
HasComponent	Object	MotionDevices		FolderType	Mandatory
HasComponent	Object	Controllers		FolderType	Mandatory
HasComponent	Object	SafetyStates		FolderType	Mandatory
The following instance declarations are not defined by this type, but by the supertype ComponentType and repeated here for better readability
HasProperty	Variable	2:ComponentName	LocalizedText	PropertyType	Optional

Table 12 – TypeDefinition of MotionDevices of MotionDeviceSystemType

Attribute	Value
BrowseName	MotionDevices
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
HasComponent	Object	<MotionDeviceIdentifier>		MotionDeviceType	MandatoryPlaceholder

Table 13 – TypeDefinition of Controllers of MotionDeviceSystemType

Attribute	Value
BrowseName	Controllers
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
HasComponent	Object	<ControllerIdentifier>		ControllerType	MandatoryPlaceholder

Table 14 – TypeDefinition of SafetyStates of MotionDeviceSystemType

Attribute	Value
BrowseName	SafetyStates
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
HasComponent	Object	<SafetyStateIdentifier>		SafetyStateType	MandatoryPlaceholder

A motion device system may consist of multiple motion devices, controllers and safety systems. References are used to describe the relations between those subsystems. Examples are described in Annex B.1.

The ComponentName property provides a user writeable name provided by the vendor, integrator or user of the device. The ComponentName may be a default name given by the vendor. This property is defined by ComponentType defined in OPC UA DI.

MotionDevices is a container for one or more instances of the MotionDeviceType.

Controllers is a container for one or more instances of the ControllerType.

SafetyStates is a container for one or more instances of the SafetyStatesType.

The MotionDeviceType describes one independent motion device, e.g. a manipulator, a turn table or a linear axis. Examples are described in Annex B.1.

A MotionDevice shall have at least one axis and one power train. The MotionDeviceType is formally defined in Figure 14.

Figure 13 – Overview MotionDeviceType

Table 15 – MotionDeviceType Definition

Attribute	Value
BrowseName	MotionDeviceType
IsAbstract	False
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
Subtype of the ComponentType defined in OPC Unified Architecture for Devices (DI)
HasProperty	Variable	2:SerialNumber	String	PropertyType	Mandatory
HasProperty	Variable	2:Manufacturer	LocalizedText	PropertyType	Mandatory
HasProperty	Variable	2:Model	LocalizedText	PropertyType	Mandatory
HasProperty	Variable	2:ProductCode	String	PropertyType	Mandatory
HasProperty	Variable	MotionDeviceCategory	MotionDeviceCategoryEnumeration	PropertyType	Mandatory
HasComponent	Object	2:ParameterSet		BaseObjectType	Mandatory
HasComponent	Object	Axes		FolderType	Mandatory
HasComponent	Object	PowerTrains		FolderType	Mandatory
HasComponent	Object	FlangeLoad		LoadType	Optional
HasComponent	Object	AdditionalComponents		FolderType	Optional
The following instance declarations are not defined by this type, but by the supertype ComponentType and repeated here for better readability
HasProperty	Variable	2:AssetId	String	PropertyType	Optional
HasProperty	Variable	2:DeviceManual	String	PropertyType	Optional
HasProperty	Variable	2:ComponentName	LocalizedText	PropertyType	Optional

The SerialNumber property is a unique production number assigned by the manufacturer of the device. This is often stamped on the outside of the device and may be used for traceability and warranty purposes. This property is derived from ComponentType defined in OPC UA DI.

The Manufacturer property provides the name of the company that manufactured the device. This property is derived from ComponentType defined in OPC UA DI.

The Model property provides the name of the product. This property is derived from ComponentType defined in OPC UA DI.

The ProductCode property provides a unique combination of numbers and letters used to identify the product. It may be the order information displayed on type shields or in ERP systems. This property is derived from ComponentType defined in OPC UA DI.

The AssetId property is a user writable alphanumeric character sequence uniquely identifying a component. The ID is provided by the vendor, integrator or user of the device. It contains typically an identifier in a branch, use case or user specific naming scheme.

This could be for example a reference to an electric scheme. For electric schemes typically EN 81346-2 is used.

An use case could be to build up a location oriented view in a spare part management client software. It enables to identify parts with the same article number which is not possible if this entry is not used.

This property is defined by ComponentType defined in OPC UA DI.

The DeviceManual property allows specifying an address of the user manual for the device. It may be a pathname in the file system or a URL (Web address). This property is defined by ComponentType defined in OPC UA DI.

The ComponentName property provides a user writeable name provided by the vendor, integrator or user of the device. The ComponentName may be a default name given by the vendor. This property is defined by ComponentType defined in OPC UA DI.

The variable MotionDeviceCategory provides the kind of motion device defined by MotionDeviceCategoryEnumeration based on ISO 8373.

Table 16 – MotionDeviceCategoryEnumeration

MotionDeviceCategoryEnumeration
EnumString	Value	Description
OTHER	0	Any motion-device which is not defined by the MotionDeviceCategoryEnumeration
ARTICULATED_ROBOT	1	This robot design features rotary joints and can range from simple two joint structures to 10 or more joints. The arm is connected to the base with a twisting joint. The links in the arm are connected by rotary joints.
SCARA_ROBOT	2	Robot has two parallel rotary joints to provide compliance in a selected plane
CARTESIAN_ROBOT	3	Cartesian robots have three linear joints that use the Cartesian coordinate system (X, Y, and Z). They also may have an attached wrist to allow for rotational movement. The three prismatic joints deliver a linear motion along the axis.
SPHERICAL_ROBOT	4	The arm is connected to the base with a twisting joint and a combination of two rotary joints and one linear joint. The axes form a polar coordinate system and create a spherical-shaped work envelope.
PARALLEL_ROBOT	5	These spider-like robots are built from jointed parallelograms connected to a common base. The parallelograms move a single end of arm tooling in a dome-shaped work area.
CYLINDRICAL_ROBOT	6	The robot has at least one rotary joint at the base and at least one prismatic joint to connect the links. The rotary joint uses a rotational motion along the joint axis, while the prismatic joint moves in a linear motion. Cylindrical robots operate within a cylindrical-shaped work envelope.

Table 17 – ParameterSet of MotionDeviceType

Attribute	Value
BrowseName	AxisType
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
HasComponent	Variable	OnPath	Boolean	BaseDataVariableType	Optional
HasComponent	Variable	InControl	Boolean	BaseDataVariableType	Optional
HasComponent	Variable	SpeedOverride	Double	BaseDataVariableType	Mandatory

Description of ParameterSet of MotionDeviceType:

• Variable OnPath: The variable OnPath is true if the motion device is on or near enough the planned program path such that program execution can continue. If the MotionDevice deviates too much from this path in case of errors or an emergency stop, this value becomes false. If OnPath is false, the motion device needs repositioning to continue program execution.
• Variable InControl: The variable InControl provides the information if the actuators (in most cases a motor) of the motion device are powered up and in control: "true". The motion device might be in a standstill.
• Variable SpeedOverride: The SpeedOverride provides the current speed setting in percent of programmed speed (0 - 100%).

Axes is a container for one or more instances of the AxisType.

Table 18 – TypeDefinition of Axes of MotionDeviceType

Attribute	Value
BrowseName	Axes
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
HasComponent	Object	<AxisIdentifier>		AxisType	MandatoryPlaceholder

PowerTrains is a container for one or more instances of the PowerTrainType.

Table 19 –TypeDefinition of PowerTrains of MotionDeviceType

Attribute	Value
BrowseName	PowerTrains
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
HasComponent	Object	<PowerTrainIdentifier>		PowerTrainType	MandatoryPlaceholder

FlangeLoad provides data for the load at the flange or mounting-point of the motion device.

AdditionalComponents is a container for one or more instances of subtypes of ComponentType defined in OPC UA DI. The listed components are installed at the motion device, e.g. an IO-board.

NOTE: Components like motors or gears of a motion device are placed inside the power train object and not inside this AdditionalComponents container.

Table 20 – TypeDefinition of AdditionalComponents of MotionDeviceType

Attribute	Value
BrowseName	AdditionalComponents
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
HasComponent	Object	<AdditionalComponentIdentifier>		2:ComponentType	MandatoryPlaceholder

The AuxiliaryComponentType and DriveType are the only subtypes of ComponentType for use in this container which are described in this specification. The intention is to integrate inside this container devices which are defined in other companion specifications using DI.

The AxisType describes an axis of a motion device. It is formally defined in Table 21.

Figure 14 – Overview AxisType

Table 21 – AxisType Definition

Attribute		Value
BrowseName		AxisType
IsAbstract		False
References		Node Class		BrowseName	DataType		TypeDefinition	Modelling Rule
Subtype of the ComponentType defined in OPC Unified Architecture for Devices (DI)
HasProperty		Variable		MotionProfile	AxisMotionProfileEnumeration		PropertyType	Mandatory
HasComponent		Object		AdditionalLoad			LoadType	Optional
HasComponent		Object		2:ParameterSet			BaseObjectType	Mandatory
Requires		Object		<PowerTrainIdentifier>			PowerTrainType	OptionalPlaceholder
The following instance declarations are not defined by this type, but by the supertype ComponentType and repeated here for better readability
HasProperty	Variable		2:AssetId			String	PropertyType		Optional

The AssetId property is a user writable alphanumeric character sequence uniquely identifying a component. The ID is provided by the vendor, integrator or user of the device. It contains typically an identifier in a branch, use case or user specific naming scheme.

This could be for example a reference to an electric scheme. For electric schemes typically EN 81346-2 is used.

The AssetID of the AxisType provides a manufacturer-specific axis identifier within the control system.

This property is defined by ComponentType defined in OPC UA DI.

The MotionProfile property provides the kind of axis motion as defined by the AxisMotionProfileEnumeration.

Table 22 – AxisMotionProfileEnumeration

AxisMotionProfileEnumeration
EnumString	Value	Description
OTHER	0	Any motion-profile which is not defined by the AxisMotionProfileEnumeration
ROTARY	1	Rotary motion is a rotation along a circular path with defined limits. Motion movement is not going always in the same direction. Control unit is mainly degree.
ROTARY_ENDLESS	2	Rotary motion is a rotation along a circular path with no limits. Motion movement is going endless in the same direction. Control unit is mainly degree.
LINEAR	3	Linear motion is a one dimensional motion along a straight line with defined limits. Motion movement is not going always in the same direction. Control unit is mainly mm.
LINEAR_ENDLESS	4	Linear motion is a one dimensional motion along a straight line with no limits. Motion movement is going endless in the same direction. Control unit is mainly mm.

AdditionalLoad provides data for the load that is mounted on this axis, e.g., a transformer for welding.

Table 23 – ParameterSet of AxisType

Attribute	Value
BrowseName	AxisType
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
HasComponent	Variable	ActualPosition	Double	AnalogUnitType	Mandatory
HasComponent	Variable	ActualSpeed	Double	AnalogUnitType	Optional
HasComponent	Variable	ActualAcceleration	Double	AnalogUnitType	Optional

Description of ParameterSet of AxisType:

• Variable ActualPosition: The ActualPosition variable provides the current position of the axis and may have limits. If the axis has physical limits, the EURange property of the AnalogUnitType shall be provided.
• Variable ActualSpeed: The ActualSpeed variable provides the axis speed. Applicable speed limits of the axis shall be provided by the EURange property of the AnalogUnitType
• Variable ActualAcceleration: The ActualAcceleration variable provides the axis acceleration. Applicable acceleration limits of the axis shall be provided by the EURange property of the AnalogUnitType.

The Requires reference provides the relationship of axes to power trains. For complex kinematics this does not need to be a one to one relationship, because more than one power train might influence the motion of one axis. This reference connects all power trains to an axis that must be actively driven when only this axis should move and all other axes should stand still.

Virtual axes that are not actively driven by a power train do not have this reference. The InverseName is IsRequiredBy.

The PowerTrainType represents instances of power trains of a motion device and is formally defined in Table 24. A power train typically consists of one motor and gear to provide the required torque. Often there is a one-to-one relation between axes and power trains, but it is also possible to have axis coupling and thus one power train can move multiple axes and one axis can be moved by multiple power trains. One power train can have multiple drives, motors and gears when these components move logically the same axes, for example in a master/slave setup. Examples are described in Annex B.1.

Figure 15 – Overview PowerTrainType

Table 24 – PowerTrainType Definition

Attribute	Value
BrowseName	PowerTrainType
IsAbstract	False
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
Subtype of the ComponentType defined in OPC Unified Architecture for Devices (DI)
HasComponent	Object	<MotorIdentifier>		MotorType	MandatoryPlaceholder
HasComponent	Object	<GearIdentifier>		GearType	OptionalPlaceholder
Moves	Object	<AxisIdentifier>		AxisType	OptionalPlaceholder
HasSlave	Object	<PowerTrainIdentifier>		PowerTrainType	OptionalPlaceholder
The following instance declarations are not defined by this type, but by the supertype ComponentType and repeated here for better readability
HasProperty	Variable	2:ComponentName	LocalizedText	PropertyType	Optional

The ComponentName property provides a user writeable name provided by the vendor, integrator or user of the device. The ComponentName may be a default name given by the vendor.

The ComponentName of the PowerTrainType provides a manufacturer-specific power train identifier within the control system.

This property is defined by ComponentType defined in OPC UA DI.

<MotorIdentifier> indicates that a power train contains one or more motors represented by MotorType instances.

<GearIdentifier> indicates that a power train may contain one or more gears represented by GearType instances.

Moves is a reference to provide the relationship of power trains to axes. For complex kinematics this does not need to be a one to one relationship, because a power train might influence the motion of more than one axis. This reference connects all axis to a power train that that move when only this power train moves and all other powertains stand still.

The InverseName is IsMovedBy.

HasSlave is a reference to provide the master-slave relationship of power trains which provide torque for a common axis. The InverseName is IsSlaveOf.

The MotorType describes a motor in a power train. It is formally defined in Table 25.

Figure 16 – Overview MotorType

Table 25 – MotorType Definition

Attribute	Value
BrowseName	MotorType
IsAbstract	False
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
Subtype of the ComponentType defined in OPC Unified Architecture for Devices (DI)
HasProperty	Variable	2:SerialNumber	String	PropertyType	Mandatory
HasProperty	Variable	2:Manufacturer	LocalizedText	PropertyType	Mandatory
HasProperty	Variable	2:Model	LocalizedText	PropertyType	Mandatory
HasProperty	Variable	2:ProductCode	String	PropertyType	Mandatory
IsConnectedTo	Object	<GearIdentifier>		GearType	OptionalPlaceholder
HasComponent	Object	2:ParameterSet		BaseObjectType	Mandatory
IsDrivenBy	Object	<DriveIdentifiier>		BaseObjectType	OptionalPlaceholer
The following instance declarations are not defined by this type, but by the supertype ComponentType and repeated here for better readability
HasProperty	Variable	2:AssetId	String	PropertyType	Optional

The SerialNumber property is a unique production number assigned by the manufacturer of the device. This is often stamped on the outside of the device and may be used for traceability and warranty purposes. This property is derived from ComponentType defined in OPC UA DI.

The Manufacturer property provides the name of the company that manufactured the device. This property is derived from ComponentType defined in OPC UA DI.

The Model property provides the name of the product. This property is derived from ComponentType defined in OPC UA DI.

The ProductCode property provides a unique combination of numbers and letters used to identify the product. It may be the order information displayed on type shields or in ERP systems. This property is derived from ComponentType defined in OPC UA DI.

The AssetId property is a user writable alphanumeric character sequence uniquely identifying a component. The ID is provided by the vendor, integrator or user of the device. It contains typically an identifier in a branch, use case or user specific naming scheme.

This could be for example a reference to an electric scheme. For electric schemes typically EN 81346-2 is used.

An use case could be to build up a location oriented view in a spare part management client software. It enables to identify parts with the same article number which is not possible if this entry is not used.

This property is defined by ComponentType defined in OPC UA DI.

IsConnectedTo is a reference to provide the relationship between a motor and a gear of a power train.

IsDrivenBy is a reference to provide a relationship from a motor to a drive, which can be a multi-slot-drive or single slot drive. The TypeDefinition of the reference destination as BaseObjectType provides the possibility to point to a slot of a mulit-slot-drive or a motor-integrated-drive. If this reference points to a physical drive (and not a drive slot) it should point to an DriveType.

Annex B.1.9 shows different possibilities of usage.

Table 26 – ParameterSet of MotorType

Attribute	Value
BrowseName	ParameterSet
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
HasComponent	Variable	BrakeReleased	Boolean	BaseDataVariableType	Optional
HasComponent	Variable	MotorTemperature	Double	AnalogUnitType	Mandatory
HasComponent	Variable	EffectiveLoadRate	UInt16	BaseDataVariableType	Optional

Description of ParameterSet of MotorType:

• Variable BrakeReleased: The BrakeReleased is an optional variable used only for motors with brakes. If BrakeReleased is TRUE the motor is free to run. FALSE means that the motor shaft is locked by the brake.
• Variable MotorTemperature: The MotorTemperature provides the temperature of the motor. If there is no temperature sensor the value is set to “null”.
• Variable EffectiveLoadRate: EffectiveLoadRate is expressed as a percentage of maximum continuous load. The Joule integral is typically used to calculate the current load, i.e.:

Duration should be defined and documented by the vendor.

The GearType describes a gear in a power train, e.g. a gear box or a spindle. It is formally defined in Table 27.

Figure 17 – Overview GearType

Table 27 – GearType Definition

Attribute	Value
BrowseName	GearType
IsAbstract	False
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
Subtype of the ComponentType defined in OPC Unified Architecture for Devices (DI)
HasProperty	Variable	2:SerialNumber	String	PropertyType	Mandatory
HasProperty	Variable	2:Manufacturer	LocalizedText	PropertyType	Mandatory
HasProperty	Variable	2:Model	LocalizedText	PropertyType	Mandatory
HasProperty	Variable	2:ProductCode	String	PropertyType	Mandatory
HasComponent	Variable	GearRatio	RationalNumber	RationalNumberType	Mandatory
HasComponent	Variable	Pitch	Double	BaseDataVariableType	Optional
IsConnectedTo	Object	<MotorIdentifier>		MotorType	OptionalPlaceholder
The following instance declarations are not defined by this type, but by the supertype ComponentType and repeated here for better readability
HasProperty	Variable	2:AssetId	String	PropertyType	Optional

In case of a one to one relation between powertrains and axes, gear ratio and pitch may reflect the relation between motor and axis velocities. This is not possible when axis coupling is involved because different ratios for all motor-axis combinations may be needed. Additionally, there could be a nonlinear coupling between the load side of the gear box and the axis. Thus GearRatio and Pitch only reflect the properties of the physical gear box and it may not be possible to use these values to transform between axis and motor movements.

The SerialNumber property is a unique production number assigned by the manufacturer of the device. This is often stamped on the outside of the device and may be used for traceability and warranty purposes. This property is derived from ComponentType defined in OPC UA DI.

The Manufacturer property provides the name of the company that manufactured the device. This property is derived from ComponentType defined in OPC UA DI.

The Model property provides the name of the product. This property is derived from ComponentType defined in OPC UA DI.

The ProductCode property provides a unique combination of numbers and letters used to identify the product. It may be the order information displayed on type shields or in ERP systems. This property is derived from ComponentType defined in OPC UA DI.

The AssetId property is a user writable alphanumeric character sequence uniquely identifying a component. The ID is provided by the vendor, integrator or user of the device. It contains typically an identifier in a branch, use case or user specific naming scheme.

This could be for example a reference to an electric scheme. For electric schemes typically EN 81346-2 is used.

An use case could be to build up a location oriented view in a spare part management client software. It enables to identify parts with the same article number which is not possible if this entry is not used. This property is defined by ComponentType defined in OPC UA DI.

GearRatio is the transmission ratio of the gear expressed as a fraction as input velocity (motor side) by output velocity (load side).

RationalNumberType and RationalNumber are defined in the OPC 10001-11 (SpatialTypes).

Pitch describes the distance covered in millimeters (mm) for linear motion per one revolution of the output side of the driving unit. Pitch is used in combination with GearRatio to describe the overall transmission from input to output of the gear.

Calculation formula:

IsConnectedTo is a reference to provide the relationship between a motor and a gear of a power train.

SafetyStateType describes the safety states of the motion devices and controllers. One motion device system is associated with one or more instances of the SafetyStateType.

The SafetyStateType was modelled directly in the MotionDeviceSystemType for the following reasons:

• The manufacturers of systems have different concepts where safety is functional located, e.g. the hardware and software implementation.
• The safety state typically applies to the entire robotic system. If multiple safety state instances are implemented in robotic systems, these can be represented by individual instances of the SafetyStateType and associated with the controller by reference.

The safety state is for informational purpose only and not intended for use with functional safety applications as defined in ISO 61508.

The SafetyStateType is formally defined in Table 28.

Figure 18 – Overview SafetyStateType

Table 28 – SafetyStateType Definition

Attribute	Value
BrowseName	SafetyStateType
IsAbstract	False
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
Subtype of the ComponentType defined in OPC Unified Architecture for Devices (DI)
HasComponent	Object	EmergencyStopFunctions		FolderType	Optional
HasComponent	Object	ProtectiveStopFunctions		FolderType	Optional
HasComponent	Object	2:ParameterSet		BaseObjectType	Mandatory
The following instance declarations are not defined by this type, but by the supertype ComponentType and repeated here for better readability
HasProperty	Variable	2:ComponentName	LocalizedText	PropertyType	Optional

The ComponentName property provides a user writeable name provided by the vendor, integrator or user of the device. The ComponentName may be a default name given by the vendor. This property is defined by ComponentType defined in OPC UA DI.

EmergencyStopFunctions is a container for one or more instances of the EmergencyStopFunctionType. The number and names of emergency stop functions is vendor specific. When provided, this object contains a list of all emergency stop functions with names and current state. See description of EmergencyStopFunctionType for examples of emergency stop functions.

Table 29 – TypeDefinition of EmergencyStopFunctions of SafetyStateType

Attribute	Value
BrowseName	EmergencyStopFunctions
References	NodeClass	BrowseName	DataType	TypeDefinition	Modelling Rule
HasComponent	Object	<EmergencyStopFunctionIdentifier>		EmergencyStopFunctionType	Mandatory Placeholder

Table 30 – ObjectType EmergencyStopFunctionType

Attribute	Value
BrowseName	EmergencyStopFunctionType
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
Subtype of the BaseObjectType defined in OPC Unified Architecture
HasProperty	Variable	Name	String	PropertyType	Mandatory
HasComponent	Variable	Active	Boolean	BaseDataVariableType	Mandatory

Description of EmergencyStopFunctionType:

According to ISO 10218-1:2011 Ch.5.5.2 Emergency stop the robot shall have one or more emergency stop functions.

• The Name of the EmergencyStopFunctionType provides a manufacturer-specific emergency stop function identifier within the safety system.

The only named emergency stop function in the ISO 10218-1:2011 standard is the "Pendant emergency stop function". Other than that, the standard does not give any indication on naming of emergency stop functions.

• The Active variable is TRUE if this particular emergency stop function is active, e.g. that the emergency stop button is pressed, FALSE otherwise.

ProtectiveStopFunctions is a container for one or more instances of the ProtectiveStopFunctionType. The number and names of protective stop functions is vendor specific. When provided, this object contains a list of all protective stop functions with names and current state. See description of ProtectiveStopFunctionType for examples of protective stop functions.

Table 31 – TypeDefinition of ProtectiveStopFunctions of SafetyStateType

Attribute	Value
BrowseName	ProtectiveStopFunctions
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
HasComponent	Object	<ProtectiveStopFunctionIdentifier>		ProtectiveStopFunctionType	Mandatory Placeholder

Table 32 – ObjectType ProtectiveStopFunctionType

Attribute	Value
BrowseName	ProtectiveStopFunctionType
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
Subtype of the BaseObjectType defined in OPC Unified Architecture
HasProperty	Variable	Name	String	PropertyType	Mandatory
HasComponent	Variable	Enabled	Boolean	BaseDataVariableType	Mandatory
HasComponent	Variable	Active	Boolean	BaseDataVariableType	Mandatory

Description of ProtectiveStopFunctionType:

According to ISO 10218-1:2011 Ch.5.5.3 the robot shall have one or more protective stop functions designed for the connection of external protective devices.

• The Name of the ProtectiveStopFunctionType provides a manufacturer-specific protective stop function identifier within the safety system.
• The Enabled variable is TRUE if this protective stop function is currently supervising the system, FALSE otherwise. A protective stop function may or may not be enabled at all times, e.g. the protective stop function of the safety doors are typically enabled in automatic operational mode and disabled in manual mode. On the other hand for example, the protective stop function of the teach pendant enabling device is enabled in manual modes and disabled in automatic modes.
• The Active variable is TRUE if this particular protective stop function is active, i.e. that a stop is initiated, FALSE otherwise. If Enabled is FALSE then Active shall be FALSE.

Examples

The table below shows an example with a door interlock function. In this example, the door is only monitored during automatic modes. During manual modes, the operators may open the door without causing a protective stop.

Table 33 – Door Interlock Protective Stop Example

	Automatic Mode		Manual Mode
Door interlock	Enabled	Active	Enabled	Active
Door closed	TRUE	FALSE	FALSE	FALSE
Door open	TRUE	TRUE	FALSE	FALSE

The next example shows how the three-position enabling device normally found on teach pendants is processed. In this case it does not matter if the enabling device is pressed or not during automatic modes, while in manual modes, a protective stop is active as long as the enabling device is released or fully pressed.

Table 34 – Teach Pendant Enabling Device Protective Stop Example

	Automatic Mode		Manual Mode
Teach Pendant Enabling Device	Enabled	Active	Enabled	Active
Released	FALSE	FALSE	TRUE	TRUE
Middle position	FALSE	FALSE	TRUE	FALSE
Fully pressed (panic)	FALSE	FALSE	TRUE	TRUE

Table 35 – ParameterSet of SafetyStateType

Attribute	Value
BrowseName	ParameterSet
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
HasComponent	Variable	OperationalMode	OperationalModeEnumeration	BaseDataVariableType	Mandatory
HasComponent	Variable	EmergencyStop	Boolean	BaseDataVariableType	Mandatory
HasComponent	Variable	ProtectiveStop	Boolean	BaseDataVariableType	Mandatory

Description of ParameterSet of SafetyStateType:

• Variable OperationalMode: The OperationalMode variable provides information about the current operational mode. Allowed values are described in OperationalModeEnumeration, see ISO 10218-1:2011 Ch.5.7 Operational Modes.
• Variable EmergencyStop: The EmergencyStop variable is TRUE if one or more of the emergency stop functions in the robot system are active, FALSE otherwise. If the EmergencyStopFunctions object is provided, then the value of this variable is TRUE if one or more of the listed emergency stop functions are active.
• Variable ProtectiveStop: The ProtectiveStop variable is TRUE if one or more of the enabled protective stop functions in the system are active, FALSE otherwise. If the ProtectiveStopFunctions object is provided, then the value of this variable is TRUE if one or more of the listed protective stop functions are enabled and active.

Table 36 – OperationalModeEnumeration

OperationalModeEnumeration
EnumString	Value	Description
OTHER	0	This value is used when there is no valid operational mode. Examples are: - During system-boot - The system is not calibrated (and hence can not verify cartesian position values) - There is a failure in the safety system itself
MANUAL_REDUCED_SPEED	1	"Manual reduced speed" - name according to ISO 10218-1:2011
MANUAL_HIGH_SPEED	2	"Manual high speed" - name according to ISO 10218-1:2011
AUTOMATIC	3	"Automatic" - name according to ISO 10218-1:2011
AUTOMATIC_EXTERNAL	4	"Automatic external" - Same as "Automatic" but with external control, e.g. by a PLC

The ControllerType describes the control unit of motion devices. One motion device system can have one or more instances of the ControllerType. The ControllerType is formally defined in Table 37.

Figure 19 – Overview ControllerType

Table 37 – ControllerType Definition

Attribute	Value
BrowseName	ControllerType
IsAbstract	False
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
Subtype of the ComponentType defined in OPC Unified Architecture for Devices (DI)
HasProperty	Variable	2:SerialNumber	String	PropertyType	Mandatory
HasProperty	Variable	2:Manufacturer	LocalizedText	PropertyType	Mandatory
HasProperty	Variable	2:Model	LocalizedText	PropertyType	Mandatory
HasProperty	Variable	2:ProductCode	String	PropertyType	Mandatory
HasComponent	Object	CurrentUser		UserType	Mandatory
HasComponent	Object	Components		FolderType	Optional
HasComponent	Object	Software		FolderType	Mandatory
HasComponent	Object	TaskControls		FolderType	Mandatory
HasComponent	Object	2:ParameterSet		BaseObjectType	Mandatory
HasSafetyStates	Object	<SafetyStatesIdentifier>		SafetyStateType	OptionalPlaceholder
Controls	Object	<MotionDeviceIdentifier>		MotionDeviceType	OptionalPlaceholder
The following instance declarations are not defined by this type, but by the supertype ComponentType and repeated here for better readability
HasProperty	Variable	2:AssetId	String	PropertyType	Optional
HasProperty	Variable	2:DeviceManual	String	PropertyType	Optional
HasProperty	Variable	2:ComponentName	LocalizedText	PropertyType	Optional

The SerialNumber property is a unique production number assigned by the manufacturer of the device. This is often stamped on the outside of the device and may be used for traceability and warranty purposes. This property is derived from ComponentType defined in OPC UA DI.

The Manufacturer property provides the name of the company that manufactured the device. This property is derived from ComponentType defined in OPC UA DI.

The Model property provides the name of the product. This property is derived from ComponentType defined in OPC UA DI.

The ProductCode property provides a unique combination of numbers and letters used to identify the product. It may be the order information displayed on type shields or in ERP systems. This property is derived from ComponentType defined in OPC UA DI.

The AssetId property is a user writable alphanumeric character sequence uniquely identifying a component. The ID is provided by the vendor, integrator or user of the device. It contains typically an identifier in a branch, use case or user specific naming scheme.

This could be for example a reference to an electric scheme. For electric schemes typically EN 81346-2 is used.

An use case could be to build up a location oriented view in a spare part management client software. It enables to identify parts with the same article number which is not possible if this entry is not used.

This property is defined by ComponentType defined in OPC UA DI.

The DeviceManual property allows specifying an address of the user manual for the controller. It may be a pathname in the file system or a URL (Web address). This property is defined by ComponentType defined in OPC UA DI.

The ComponentName property provides a user writeable name provided by the vendor, integrator or user of the device. The ComponentName may be a default name given by the vendor. This property is defined by ComponentType defined in OPC UA DI.

The CurrentUser obje provides information about the active vendor specific user level of the controller.

Components is a container for one or more instances of subtypes of ComponentType defined in OPC UA DI. The listed components are installed in the motion device system, e.g. a processing-unit, a power-supply, an IO-board or a drive, and have an electrical interface to the controller.

Table 38 – TypeDefinition of Components of ControllerType

Attribute	Value
BrowseName	Components
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
HasComponent	Object	<ComponentIdentifier>		2:ComponentType	MandatoryPlaceholder

The AuxiliaryComponentType and DriveType are the only subtypes of ComponentType for use in this container which are described in this specification. The intention is to integrate inside this container devices which are defined in other companion specifications using DI.

Software is a container for one or more instances of SoftwareType defined in OPC UA DI.

Each controller has at least one software installed.

Table 39 – TypeDefinition of Software of ControllerType

Attribute	Value
BrowseName	Software
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
HasComponent	Object	<SoftwareIdentifier>		2:SoftwareType	MandatoryPlaceholder

TaskControls is a container for one or more instances of TaskControlType.

Table 40 – TypeDefinition of TaskControls of ControllerTyp

Attribute	Value
BrowseName	TaskControls
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
HasComponent	Object	<TaskControlIdentifier>		TaskControlType	MandatoryPlaceholder

Table 41 – ParameterSet of ControllerType

Attribute	Value
BrowseName	ControllerType
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
HasComponent	Variable	TotalPowerOnTime	DurationString	BaseDataVariableType	Optional
HasComponent	Variable	StartUpTime	DateTime	BaseDataVariableType	Optional
HasComponent	Variable	UpsState	String	BaseDataVariableType	Optional
HasComponent	Variable	TotalEnergyConsumption	Double	AnalogUnitType	Optional
HasComponent	Variable	CabinetFanSpeed	Double	AnalogUnitType	Optional
HasComponent	Variable	CPUFanSpeed	Double	AnalogUnitType	Optional
HasComponent	Variable	InputVoltage	Double	AnalogUnitType	Optional
HasComponent	Variable	Temperature	Double	AnalogUnitType	Optional

Description of ParameterSet of ControllerType:

• Variable :The TotalPowerOnTime variable provides the total accumulated time the controller was powered on.
• Variable StartUpTime: The StartUpTime variable provides the date and time of the last start-up of the controller.
• Variable UpsState: The UpsState variable provides the vendor specific status of an integrated uninterruptible power supply or accumulator system.
• Variable TotalEnergyConsumption: The TotalEnergyConsumption variable provides total accumulated energy consumed by the motion devices related with this controller instance.
• Variable CabinetFanSpeed: The CabinetFanSpeed variable provides the speed of the cabinet fan.
• Variable CPUFanSpeed: The CPUFanSpeed variable provides the speed of the CPU fan.
• Variable InputVoltage: The InputVoltage variable provides the input voltage of the controller which can be a configured value. To distinguish between an AC or DC supply the optional property Definition of the base type DataItemType shall be used.
• Variable Temperature: The Temperature variable provides the controller temperature given by a temperature sensor inside of the controller.

The HasSafetyStates reference provides the relationship of safety states to a controller. The InverseName is SafetyStatesOf.

The Controls reference provides the relationship of a motion device and controller. The InverseName is IsControlledBy.

The AuxiliaryComponentType describes components mounted in a controller cabinet or a motion device e.g. an IO-board or a power supply.

It is formally defined in Table 42.

This type should not be used for instances of components which represent a motor, a gear or a drive For these components this specification describes specific types.

Figure 20 – Overview AuxiliaryComponentType

Table 42 – AuxiliaryComponentType Definition

Attribute	Value
BrowseName	AuxiliaryComponentType
IsAbstract	False
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
Subtype of the DeviceType defined in OPC Unified Architecture for Devices (DI)
HasProperty	Variable	2:ProductCode	String	PropertyType	Mandatory
The following instance declarations are not defined by this type, but by the supertype ComponentType and repeated here for better readability
HasProperty	Variable	2:AssetId	String	PropertyType	Optional

The ProductCode property provides a unique combination of numbers and letters used to identify the product. It may be the order information displayed on type shields or in ERP systems. This property is derived from ComponentType defined in OPC UA DI.

The AssetId property is a user writable alphanumeric character sequence uniquely identifying a component. The ID is provided by the vendor, integrator or user of the device. It contains typically an identifier in a branch, use case or user specific naming scheme.

This could be for example a reference to an electric scheme. For electric schemes typically EN 81346-2 is used.

An use case could be to build up a location oriented view in a spare part management client software. It enables to identify parts with the same article number which is not possible if this entry is not used.

This property is defined by ComponentType defined in OPC UA DI.

The DriveType describes drives (multi-slot or single-slot axis amplifier) mounted in a controller cabinet or a motion device. When used inside a motion device it should be part of a power train. It is formally defined in Table 42.

Annex B.1.9 shows different possibilities of usage.

Figure 21 – Overview DriveType

Table 43 – DriveType Definition

Attribute	Value
BrowseName	DriveType
IsAbstract	False
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
Subtype of the DeviceType defined in OPC Unified Architecture for Devices (DI)
HasProperty	Variable	2:ProductCode	String	PropertyType	Mandatory
The following instance declarations are not defined by this type, but by the supertype ComponentType and repeated here for better readability
HasProperty	Variable	2:AssetId	String	PropertyType	Optional

The ProductCode property provides a unique combination of numbers and letters used to identify the product. It may be the order information displayed on type shields or in ERP systems. This property is derived from ComponentType defined in OPC UA DI.

The AssetId property is a user writable alphanumeric character sequence uniquely identifying a component. The ID is provided by the vendor, integrator or user of the device. It contains typically an identifier in a branch, use case or user specific naming scheme.

This could be for example a reference to an electric scheme. For electric schemes typically EN 81346-2 is used.

An use case could be to build up a location oriented view in a spare part management client software. It enables to identify parts with the same article number which is not possible if this entry is not used.

This property is defined by ComponentType defined in OPC UA DI.

The TaskControlType represents instances of task controls of a controller and is formally defined in Table 44.

The task control describes an execution engine that loads and runs task programs. One task runs one task program at the time. The system should instantiate the maximum allowed number of task controls.

Figure 22 – Overview TaskControlType

Table 44 – TaskControlType Definition

Attribute	Value
BrowseName	TaskControlType
IsAbstract	False
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
Subtype of the ComponentType defined in OPC Unified Architecture for Devices (DI)
HasProperty	Variable	2:ComponentName	LocalizedText	PropertyType	Mandatory
HasComponent	Object	2:ParameterSet		BaseObjectType	Mandatory
Controls	Object	<MotionDeviceIdentifier>		MotionDeviceType	OptionalPlaceholder

The ComponentName property provides a user writeable name provided by the vendor, integrator or user of the device.

The ComponentName of the TaskControlType provides a customer given identifier for the task control or a default name given by the vendor. This property is derived from ComponentType defined in OPC UA DI.

Table 45 – ParameterSet of TaskControlType

Attribute	Value
BrowseName	ParameterSet
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
HasComponent	Variable	TaskProgramName	String	BaseDataVariableType	Mandatory
HasComponent	Variable	TaskProgramLoaded	Boolean	BaseDataVariableType	Mandatory
HasComponent	Variable	ExecutionMode	Enumeration	ExecutionModeEnumeration	Optional

Description of ParameterSet of TaskControlType:

• Variable TaskProgramName: The TaskProgramName variable provides a customer given identifier for the task program.
• Variable TaskProgramLoaded: The TaskProgramLoaded variable is TRUE if a task program is loaded in the task control, FALSE otherwise.
• Variable ExecutionMode: The ExecutionMode variable tells how the task control executes the task program.

Table 46 – ExecutionModeEnumeration

ExecutionModeEnumeration
EnumString	Value	Description
CYCLE	0	Single execution of a task program according to ISO 8373
CONTINUOUS	1	Task program is executed continuously and starts again automatically
STEP	2	Task program is executed in steps

Controls is a reference to provide the relationship between a task control and a motion device. The InverseName is IsControlledBy.

The LoadType is for describing loads mounted on the motion device typically by an integrator or a customer and is formally defined in Table 47. Instances of this ObjectType definition are used to describe the load mounted on one of several mounting points. A very common mounting point is the flange of a motion device. Typically a motion device has additional mounting points on some of the axis. The provided values can either be determined by the robot controller or can be set up by an operator.

Figure 23 – Overview LoadType

Table 47 – LoadType Definition

Attribute	Value
BrowseName	LoadType
IsAbstract	False
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
Subtype of the BaseObjectType defined in OPC Unified Architecture
HasComponent	Variable	Mass	Double	AnalogUnitType	Mandatory
HasComponent	Variable	CenterOfMass	3DFrame	3DFrameType	Optional
HasComponent	Variable	Inertia	3DVector	3DVectorType	Optional

The variable Mass provides the weight of the load mounted on one mounting point.

The EngineeringUnits of the Mass shall be provided.

The variable CenterOfMass provides the position and orientation of the center of the mass related to the mounting point using a 3DFrameType. X, Y, Z define the position of the center of gravity relative to the mounting point coordinate system. A, B, C define the orientation of the principal axes of inertia relative to the mounting point coordinate system. Orientation A, B, C can be "0" for systems which do not need these values.

3DFrameType and 3DFrame are defined in OPC 10001-11 (SpatialTypes).

If the instance of the LoadType describes the flange load of a motion device the mounting point coordinate system is the flange coordinate system. If the instance of the LoadType describes an additional load of an axis the mounting point coordinate system is vendor specific and it is up to the vendor to model this coordinate system.

The variable Inertia uses the 3DVektorType to describe the three values of the principal moments of inertia with respect to the mounting point coordinate system. If inertia values are provided for rotary axis the CenterOfMass shall be completely filled as well. Table 48 describes the possible degrees of modelling from a minimal one e.g. only the weight of the mass to a complete one comprising weight, center of mass, principal axes and inertia.

3DVectorType and 3DVector are defined in OPC 10001-11 (SpatialTypes).

Table 48 – LoadType possible degrees of modelling

	Mass	CenterOfMass		Inertia
		X, Y, Z	A, B, C
Mass only	Used	-	-	-
Mass with center of gravity	Used	Used	0, 0, 0	-
Mass with inertia	Used	Used	Used	Used

The UserType ObjectType describes information of the registered user groups within the control system.

It is formally defined in Table 49.

Figure 24 – Overview UserType

Table 49 – UserType Definition

Attribute	Value
BrowseName	UserType
IsAbstract	False
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
Subtype of the BaseObjectType defined in OPC Unified Architecture
HasProperty	Variable	Level	String	PropertyType	Mandatory
HasProperty	Variable	Name	String	PropertyType	Optional

The Level property provides information about the access rights and determines what can be viewed, updated or deleted by a user. Depending on the user level different functionalities are available. The robot vendors might use different descriptions and access levels for the users and might require authentification.

The Name property provides the name for the current user within the control system.