1 Scope

This document specifies an OPC UA Information Model for the representation of a complete motion device system as an interface for higher-level control and evaluation systems. A motion device system consists out of one or more motion devices, which can be any existing or future robot type (e.g. industrial robots, mobile robots), kinematics or manipulator as well as their control units and other peripheral components.

Additionally, this document shows in Annex C the use of the OPC 40001-1 - UA CS for Machinery Part 1 - Basic Building Blocks together with the Information Model described in this part.

2 Normative references

The following documents, in whole or in part, are normatively referenced in this document and are indispensable for its application. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

ISO 8373 Robots and robotic devices — Vocabulary

ISO 10218-1 Robots and robotic devices — Safety requirements for industrial robots — Part 1: Robots

OPC 10000-3, OPC Unified Architecture - Part 3: Address Space Model

OPC 10000-3

OPC 10000-4, OPC Unified Architecture - Part 4: Services

OPC 10000-4

OPC 10000-5, OPC Unified Architecture - Part 5: Information Model

OPC 10000-5

OPC 10000-100, OPC Unified Architecture - Part 100: Devices

OPC 10000-100

OPC 40001-1: OPC UA for Machinery - Basic Building Blocks

http://opcfoundation.org/UA/Machinery/

3 Terms, definitions, and conventions

For the purposes of this document, the following terms and definitions apply.

3.1 Overview

It is assumed that the reader of this document understands the basic concepts of OPC UA information modelling and the referenced documents. This specification will use these concepts to describe the Robotics Information Model.

Note that OPC UA terms and terms defined in this specification are written in italics in the specification.

3.2 Terms

Annex B contains examples of the described terms.

3.3 Abbreviations

3.4 Conventions used in this document

3.4.1 Conventions for Node descriptions

Node definitions are specified using tables (see Table 4).

Attributes are defined by providing the Attribute name and a value, or a description of the value.

References are defined by providing the ReferenceType name, the BrowseName of the TargetNode and its NodeClass.

If the TargetNode is a component of the Node being defined in the table, the Attributes of the composed Node are defined in the same row of the table.

The DataType is only specified for Variables; “[<number>]” indicates a single-dimensional array, for multi-dimensional arrays the expression is repeated for each dimension (e.g. [2][3] for a two-dimensional array). For all arrays, the ArrayDimensions is set as identified by <number> values. If no <number> is set, the corresponding dimension is set to 0, indicating an unknown size. If no number is provided at all the ArrayDimensions can be omitted. If no brackets are provided, it identifies a scalar DataType and the ValueRank is set to the corresponding value (see OPC 10000-3). In addition, ArrayDimensions is set to null or is omitted. If it can be Any or ScalarOrOneDimension, the value is put into “{<value>}”, so either “{Any}” or “{ScalarOrOneDimension}” and the ValueRank is set to the corresponding value (see OPC 10000-3) and the ArrayDimensions is set to null or is omitted. Examples are given Table 3.

The TypeDefinition is specified for Objects and Variables.

The TypeDefinition column specifies a symbolic name for a NodeId, i.e. the specified Node points with a HasTypeDefinition Reference to the corresponding Node.

The ModellingRule of the referenced component is provided by specifying the symbolic name of the rule in the ModellingRule column. In the AddressSpace, the Node shall use a HasModellingRule Reference to point to the corresponding ModellingRule Object.

If the NodeId of a DataType is provided, the symbolic name of the Node representing the DataType shall be used.

Nodes of all other NodeClasses cannot be defined in the same table; therefore, only the used ReferenceType, their NodeClass and their BrowseName are specified. A reference to another part of this document points to their definition.

Table 4 illustrates the table. If no components are provided, the DataType, TypeDefinition and ModellingRule columns may be omitted and only a Comment column is introduced to point to the Node definition.

Components of Nodes can be complex that is containing components by themselves. The TypeDefinition, NodeClass, DataType and ModellingRule can be derived from the type definitions, and the symbolic name can be created as defined in chapter 3.4.3.1. Therefore, those containing components are not explicitly specified; they are implicitly specified by the type definitions.

3.4.2 NodeIds and BrowseNames

3.4.2.1 NodeIds

The NodeIds of all Nodes described in this standard are only symbolic names. Annex A defines the actual NodeIds.

The symbolic name of each Node defined in this specification is its BrowseName, or, when it is part of another Node, the BrowseName of the other Node, a “.”, and the BrowseName of itself. In this case “part of” means that the whole has a HasProperty or HasComponent Reference to its part. Since all Nodes not being part of another Node have a unique name in this specification, the symbolic name is unique.

The namespace for all NodeIds defined in this specification is defined in Annex A. The namespace for this NamespaceIndex is Server-specific and depends on the position of the namespace URI in the server namespace table.

Note that this specification not only defines concrete Nodes, but also requires that some Nodes shall be generated, for example one for each Session running on the Server. The NodeIds of those Nodes are Server-specific, including the namespace. But the NamespaceIndex of those Nodes cannot be the NamespaceIndex used for the Nodes defined in this specification, because they are not defined by this specification but generated by the Server.

3.4.2.2 BrowseNames

The text part of the BrowseNames for all Nodes defined in this specification is specified in the tables defining the Nodes. The NamespaceIndex for all BrowseNames defined in this specification is defined in Annex A.

If the BrowseName is not defined by this specification, a namespace index prefix like ‘0:EngineeringUnits’ or ‘2:DeviceRevision’ is added to the BrowseName. This is typically necessary if a property of another specification is overwritten or used in the OPC UA types defined in this specification. Table 130 provides a list of namespaces and their indexes as used in this specification.

3.4.3 Common Attributes

3.4.3.1 General

The Attributes of Nodes, their DataTypes and descriptions are defined in OPC 10000-3. Attributes not marked as optional are mandatory and shall be provided by a Server. The following tables define if the Attribute value is defined by this specification or if it is server specific.

For all Nodes specified in this specification, the Attributes named in Figure 5 shall be set as specified in the table.

3.4.3.2 Objects

For all Objects specified in this specification, the Attributes named in Table 6 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

3.4.3.3 Variables

For all Variables specified in this specification, the Attributes named in Table 7 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

3.4.3.4 VariableTypes

For all VariableTypes specified in this specification, the Attributes named in Table 8 be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

3.4.3.5 Methods

For all Methods specified in this specification, the Attributes named in Table 9 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

3.4.3.6 Expanding conventions

For the following illustrations, the legend is as follows:

Additional definitions:

Table 10 describes the additional definitions.

3.4.3.7 Handling of not supported properties

In case of not supported Properties the following default shall be provided:

Properties with DataType String: empty string

Properties with DataType LocalizedText: empty text field

RevisionCounter Property: - 1

4 General information to OPC Robotics and OPC UA

4.1 Introduction to OPC Robotics

The OPC Robotics specification describes an information model, which aims to cover all current and future robotic systems such as:

Industrial robots

Mobile robots

Several control units

Peripheral devices, which do not have their own OPC UA server.

Part 1 provides information for asset management and condition monitoring. In future parts, the information model will be extended to cover more use cases.

The following functionalities are covered:

Provision of asset configuration and runtime data of a running motion device system and its components e.g. manipulators, axes, motors, controllers, and software

Following functions are not included and might be covered in future parts:

A messaging mechanism covered by events and alarms to provide conditions.

A state machine to inform about the status of task controls and to interact via methods.

The possibility for the operator to store customer specific information inside the motion device system e.g. location, cost centre, ERP data, ...

4.2 Introduction to OPC Unified Architecture

4.2.1 What is OPC UA?

OPC UA is an open and royalty free set of standards designed as a universal communication protocol. While there are numerous communication solutions available, OPC UA has key advantages:

A state of art security model (see OPC 10000-2).

A fault tolerant communication protocol.

An information modelling Framework that allows application developers to represent their data in a way that makes sense to them.

OPC UA has a broad scope which delivers for economies of scale for application developers. This means that a larger number of high-quality applications at a reasonable cost are available.

The OPC UA model is scalable from small devices to ERP systems. OPC UA Servers process information locally and then provide that data in a consistent format to any application requesting data - ERP, MES, PMS, Maintenance Systems, HMI, Smartphone, or a standard Browser, for example. For a more complete overview see OPC 10000-1.

4.2.2 Basics of OPC UA

As an open standard, OPC UA is based on standard internet technologies, like TCP/IP, HTTP, Web Sockets.

As an extensible standard, OPC UA provides a set of Services (see OPC 10000-4) and a basic information model Framework. This Framework provides an easy manner for creating and exposing vendor defined information in a standard way. More importantly all OPC UA Clients are expected to be able to discover and use vendor-defined information. This means OPC UA users can benefit from the economies of scale that come with generic visualization and historical applications. This specification is an example of an OPC UA Information Model designed to meet the needs of developers and users.

OPC UA Clients can be any consumer of data from another device on the network to browser based thin clients and ERP systems. The full scope of OPC UA applications is shown in Figure 3.

OPC UA provides a robust and reliable communication infrastructure having mechanisms for handling lost messages, failover, heartbeat, etc. With its binary encoded data, it offers a high-performing data exchange solution. Security is built into OPC UA as security requirements become increasingly important especially since environments are connected to the office network or the internet and attackers are starting to focus on automation systems.

4.2.3 Information modelling in OPC UA

4.2.3.1 Concepts

OPC UA provides a Framework that can be used to represent complex information as Objects in an AddressSpace which can be accessed with standard services. These Objects consist of Nodes connected by References. Different classes of Nodes convey different semantics. For example, a Variable Node represents a value that can be read or written. The Variable Node has an associated DataType that can define the actual value, such as a string, float, structure etc. It can also describe the Variable value as a variant. A Method Node represents a function that can be called. Every Node has a number of Attributes including a unique identifier called NodeId and non-localized name called BrowseName. An Object representing a ‘Reservation’ is shown in Figure 4.

Object and Variable Nodes represent instances and they always reference a TypeDefinition (ObjectType or VariableType) Node which describes their semantics and structure. Figure 5 illustrates the relationship between an instance and its TypeDefinition.

The type Nodes are templates that define all the children that can be present in an instance of the type. In the example in Figure 5 the PersonType ObjectType defines two children: First Name and Last Name. All instances of PersonType are expected to have the same children with the same BrowseNames. Within a type the BrowseNames uniquely identifies the children. This means Client applications can be designed to search for children based on the BrowseNames from the type instead of NodeIds. This eliminates the need for manual reconfiguration of systems if a Client uses types that multiple Servers implement.

OPC UA also supports the concept of sub-typing. This allows a modeller to take an existing type and extend it. There are rules regarding sub-typing defined in OPC 10000-3, but in general they allow the extension of a given type or the restriction of a DataType. For example, the modeller may decide that the existing ObjectType in some cases needs an additional Variable. The modeller can create a subtype of the ObjectType and add the Variable. A Client that is expecting the parent type can treat the new type as if it were of the parent type. Regarding DataTypes, subtypes can only restrict. If a Variable is defined to have a numeric value, a sub type could restrict it to a float.

References allow Nodes to be connected in ways that describe their relationships. All References have a ReferenceType that specifies the semantics of the relationship. References can be hierarchical or non-hierarchical. Hierarchical references are used to create the structure of Objects and Variables. Non-hierarchical are used to create arbitrary associations. Applications can define their own ReferenceType by creating subtypes of an existing ReferenceType. Subtypes inherit the semantics of the parent but may add additional restrictions. Figure 6 depicts several References, connecting different Objects.

The figures above use a notation that was developed for the OPC UA specification. The notation is summarized in Figure 7. UML representations can also be used; however, the OPC UA notation is less ambiguous because there is a direct mapping from the elements in the figures to Nodes in the AddressSpace of an OPC UA Server.

A complete description of the different types of Nodes and References can be found in OPC 10000-3 and the base structure is described in OPC 10000-5.

OPC UA specification defines a very wide range of functionality in its basic information model. It is not expected that all Clients or Servers support all functionality in the OPC UA specifications. OPC UA includes the concept of Profiles, which segment the functionality into testable certifiable units. This allows the definition of functional subsets (that are expected to be implemented) within a companion specification. The Profiles do not restrict functionality but generate requirements for a minimum set of functionality (see OPC 10000-7).

4.2.3.2 Namespaces

OPC UA allows information from many different sources to be combined into a single coherent AddressSpace. Namespaces are used to make this possible by eliminating naming and id conflicts between information from different sources. Namespaces in OPC UA have a globally unique string called a NamespaceUri and a locally unique integer called a NamespaceIndex. The NamespaceIndex is only unique within the context of a Session between an OPC UA Client and an OPC UA Server. The Services defined for OPC UA use the NamespaceIndex to specify the Namespace for qualified values.

There are two types of values in OPC UA that are qualified with Namespaces: NodeIds and QualifiedNames. NodeIds are globally unique identifiers for Nodes. This means the same Node with the same NodeId can appear in many Servers. This, in turn, means Clients can have built in knowledge of some Nodes. OPC UA Information Models define globally unique NodeIds for the TypeDefinitions defined by the Information Model.

QualifiedNames are non-localized names qualified with a Namespace. They are used for the BrowseNames of Nodes and allow the same names to be used by different information models without conflict. TypeDefinitions are not allowed to have children with duplicate BrowseNames; however, instances do not have that restriction.

4.2.3.3 Companion Specifications

An OPC UA companion specification for an industry specific vertical market describes an Information Model by defining ObjectTypes, VariableTypes, DataTypes and ReferenceTypes that represent the concepts used in the vertical market, and potentially also well-defined Objects as entry points into the AddressSpace.

5 Use Cases

Part 1 of this companion specification describes an interface that provides access to asset management and condition monitoring data of motion device systems. Based on the provided data the following use cases are supported:

Supervision: With the provided data by the companion specification the robot system can be supervised and monitored. Functional analysis of individual robot systems within the factory ground is possible. During production phase the companion specification provides data about the operational and safety states as well as process data.

Condition monitoring: Condition monitoring is the process of determining the condition of machinery while in operation, to identify a significant change which is indicative of a developing fault. This is a major component of Predictive Maintenance where the maintenance is scheduled to shorten the downtime. The typical parameters needed for condition monitoring like motor temperature, load, on time are provided by the companion specification for robotics.

Asset management: The companion specification for robotics provides detailed information of the main electrical and mechanical parts like part number, brand name, serial number etc. With these data an effective maintenance is possible because the technician knows in advance which parts need to be changed and can be prepared.

Remote operation: The companion specification provides state machines at the controller and the task control level to provide remote operation capability via OPC UA. This includes, upload, download, loading, unloading, starting, stopping of robot programs, handling conditions etc.

Figure 8 shows the communication structure with OPC UA.

6 OPC Robotics Information Model overview

The MotionDeviceSystemType as a subtype of the ComponentType (OPC UA for Devices) is used as the root object representing the motion device system with all its subcomponents, see Figure 10.

Figure 11 shows the main objects and the relations between them in an abstract view.

In Part 1 in general all variables and properties are read only unless stated otherwise in the description. A vendor can decide to provide variables or properties as writeable by client side as well.

7 OPC UA ObjectTypes

7.1 MotionDeviceSystemType ObjectType Definition

7.1.1 Overview

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. The MotionDeviceSystemType is formally defined in Table 11.

7.1.2 MotionDeviceSystemType definition

The components of the MotionDeviceSystemType have additional subcomponents which are defined in Table 12.

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.

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 10000-100.

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.

7.2 MotionDeviceType ObjectType Definition

7.2.1 Overview

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

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

7.2.2 MotionDeviceType definition

The components of the MotionDeviceType have additional subcomponents which are defined in Table 14.

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 10000-100.

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

The Model property provides the name of the product. This property is derived from ComponentType defined in OPC 10000-100.

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 10000-100.

The AssetId property is a user writable alphanumeric character sequence uniquely identifying a component. The vendor, integrator or user of the device provides the ID. 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. A 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 10000-100.

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 10000-100.

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 10000-100.

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

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

The Variable TaskControlReference provides a NodeId pointing to the instance of TaskControlOperationType defined in 7.15, which controls this motion device in combination with the loaded program.

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 (7.3).

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

AdditionalComponents is a container for one or more instances of any other ObjectType (any subtype of 0:BaseObjectType). 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. The intention of this folder is to integrate devices which are defined in companion specifications that use OPC 10000-100 ComponentType. From this specification, only instances of AuxiliaryComponentType and DriveType can be used in this container.

7.3 AxisType ObjectType Definition

7.3.1 Overview

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

7.3.2 AxisType definition

The components of the AxisType have additional subcomponents which are defined in Table 16.

The AssetId property is a user writable alphanumeric character sequence uniquely identifying a component. The vendor, integrator or user of the device provides the ID. 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 10000-100.

The MotionProfile property provides the kind of axis motion as defined by the AxisMotionProfileEnumeration (10.2)

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

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.

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.

7.4 PowerTrainType ObjectType Definition

7.4.1 Overview

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. The PowerTrainType represents instances of power trains of a motion device and is formally defined in

Table 17.

7.4.2 PowerTrainType definition

The ComponentName property provides a user writable 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 10000-100.

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

The IsConnectedTo ReferenceType defined in 8.6 is intended to provide the relationship between a motor and a gear of a power train.

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

The IsConnectedTo ReferenceType defined in 8.6 is intended to provide the relationship between a motor and a gear of a power train.

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 powertrains 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.

7.5 MotorType ObjectType Definition

7.5.1 Overview

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

7.5.2 MotorType definition

The components of the MotorType have additional subcomponents which are defined in Table 19.

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 10000-100.

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

The Model property provides the name of the product. This property is derived from ComponentType defined in OPC 10000-100.

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 10000-100.

The AssetId property is a user writable alphanumeric character sequence uniquely identifying a component. The vendor, integrator or user of the device provides the ID. 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.

A 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 10000-100.

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 multi-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.10 shows different possibilities of usage.

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.:

7.6 GearType Definition

7.6.1 Overview

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

7.6.2 GearType definition

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 10000-100.

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

The Model property provides the name of the product. This property is derived from ComponentType defined in OPC 10000-100.

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 10000-100.

The AssetId property is a user writable alphanumeric character sequence uniquely identifying a component. The vendor, integrator or user of the device provides the ID. 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. A 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 10000-100.

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

Pitch describes the distance covered in millimetres (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:

7.7 SafetyStateType ObjectType Definition

7.7.1 Overview

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 IEC 61508.

The SafetyStateType is formally defined in Table 21.

7.7.2 SafetyStateType definition

The ComponentName property provides a user writable 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 10000-100.

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.

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.

Description of ParameterSet of SafetyStateType:

The OperationalMode variable provides information about the current operational mode. Allowed values are described in OperationalModeEnumeration (10.4).

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.

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.

7.8 EmergencyStopFunctionType ObjectType Definition

7.8.1 Overview

According to ISO 10218-1:2011 Ch.5.5.2 Emergency stop, the robot shall have one or more emergency stop functions. This shall be done with the help of the EmergencyStopFunctionType is defined in Table 23.

7.8.2 EmergencyStopFunctionType definition

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 emergency stop function is active, e.g. that the emergency stop button is pressed, FALSE otherwise.

7.9 ProtectiveStopFunctionType ObjectType Definition

7.9.1 Overview

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. This type is formally defined in Table 24

7.9.2 ProtectiveStopFunctionType definition

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 always enabled, e.g. the protective stop function of the safety doors is 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 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.

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 if the enabling device is released or fully pressed.

7.10 OperationStateMachineType Definition

The OperationStateMachineType provides an abstract state machine for operation. The state machine can be used for entities whose states can be represented by Idle, Ready or Executing and which can be started and stopped.

At the system and task control levels, concrete state machine types are derived from the OperationStateMachineType. The states of these state machines can be further enhanced with Substate machines.

The overview of the state machine with all transitions is shown in Figure 19.

Figure 20 shows the OPC UA representation of the OperationStateMachineType, the transitions between the states have not been shown for the sake of simplicity. The OperationStateMachineType is formally defined in Table 65.

The states of the OperationStateMachineType are described in Table 28.

The component Variables of the OperationStateMachineType have additional Attributes defined in Table 30.

The Variable LastTransitionReason provides the reason for the LastTransition. The EnumValue and ValueAsText of this 0:MultiStateValueDiscreteType are described in Table 29. This specification does not define an explicit error state. The LastTransitionReason indicates if a state change was caused due to an error.

The component Variables of the OperationStateMachineType have additional Attributes defined in Table 30.

LastTransitionReason EnumValues 1 and 2 describe where an operation was initiated, which reasoned the last transition. External means that the operation was initiated by a control station, which is not part of the robot system, e.g a cell PLC. Direct means that the operation was initiated by a control station, which is part of the robot system, e.g. the teach pendant.

The Variable PossibleStopModes is an array of EnumValueType, which contains a list of supported stop modes (see Table 31).

The Variable ConfiguredDefaultStopMode is an integer, which contains the value of the configured stop mode for this system. This shall be one of the values in the PossibleStopModes array.

The Variable LastTransition, inherited from the FiniteStateMachineType, is defined as mandatory in the OperationStateMachineType.

The transitions of the OperationStateMachineType are described in Table 33.

The components of the OperationStateMachineType have additional references which are defined in Table 69.

The component Variables of the OperationStateMachine have additional Attributes defined in the table below.

7.10.1 Start Method

The signature of this Method is specified below.

Signature

	Start (
	[out]	0:Int32	Status
	);

The Start Method is called by a Client to start execution of the entity which is represented by the state machine.

The possible Method result codes are formally defined in Table 37.

The Start Method representation in the AddressSpace is formally defined in table below.

7.10.2 Stop Method

The signature of this Method is specified below.

Signature

	Stop (
	[in]	0:Int64 	StopMode
	[out]	0:Int32	Status
	);

The Stop Method is called by a Client to stop execution of the entity which is represented by the state machine.

The possible Method result codes are formally defined in Table 40.

The Stop Method representation in the AddressSpace is formally defined in the table below.

7.11 SystemOperationType ObjectType

7.11.1 Overview

The SystemOperationType is an AddIn Type to extend instances of ControllerType described in 7.18. The SystemOperationType provides a state machine to monitor and/or command the controller behaviour at the system level and is formally defined in Table 42.

Robot systems may have conditions that must be acknowledged before some operational commands can be executed.

The system has two possibilities to enable the Client to acknowledge conditions.

By exposing at least one instance of AcknowledgeableConditionType inside the Server’s AddressSpace located within the Conditions folder as defined in the ConformanceUnit RobAckCondInstance.

By handling such conditions using the OPC UA Eventing mechanisms as defined in the ConformanceUnit RobAckCondEventing.

7.11.2 SystemOperationType definition

The SystemOperationType is formally defined in Table 42.

The Object SystemOperationStateMachine provides a state machine to monitor or command the controller at the system level. The SystemOperationStateMachineType is inherited from the OperationStateMachineType.

The folder Conditions (part of the ConformanceUnit RobAckCondInstance) provides instances of AcknowledgeableConditionType for the acknowledgement of single conditions or instances of MultiAcknowledgeableConditionType (see 8.1) for the acknowledgement of multiple conditions.

The Property 0:DefaultInstanceBrowseName of the SystemOperationType has an additional Attribute defined in

Table 44.

7.12 SystemOperationStateMachineType

The SystemOperationStateMachineType represents the behaviour of a controller at the system level and can be used for monitoring and for external or direct operation. In robot systems, a distinction is typically made between external and direct operation, depending on the OperationalMode (see 7.7.2).

If the system takes a significant amount of time to transition from the Idle State to the Ready State, the Idle State can be extended by the sub state machine IdleSubstateMachine. Alternatively, a vendor/application specific Substate machine may also be used.

For certain stop modes, the transition from the Executing State to the Ready State can take a significant amount of time. In such cases, the Executing State can be extended by the sub state machine ExecutingSubstateMachine. Alternatively, an application or vendor specific Substate machine may also be used.

The Substate machines enable the client to get more information during the transition.

The SystemMonitor Server Facet supports monitoring of the activities performed by the operator or system internally. (e.g. monitor condition changes and base causes) The SystemOperation Server Facet extends on the SystemMonitor Server Facet and adds support to operate the system.

The overview of the SystemOperationStateMachine with the IdleSubstateMachine as Substate machine of Idle State and the ExecutingSubstateMachine as Substate machine of Executing State with all transitions is shown in Figure 8.

The transitions in this state machine can occur due to internal processes of the system or they may be triggered by a method call. In case the transition is triggered by a method call, the transition might not occur immediately (e.g. it will be delayed until internal conditions are met).

The SystemOperationStateMachineType is formally defined in Table 45.

The Idle State of SystemOperationStatemachineType has additional subcomponents which are defined in Table 46

To acknowledge the state changes in a system the Conditions within the Conditions folder of SystemOperationType must be taken under consideration. A client might need to acknowledge them so that the robot system can be activated. (e.g. operational mode change requires acknowledgement to start the system)

The components of the SystemOperationStateMachineType have additional references which are defined in the table below.

The component Variables of the SystemOperationStateMachineType have additional Attributes defined in the table below.

7.12.1 Start Method

The signature of this Method is specified below.

Signature

	Start (
	[out]	0:Int32	Status
	);

The Start Method is called by a Client to start execution of the system that is represented by the state machine. If the method is successfully called, the method should return with a Good or Uncertain result code.

The Start Method allows an authorized Client to command the system to the Executing State.

The possible Method result codes are formally defined in Table 52

The Start Method representation in the AddressSpace is formally defined in Table 53.

7.12.2 Stop Method

The signature of this Method is specified below.

Signature

	Stop (
	[in]	0:Int64 	StopMode
	[out]	0:Int32	Status
	);

The Stop Method allows an authorized Client to command the system to stop executing and leave the Executing state.

In conjunction with the usage of this method, the transient states can be expressed with Substate machines within the Executing state (e.g. the ExecutingSubstateMachine in 7.14)

The input argument StopMode must be either 0 or one of those listed in the PossibleStopModes Variable (see Table 31). If not, then a Bad_InvalidArgument Result Code is returned.

The possible Method result codes are formally defined in Table 55

The Stop Method representation in the AddressSpace is formally defined in Table 56

7.12.3 GetReady Method

The signature of this Method is specified below.

Signature

	GetReady (
	[out]	0:Int32	Status
	);

The GetReady Method allows an authorized Client to request the system to transition from the Idle state to the Ready state. Internally the system prepares to get started in the next step (e.g. switching on the intermediate circuit). If the internal preparations for this transition are successful, the system will transition from Idle to Ready. If the internal preparations are unsuccessful then the IdleToIdle transition occurs.

In conjunction with the usage of this method, the transient states can be expressed with Substate machines within the Idle state (e.g. the IdleSubstateMachine in 7.13)

The possible Method result codes are formally defined in Table 58

The Start Method representation in the AddressSpace is formally defined in Table 59.

7.12.4 StandDown Method

The signature of this Method is specified below.

Signature

	StandDown (
	[out]	0:Int32	Status
	);

The StandDown method allows an authorized Client to request the system to:

transition from the Ready state to the Idle state or

cancel an ongoing preparation of the system and causes the IdleToIdle transition.

In conjunction with the usage of this method, the transient states can be expressed with Substate machines within the Idle state (e.g. the IdleSubstateMachine in 7.13)

The possible Method result codes are formally defined in Table 61.

The StandDown Method representation in the AddressSpace is formally defined in Table 62.

7.13 IdleSubstateMachineType

The IdleSubstateMachineType, a Substate machine of the Idle State of the SystemOperationStateMachine, represents a mechanism to prepare a system in a way that it will reach Ready State of the SystemOperationStateMachine after preparation.

The overview of the IdleSubstateMachine with all transitions is shown in Figure 24.

Figure 24 – IdleSubstateMachine

7.13.1 Overview

Figure 25 – IdleSubstateMachineType Overview

The IdleSubstateMachineType is formally defined in Table 63.

The Variable LastTransitionReason provides the reason for the LastTransition. The EnumValue and ValueAsText of this 0:MultiStateValueDiscreteType are described in the table below.

Table 64 – IdleSubstateMachineType Attribute values for child nodes

The states of the IdleSubstateMachineType are described in Table 65.

Table 65 – IdleSubstateMachineType State Descriptions

The transitions are described in .

Table 66 – IdleSubstateMachineType Transition Descriptions