The Drive Information Model specifies Objects and Services representing Axis type Drive Objects. Although this specification uses concepts and definitions specified by the PROFIdrive profile (see [PI 3172 PDP]), the represented Drives do not necessarily comply to PROFIdrive. Instead, this specification aims to support all kinds of drives supporting a PROFINET communication interface. As a benefit for a PROFIdrive represented by the OPC UA information model out of this specification on an edge device, this specification defines the PROFIdrive parameter to be used to read out the variables and properties of the information model via acyclic PROFINET communication.
The comprehensive Information Model describes all aspects of a device or automation system, containing the asset partial model related to orderable components and the functional partial model related to the application function part of the system (see [OPC 30140 PN], chapter 6). The asset types to be used for the asset partial model are specified in [OPC 40400-1] (OPC UA for Powertrain, Part1: Asset Management). This specification document defines the functional model of a Drive axis, in a PROFIdrive device typically represented by a Drive Object. The possible connections (relations) enable the navigation between related Objects representing the same entity in different partial models are shown in [OPC 30140 PN], chapter 6; see D.1 also. For a Drive device it is also possible to add additional functional models like Energy Management [OPC PE] or analog and digital IO-Channels [OPC RIO] to the comprehensive Information Model, if this functionality is supported by the Drive device. For examples of the comprehensive Information Model see the appendix (see Figure 10).
OPC UA for PROFINET Drives defines all Objects and types provided by an OPC UA Server allowing OPC UA Clients to access data and services of Axis type Drive Objects by providing Axis Objects. As specified in [OPC 30142 RIO], the Information Model is divided into a PROFINET aspect and a functional aspect. The PROFINET aspect offers optional detailed Telegram information (See [OPC 30142 RIO]), the functional aspect provides an Information Model for Axis type Drive Objects. The optional Signal Objects (see [OPC 30142 RIO]) in the PROFINET aspect relate to components of the Axis Objects in the functional aspect by dedicated 0:RepresentsSameEntityAs References (see Figure 10).
Figure 10 – DriveAxisType Organization
The Axis Objects serve as the root containers for modelling of Axis type Drive Objects. The functional aspect of a Drive contains as many Axis Objects as needed to represent the Axis type Drive Objects of the PROFIdrive P-Device.
Figure 10 shows the organization of the Axis Object. The components of this DriveAxisType Object representing an Axis Object are part of the four different sub-aspects “Signals”, “Actual and Command Values”, “Diagnosis” and “Axis Properties”.
The concrete ObjectTypes representing Axis type Drive Objects like VelocityDriveAxisType (see section 7.2) and FrequencyDriveAxisType (see section 7.3) are derived from the abstract DriveAxisType base ObjectType (see section 7.1). The base type contains all Variables and Properties common for all Axis Objects.
Within the Axis Object, the mandatory “Actual and Command Values” sub-aspect is mainly consisting of Variables which contain the setpoint and measurement values of an axis like velocity and acceleration represented as physical values in floating point data types. These Variables are used to address the use case for axis monitoring on a control panel and the use case for data mining.
In the optional “Signals” sub-aspect, the “PNSignals” folder Object contains the Variables representing the Signal as transmitted in the PROFINET Telegram as Value. These “Signals” address the use case for supervision or debugging of the original Signal values transmitted between the Motion Controller and the Drive Axis. If such a Signal contains the same information as a Variable out of the “Monitoring” folder, the Variables of these two sub-aspects are connected using the 0:RepresentsSameEntityAs ReferenceType (see Figure 11). Note, that Variables which are connected by the 0:RepresentsSameEntityAs ReferenceType may have the same DataType and Value or may have different DataType and Value, e.g. the velocity actual value as monitoring Variable is represented in float and unit U/min, while as Signal Variable represented in INT32 and unit % and N4 normalized.
The “Diagnosis” sub-aspect yields diagnosis data by providing the DiagnosisAlarmType Events. The Logbook Object provides access to the DriveAxisType Object’s fault buffer.
The “Axis Properties” sub-aspect contains a collection of values which are of special interest for the functional identification and behaviour (configuration) of the Axis Object. These values are organized into several containers further structuring the sub-aspects.
Figure 11 shows a reduced Axis Object model with the relationships of the Signal Objects in the PROFINET aspect with the Variables providing concrete Values in the functional aspect. The figure shall give a basic understanding by demonstrating the model organization using Standard Signals transmitted with Standard Telegram 1 (see [PI 3172 PDP], chapter 6.3.4.3.2 and 6.3.4.4). As described, the transmitted Signals are given by the selection of one of the Standard Telegrams or by the setup of the free telegram configuration.
Figure 11 – PROFINET Signals and Axis Object Variables
The “VelocityActualValue” and “VelocityCommandValue” 0:AnalogUnitType Variables in the “Actual and Command Values” sub-aspect contain the numeric representation of the “NIST_A” and “NSOLL_A” Standard Signals allowing Clients easy access to the numeric values of the represented Signals. The AxisState Variable contains the current state of the axis state machine, as it is encoded by related bits in value of the “ZSW1” Standard Signal. The AxisState Variable is encoded as 0:MultistateDiscreteType allowing Clients to obtain the state of the Axis/DO as numeric value as well as in string form. These Variables are linked to their Signal Variable counterpart in the “Signals” sub-aspect using 0:RepresentsSameEntityAs References (see Figure 11).
The “01_ZSW1”, “02_NIST_A”, “01_STW1” and “02_NSOLL_A” Signal Objects in the PROFINET aspect represent Standard Signals provided by the Axis Object. These Standard Signals are also linked to their counterpart Variables in the functional aspect of the Information Model using 0:RepresentsSameEntityAs References (see Figure 11).
The “ZSW1”, “NIST_A”, “STW1” and “NSOLL_A” Variables in the “Signals” sub-aspect provide the raw Signal Values encoded as unsigned integer data types.