6 OPC UA for RIO Information Model overview

6.1 Introduction to OPC UA for PROFINET Remote IO

The OPC UA for PROFINET Remote IO Information Model aims to offer Clients Objects and Services based on two RIO application profiles: Remote IO for Factory Automation (see [RIO FA]) and Remote IO for Process Automation (see [RIO PA]).

OPC UA for PROFINET Remote IO consists of all Objects and types provided by an OPC UA Server allowing OPC UA Clients to access the IO data of PN Submodules. The Information Model is divided into a PROFINET aspect offering detailed Telegram information and a functional aspect modelling Process Values as part of RIO Channel Objects. The two aspects offer different access paths for Clients and are connected by dedicated References to allow navigating to the preferred representation from either aspect.

6.2 OPC UA for RIO Channel Model

The “RIOChannel” Object in the functional aspect aggregates Process Value Objects optionally offering additional information like Process Value qualifiers associated with the IO data. Figure 8 shows the basic channel model for an analog RIO Input Channel according to RIOforPA.

The functional aspect with RIO of the Information Model contains as many RIO Channel objects as needed to represent the IO’s associated with the PN Submodules of the Device.

The “ProcessValue” Variable in Figure 8 contains an analog Process Value. The VariableType used to represent analog Process Values is RioPaAnalogProcessValueVariableType, the data type used by this VariableType is RioPaAnalogProcessValueDataType.

Configuration properties of the RIO Channel are provided with the “Config” Variable. There are individual configuration VariableTypes defined for each channel type, the type used for analog Input Channels according to RIOforPA is RioPaAnalogInputConfigVariableType.

Figure 9 shows all RIO Channel ObjectTypes, Process Value VariableTypes and configuration ObjectTypes which are defined in this specification to cover digital and analog Input and Output for RIOforPA and RIOforFA.

The RIO Channel ObjectTypes provide additional components, Variables and configuration Properties available for access by the Client which substantially differ between the various types, see sections 7.2 and 9.4 for details.

6.3 PROFINET Cyclic IO Telegram Model

Figure 10 shows the Cyclic IO Telegram model accessible from the PN Submodule in the PROFINET aspect of the Information Model. If provided by the Server, the Telegram Object associated with one PN Submodule aggregates the Input and the Output Telegram Objects. The individual data points or variables within a Telegram are represented by Signal Objects. The Input Telegram and Output Telegram Objects aggregate the Signal Objects and provide additional information like provider status and consumer status.

The Offset Property of the PnIoSignalType Object contains the position as byte offset of the signal from the start of the binary telegram.

The 0:RepresentsSameEntityAs Reference connects PnIoSignalType Objects with the “ProcessValue” Variables containing the Process Value provided by RIO Channel Objects in the functional aspect of the Information Model.

6.4 Connection of PROFINET Aspect and Functional Aspect

Figure 11 shows the Channel model for analog Input according to RIOforPA to illustrate the relationship between the different aspects. The Process Values and their qualifiers are transmitted consecutively and are available for the user program in the Input section of the Process Image.

The connection of the PROFINET aspect and the functional aspect with two analog RIO Input Channels according to RIOforPA in the Information Model is shown in Figure 12.

The PnIoSignalType Objects “01_AI_1_Value” and “03_AI_2_Value” representing the Process Values in the PnIoTelegramType Object “Input” connect to the “ProcessValue” Variables which are components of the Input Channels “AI_1” and “AI_2” using a 0:RepresentsSameEntityAs Reference.

The PnIoSignalType Objects “02_AI_1_Q” and “04_AI_2_Q” representing the Process Value Qualifiers transmitted alongside the Process Values they belong to connect to the “QualifierValue” Variables also using a 0:RepresentsSameEntityAs Reference.

The direct connection of Signal Objects representing status data and qualifier Variables using 0:RepresentsSameEntityAs References in the way shown in Figure 12 is only possible for analog Input and analog Output according to RIOforPA, since only analog RIOforPA transmits the status data (= qualifiers) alongside to each Process Value as separate Signal in the Telegram.

Digital RIOforPA Input and Output Channels transmit value and status packed into one byte (see [RIO PA] sec. 7.3.1.2 “Discrete Values”). Figure 13 shows the digital Output Channel model according to RIOforPA.

No separate qualifier Signal Objects and no 0:RepresentsSameEntityAs References to qualifier Variables exist for digital RIOforPA values, as shown in Figure 14.

6.5 OPC UA for RIO Channel Groups

The qualifiers in RIOforFA Channels are single bits transferred together in one or more bytes (see [RIO FA] sec. 7.2). Therefore, the Telegram contains an arbitrary number of qualifier bits distributed among several continuous bytes.

Figure 15 shows the analog Output Channel model and a Channel Group according to RIOforFA. The qualifiers of the Output Process Values are transferred as single bits packed into one byte in the Input section of the process image.

Figure 16 shows the References from Signal Objects in the PROFINET aspect to their counterparts in the RIO aspect for analog RIO Output Channels according to RIOforFA. The qualifier Signal Object is connected to a RioBitFieldVariableType Variable containing a bit field. The bit field and the RIO Channel Objects are related using RIO Channel Group Objects.

The Output Signal Objects “01_AO_1_Value” and “02_AO_2_Value” are connected to the Process Value Variables with 0:RepresentsSameEntityAs References in the same way as described before.

The qualifiers of RIO Output Channels according to RIOforFA are transmitted separated from the values in an Input Signal since qualifiers of RIOforFA Output Channels are provided by the Channel and are part of the Input section of the process image. Therefore, the qualifier Signal Object “03_AO_1-AO_2_Q” containing the status information for both Output Channels is a component of the Input Signal Variable and relates to the “OutputImageQualifiers” Variable in the functional aspect of the Information Model using a 0:RepresentsSameEntityAs Reference.

The “SM1” PROFINET submodule Object connects to the RioFaAnalogChannelGroupType Object using a 0:RepresentsSameFunctionalityAs Reference. Since the RIO Channel Group types allow aggregating of Input and Output but are separated into different types for digital and analog IO, hybrid digital/analog submodules may reference a digital Channel Group type object and an analog Channel Group type object with 0:RepresentsSameFunctionalityAs References.

For analog RIOforFA Input Channels, the RIO Channel Group modelling is done in the same way as shown in Figure 16, but all Signal Objects are components of the Input Signal Variable.

The mapping of the bit number inside the RioBitFieldVariableType Variable to the RIO Channel the status bit belongs to is done in the following way: The Value of the RioChannelNumber Property of each Channel Object corresponds to the bit number of the status bit inside the bit field.

The Server may optionally provide additional RioFaProcessValueQualifierVariableType Variables as components of the Process Value Variables to make the status information directly accessible for Clients without decoding the value structure of the Process Value Variable.

Digital RIO Channels according to RIOforFA transmit the Process Values as single bits packed together into one or more bytes. One Telegram contains an arbitrary number of value bits which belong to separate RIO Channels distributed among continuous bytes, as shown in Figure 17.

Figure 18 shows the modelling of a digital RIOforFA Input Channel Group. The RIO Channel Group Object aggregates the value and status information for 32 digital RIOforFA Input Channels. The RioBitFieldVariableType Variable “InputImage” is a bit field representing the digital values of 32 Process Values. The “InputImageQualifier” Variable of the same type contains the status bits.

The optional “InputChannel” Objects may contain single RioFaDigitalInputChannelType Objects providing detailed information for each aggregated RIO Channel. The “01_DI_1-DI_32_Value” Object is connected to a RioBitFieldVariableType Variable containing a bit field which represents the digital values for more than one RIO Channel. The qualifier Signal Object is also connected with a bit field Variable containing the status bits.

Figure 19 shows the modelling of a digital RIOforFA Output Channel Group. The “OutputImageQualifier” bit field Variable is connected to the qualifier Signal Object which is a component of the Input Telegram.

Figure 20 shows an analog RIO Channel Group aggregating two RioPaAnalogInputChannelType Objects. The “InputValues” Variable containing an array of RioPaAnalogValueDataType structures is connected to the “Input” Telegram Variable in the PROFINET aspect using a 0:RepresentsSameEntityAs Reference.

Figure 21 shows a digital RIO Channel Group aggregating two RioPaDigitalOutputChannelType Objects. The “OutputImage” Variable containing an array of RioPaDigitalValueDataType structures is connected with the “Output” Telegram Variable in the PROFINET aspect using a 0:RepresentsSameEntityAs Reference.

6.6 RIO Channel Groups Summary

For RIO Channel Group Objects the following rules apply to Servers.

RIOforFA:
RIO Channel Group Objects shall be provided always if the Cyclic IO Telegram model is provided by the Server. RIO Channel Groups could be used for lightweight modelling of digital multichannel I/O submodules when the RIO Channel Objects are omitted and only the I/O image Variables are used.

RIOforPA:
RIO Channel Group Objects could be used if logical grouping of channels shall be done for asset relations on the RIO aspect side if the PROFINET aspect is omitted.

General:
Servers may always provide RIO Channel Group Objects, independent from the conditions mentioned above.

6.7 OPC UA for RIO Security

Servers shall allow Method invocation and write access to Variables only for Sessions using dedicated user accounts. There shall exist user accounts with restricted rights (that is, no Method invocation and read-only access to Variables) for Clients performing data acquisition or diagnosis also.

If well-known Roles are supported by the Server, role-based security shall be applied. Method invocation as well as write access shall only be possible if the well-known “Operator” Role is granted to the Client’s Session.

6.8 Process Value Qualifier and StatusCode Relationship

When returning the Value of Process Values, the Server shall set the StatusCode member of the DataValue structures returned by the Read Service and the Publish Service consistent with the Process Value Qualifier information defined for Process Value Variables and structures.

6.8.1 Process Value Qualifier and StatusCode Relationship for RIOforPA

RIOforPA status information is conveyed to the Client as copy of the original status transmitted in the telegram signal. The value of the RioPaProcessValueQualifierVariableType Variable and the Qualifier member of the RioPaAnalogValueDataType and the RioPaDigitalValueDataType shall contain the original status. In addition to this, the status can be encoded into additional qualifier values encoded as RioQualityEnumeration, RioSpecifierEnumeration and RioQualifierEnumeration enumeration values.

6.8.1.1 Condensed Status restricted to NE 107

If the Device generates condensed status codes restricted to NE 107 (See [PCD] chapter 5.4.3.2), the status information delivered for one Process Value and the OPC UA StatusCode shall be set consistent as defined in Table 13.

The two values for status bytes consider the possible appearance of the update bit as defined in [PCD]. The update bit is not mapped further into separate status values. In contrast, the appearance of the “simulation active” bit is mapped to special values of the RioQualifierEnumeration.

6.8.1.2 Status with detailed Information

If the Server generates status codes with detailed information (See [PCD] chapter 5.4.3.3), the status information delivered for one Process Value and the OPC UA StatusCode shall be set consistent as defined in Table 14.

6.8.1.3 Classic Status

For Devices generating classic status codes, OPC UA Servers shall set the status information delivered for one Process Value and the OPC UA StatusCode consistent as defined in Table 15.

According to [PCD PB] chapter 5.3.4.2.1, the classic status codes shall be supported for legacy Devices requiring backward compatibility only. Otherwise, only condensed status generation or condensed status with detailed information as defined in 6.8.1.1 and 6.8.1.2 is required.

6.8.2 Process Value Qualifier and StatusCode Relationship for RIOforFA

RIOforFA status information is conveyed to the Client as copy of the original status transmitted in the telegram signal. The value of the RioFaProcessValueQualifierVariableType Variable and the Qualifier member of the RioFaAnalogValueDataType and the RioFaDigitalValueDataType shall contain the original status. In addition to this, the status can be encoded into additional qualifier values encoded as RioQualityEnumeration.

The status information delivered for one Process Value and the OPC UA StatusCode shall be set consistent as defined in Table 16.

6.8.3 StatusCode of Arrays of Process Values

When returning arrays of Process Values, the Server shall set the Severity of the StatusCode to “Bad” if one or more Process Values in the returned array are “Bad”. If no Process Value in the array is “Bad”, the Severity returned shall be “Uncertain” if one or more Process Values in the returned array are “Uncertain”. The Severity returned shall be “Good” only if all Process Values in the array are “Good”.