1 Scope

This document specifies the OPC UA Information Model to represent the Objects and services that comprise Remote IO as defined in chapter 6. The Remote IO Information Model is based on Remote IO for FA [RIO FA] and Remote IO for PA [RIO PA].

OPC Foundation

OPC is the interoperability standard for the secure and reliable exchange of data and information in the industrial automation space and in other industries. It is platform independent and ensures the seamless flow of information among devices from multiple vendors. The OPC Foundation is responsible for the development and maintenance of this standard.

OPC UA is a platform independent service-oriented architecture that integrates all the functionality of the individual OPC Classic specifications into one extensible framework. This multi-layered approach accomplishes the original design specification goals of:

Platform independence: from an embedded microcontroller to cloud-based infrastructure

Secure: encryption, authentication, authorization and auditing

Extensible: ability to add new features including transports without affecting existing applications

Comprehensive information modelling capabilities: for defining any model from simple to complex

PROFINET Standardization Group (PNO)

The PROFIBUS and PROFINET user organization (PNO: Profibus Nutzerorganisation e. V.) was founded in 1989 and is the largest automation community in the world and responsible for PROFIBUS and PROFINET, the two most important enabling technologies in automation today. The PNO is member of PROFIBUS and PROFINET International (PI).

The common interest of the PNO global network of vendors, developers, system integrators and end users covering all industries lies in promoting, supporting and using PROFINET. Regionally and globally about 1,400 member companies are working closely together to the best automation possible. No other fieldbus organization in the world has the same kind of global influence and reach.

2 Normative references

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

OPC 10000-1, OPC Unified Architecture - Part 1: Overview and Concepts

OPC 10000-1

OPC 10000-2, OPC Unified Architecture - Part 2: Security Model

OPC 10000-2

OPC 10000-3, OPC Unified Architecture V1.05 - 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 V1.05 - Part 5: Information Model

OPC 10000-5

OPC 10000-6, OPC Unified Architecture V1.05 - Part 6: Mappings

OPC 10000-6

OPC 10000-7, OPC Unified Architecture - Part 7: Profiles

OPC 10000-7

OPC 10000-9, OPC Unified Architecture V1.05 - Part 9: Alarms and Conditions

OPC 10000-9

OPC 10000-23, OP Unified Architecture V1.05 - Part 23: Common Reference Types

OPC 10000-23

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

OPC 10000-100

RIO FA, Remote IO for Factory Automation – Version 1.10 – Date: August 2018 –

Order No.:3.242

RIO PA, Remote IO for Process Automation – Version 1.00 – Date: March 2022 –

Order No.:3.232

PCD PB, Profile for Process Control Devices – Version 3.02 – Date: April 2009 –

Order No.:3.042

PCD, Profile for Process Control Devices – Version 4.01 – Date: November 2020 –

Order No.:3.042

OPC PN, OPC UA for PROFINET – Release V1.0 – Date: January 2020 –

Order No.: 30140

PN Service IEC 61158-5-10, Industrial communication networks – Fieldbus specifications –

Part 5-10: Application layer service definition – Type 10 elements

3 Terms, abbreviated terms and conventions

3.1 Overview

It is assumed that basic concepts of OPC UA information modelling, Remote IO for Factory Automation [RIO FA] and Remote IO for Process Automation [RIO PA] are understood in this document. This document will use these concepts to describe the Remote IO Information Model. For the purposes of this document, the terms and definitions given in OPC 10000-1, OPC 10000-3, OPC 10000-4, OPC 10000-5, OPC 10000-7, OPC 10000-100, … as well as the following apply.

Note that OPC UA terms and terms defined in this document are italicized in the document.

3.2 OPC UA for PROFINET Remote IO terms

3.2.1 Untitled

A Controller is a host running a program which reads and writes the Process Values used to control an automated process. The control is usually done in cycles consisting of reading the Input Process Value, processing the Input, calculating the Output, and finally writing the Output Process Value.

3.2.2 Untitled

A Device is a stand-alone unit exchanging cyclic data with a Controller. Devices are usually configured by the Controller and may also generate acyclic data like alarms or diagnostic information. A Device may consist of several modules and Submodules.

3.2.3 Untitled

Remote IO is defined in this specification as accessing the Input Telegram data and the Output Telegram data of a PN Submodule from a remote host without interfering or interacting with cyclic data transfer.

3.2.4 Untitled

A RIO Channel comprises all Function Blocks, Functions and Variables used for processing of an analog or digital electric signal.

3.2.5 Untitled

A RIO Input Channel comprises all Function Blocks, Functions and Variables used for processing of an analog or digital electric input signal. Typically, the RIO Input Channel generates an Input Process Value from an electric signal.

3.2.6 A RIO Output Channel comprises all Function Blocks, Functions and Variables used for processing of an analog or digital electric output signal. Typically, a RIO Output Channel is used to transfer an Output Process Value to an electric signal. In addition, RIO Output Channels may process a Readback Value.

3.2.7 A RIO Channel Group is an aggregation of RIO Channels.

3.2.8 Untitled

Input is the data transferred from a monitored electrical sensor signal to the Controller.

3.2.9 Untitled

Output is the data transferred from the Controller to a remote-controlled actuator signal.

3.2.10 Untitled

A Transducer comprises all Functions used for the conversion of an electric signal into a digital representation and vice versa.

3.2.11 Untitled

An Input Transducer comprises all Functions used for the conversion of an electric signal into a digital representation.

3.2.12 Untitled

An Output Transducer comprises all Functions used for the conversion of a digital signal representation into an electric signal. As an option, an Output Transducer in addition can also convert the electric output signal back into a digital Readback Value representation.

3.2.13 Untitled

The Readback Value is the result of feeding the electric signal back into the RIO Output Channel within an Output Transducer.

3.2.14 Untitled

A Physical Value is the digital representation of the electrical signal or the physical value measured/controlled by the attached sensor/actor.

3.2.15 Untitled

3.2.16 Untitled

A Function Block comprises all Functions used for the conversion of the Physical Value into the Process Value and vice versa.

3.2.17 Untitled

The Process Value are all data variables which are intended to be part of cyclic data transfer with a Controller.

3.2.18 Untitled

3.2.19 Untitled

An Input Process Value contains the Input data used by a Controller.

3.2.20 Untitled

An Output Process Value contains a Controller’s Output data to an automated process.

3.2.21 Untitled

A Telegram represents the cyclic data of one PN Submodule. A Telegram consists at least of one Input Telegram or of one Output Telegram or of both.

3.2.22 Untitled

An Input Telegram represents the cyclic Input data of one PN Submodule. An Input Telegram consists of Signals.

3.2.23 Untitled

An Output Telegram represents the cyclic Output data of one PN Submodule. An Output Telegram consists of Signals.

3.2.24 Untitled

Signals are components of a Telegram. A Signal maps to a Variable in the Application Information Model.

3.2.25 Untitled

A PN Submodule is the consumer or the provider of one Telegram and the addressable endpoint for PROFINET access.

3.3 Abbreviated terms

3.4 Conventions used in this document

3.4.1 Conventions for Node descriptions

3.4.1.1 Node definitions

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

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 in Table 1.

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

Note that if a symbolic name of a different namespace is used, it is prefixed by the NamespaceIndex (see 3.4.2.2).

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 2 illustrates the table. If no components are provided, the DataType, TypeDefinition and Other 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 and DataType can be derived from the type definitions, and the symbolic name can be created as defined in 3.4.3.1. Therefore, those containing components are not explicitly specified; they are implicitly specified by the type definitions.

The Other column defines additional characteristics of the Node. Examples of characteristics that can appear in this column are show in Table 3.

If multiple characteristics are defined they are separated by commas. The name or the short name may be used.

3.4.1.2 Additional References

To provide information about additional References, the format as shown in Table 4 is used.

References can be to any other Node.

3.4.1.3 Additional sub-components

To provide information about sub-components, the format as shown in Table 5 is used.

3.4.1.4 Additional Attribute values

The type definition table provides columns to specify the values for required Node Attributes for InstanceDeclarations. To provide information about additional Attributes, the format as shown in Table 6 is used.

There can be multiple columns to define more than one Attribute.

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 document 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 document, the symbolic name is unique.

The NamespaceUri for all NodeIds defined in this document is defined in Annex A. The NamespaceIndex for this NamespaceUri is vendor-specific and depends on the position of the NamespaceUri in the server namespace table.

Note that this document 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 document, because they are not defined by this document but generated by the Server.

3.4.2.2 BrowseNames

The text part of the BrowseNames for all Nodes defined in this document is specified in the tables defining the Nodes. The NamespaceUri for all BrowseNames defined in this document is defined in 13.2.

For InstanceDeclarations of NodeClass Object and Variable that are placeholders (OptionalPlaceholder and MandatoryPlaceholder ModellingRule), the BrowseName and the DisplayName are enclosed in angle brackets (<>) as recommended in OPC 10000-3.If the BrowseName is not defined by this document, a namespace index prefix is added to the BrowseName (e.g., prefix '0' leading to ‘0:EngineeringUnits’ or prefix '2' leading to ‘2:DeviceRevision’). This is typically necessary if a Property of another specification is overwritten or used in the OPC UA types defined in this document. Table 145 provides a list of namespaces and their indexes as used in this document.

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 document or if it is server-specific.

For all Nodes specified in this document, the Attributes named in Table 7 shall be set as specified in the table.

3.4.3.2 Objects

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

3.4.3.3 Variables

For all Variables specified in this document, 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.4 VariableTypes

For all VariableTypes specified in this document, the Attributes named in Table 10 shall 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 document, the Attributes named in Table 11 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

4 General information to PROFINET Remote IO and OPC UA

PROFINET Remote IO (RIO) as referred to in this document consists of the objects and services allowing clients to access the IO data of PROFINET submodules.

4.1 What is RIO for Factory Automation?

RIO for Factory Automation (RIOforFA) is a Common Profile Specification for PROFINET and PROFIBUS which defines the qualifier, behaviour, and representation of IO data for Remote IO (see [RIO FA]). RIOforFA defines the minimal and typical requirements for Remote IO.

RIOforFA has the following properties (excerpt, See [RIO FA], sec. 1.2):

Defines qualifiers for values of physical signals, to be able to communicate and use data access (Process Image) in the host in a standardized way.

Defines a RIOforFA channel for digital IO and for analog IO. One RIOforFA channel consists of value and qualifier. The qualifier shall be synchronous and consistent with the value.

A RIOforFA submodule uses RIOforFA channels only.

The profile does not add any definition to standard PROFINET diagnosis and I&M functions.

Figure 1 shows an example of an Input submodule according to RIOforFA. The RIOforFA channel provides the value and its qualifier, which both are available in the process image of the user program (see [RIO FA], sec. 1.3).

4.2 What is RIO for Process Automation

RIO for Process Automation (RIOforPA) is a Common Application Profile for PROFINET and PROFIBUS defined in [RIO PA].

RIOforPA defines the following application classes (see [RIO PA], sec. 5.1):

“… The application class RIOforPA Digital Input defines functions for mapping of digital input signals from the process to input data transferred to the IO controller. The application class RIOforPA Analog Input defines functions for mapping of analog input signals from the process to input data transferred to the IO controller.

The application class RIOforPA Digital Output defines functions for mapping of output data transferred from the IO controller to digital output signals to the process. The application class RIOforPA Analog Output defines functions for mapping of output data transferred from the IO controller to analog output signals to the process.

Additional functions like fieldbus integration or HART mappings etc. are not in the scope of the profile.

Instances of the application classes will be realised as channels. A channel may have a connection to a sensor or actuator (physical channel) or not (logical channel). …” (see also [RIO PA] sec. 5.1).

4.3 Introduction to OPC Unified Architecture

4.3.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. When combined with semantic models such as OPC UA for PROFINET Remote IO, OPC UA makes it easier for end users to access data via generic commercial applications.

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 examples. For a more complete overview see OPC 10000-1.

4.3.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 historian 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 more and more important especially since environments are connected to the office network or the internet and attackers are starting to focus on automation systems.

4.3.3 Information modelling in OPC UA

4.3.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 a NodeId and non-localized name called as 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 of 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 identify 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 was 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 required 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.3.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. Each namespace in OPC UA has a globally unique string called a NamespaceUri which identifies a naming authority and a locally unique integer called a NamespaceIndex, which is an index into the Server's table of NamespaceUris. The NamespaceIndex is unique only within the context of a Session between an OPC UA Client and an OPC UA Server- the NamespaceIndex can change between Sessions and still identify the same item even though the NamespaceUri's location in the table has changed. The Services defined for OPC UA use the NamespaceIndex to specify the Namespace for qualified values.

There are two types of structured values in OPC UA that are qualified with NamespaceIndexes: NodeIds and QualifiedNames. NodeIds are locally unique (and sometimes globally unique) identifiers for Nodes. The same globally unique NodeId can be used as the identifier in a node in many Servers – the node's instance data may vary but its semantic meaning is the same regardless of the Server it appears in. This means Clients can have built-in knowledge of what the data means in these Nodes. OPC UA Information Models generally 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.3.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

Table 12 lists possible use cases of interest for OPC UA Clients. Typically, the use case consists of utilization of OPC UA standard mechanisms and data processing at the Client site.

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

7 OPC UA for RIO ObjectTypes

7.1 OPC UA for RIO Channel Group Types

The RIO Channel Group ObjectTypes are listed in Table 17. There are Channel Group types defined for digital and analog IO for RIOforFA and RIOforPA. There is no distinction regarding Input and Output, the Channel Group Objects aggregate Input and Output Channel Objects. All Channel Group types are derived from the RioChannelGroupType defined in chapter 7.1.1.

7.1.1 RioChannelGroupType

The RioChannelGroupType allows the aggregation of RIO Channels for diagnostic purposes and for asset relations. The RioChannelGroupType contains References to RioChannelType Objects. In addition, the server might provide configuration information common to all aggregated channels.

The NumberOfChannels array Variable contains the number of channels of each supported type represented by the RIO Channel Group. The following table contains the relationship of array index and the channel number information stored at the respective index:

The ApplicationTag Variable contains application specific data which can be used by Clients to obtain additional semantic information. Clients can modify the content of this Variable by invoking the SetApplicationTag Method.

If no subordinated RIO Channel Objects are provided, the Channel Group level ApplicationTag Variable is the only possibility to store Client specific semantic information. Servers can support tagging on RIO Channel level by providing Channel Objects.

The <RioInputChannel> Reference links one aggregated Input Channel Object. For each aggregated Input Channel Object, one HasRioInputChannel Reference shall be part of the RioChannelGroupType Object.

The <RioOutputChannel> Reference links one aggregated Output Channel Object. For each aggregated Output Channel Object, one HasRioOutputChannel Reference shall be part of the RioChannelGroupType Object.

If provided, the ChannelGroupConfig Object contains an arbitrary subset of read-only configuration properties of the represented RIO Channel Objects.

The Server might provide diagnosis data by sending RioChannelDiagnosisEventType Events and / or RioChannelDiagnosisAlarmType Events. The diagnosis data of the RioChannelGroup Object includes the diagnosis information of all aggregated RIO Channel Objects.

The used cross-aspect ReferenceTypes 0:RepresentsSameFunctionalityAs and 0:RepresentsSameEntityAs (see below) can only exist if the Server provides the PROFINET aspect of the Information Model.

If the PROFINET aspect is provided by the Server, the RIO Channel Group Object shall be linked to the associated PN Submodule using a 0:RepresentsSameFunctionalityAs Reference. The associated submodule addresses the same IO data as the Channel Group Object provides.

The Lock Object ensures exclusive write access and Method call for one Client. The Client locks the Channel Group Object by invoking the InitLock Method of the Lock Object. The Client invokes ExitLock to release the lock.

Before invoking a Method of the Channel Group Object, Clients must gain exclusive write access (“lock” the Channel Group Object) using the Lock Object.

7.1.1.1 SetApplicationTag Method

This Method sets the Value of the ApplicationTag Variable. The security constraints defined in chapter 6.7 apply.

Signature

	SetApplicationTag (
		[in] 0:String	 ApplicationTag
		);
	

The Method Result Codes (defined in Call Service) are defined in Table 19.

If the SetApplicationTag Method is invoked or if configuration data provided by the subordinated RioChannelGroupConfigType Object is changed, the value of the LastParameterChange timestamp Variable shall be changed by the Server.

7.1.2 RioChannelGroupConfigType

The RioChannelGroupConfigType contains all configuration properties which are common to all RIO Channel configuration types. A Server may support an arbitrary subset of these properties. Each supported property applies to all represented channels of the RIO Channel Group.

The Server may provide only one of the PaDigitalSubstituteValue, FaDigitalSubstituteValue bit fields, as well as the PaAnalogSubstituteValue and FaAnalogSubstituteValue arrays. But these variables shall be provided only if individual RIO Channel Objects are not provided.

The SignalType Property contains the signal type encoded as RioSignalTypeEnumeration.

The InversionEnabled Property contains True if the digital signal is inverted in the Function Block, otherwise False.

The ShortCircuitCheckEnabled Property contains True if short circuit check is active for the channel, otherwise False.

The WireCheckEnabled Property contains True if wire check is active for the channel, otherwise False.

The SupplyVoltageCheckEnabled Property contains True if supply voltage check is active for the channel, otherwise False.

The LoadVoltageCheckEnabled Property contains True if load voltage check is active for the channel, otherwise False.

The SubstitutePolicy Property contains the substitute value setting of the channel encoded as RioSubstitutePolicyEnumeration.

The PaDigitalSubstituteValue bit field Property contains the substitute values for the Process Value of the represented digital RIOforPA channels which shall be used if a failure is detected. The usage of the substitute value depends on the actual value of the SubstitutePolicy Property.

The FaDigitalSubstituteValue bit field Property contains the substitute values for the Process Value of the represented digital RIOforFA channels which shall be used if a failure is detected. The usage of the substitute value depends on the actual value of the SubstitutePolicy Property.

If the number of RIOforFA Channels the RIO Channel Group represents exceeds the capacity of the RioBitFieldVariableType (which is 32), as many RioBitFieldVariableType Variables shall be part of the RIO Channel Group Object as are needed to represent the substitute values of all RIOforFA Channels. The BrowseNames of the RioBitFieldVariableType Variable shall be extended with a suffix ensuring uniqueness and indicating the section of the bitfield the variable represents in this case, e.g. “FaDigitalSubstituteValue_0_31”, “FaDigitalSubstituteValue _32_47”, and so on.

The optional Offset Property of the RioBitFieldVariableType Variables shall be provided in this case and contain the start of the range the RioBitFieldVariableType Variable represents. Possible Values for Offset are 0, 32, 64, and so on. The Offset Value added to the bit number shall be used as the RioChannelNumber Property Value of the corresponding RIO Channel Objects if these Objects are provided.

The PaAnalogSubstituteValue array Property contains the substitute values for the Process Value of the represented analog RIOforPA channels which shall be used if a failure is detected. The usage of the substitute value depends on the actual value of the SubstitutePolicy Property.

The FaAnalogSubstituteValue array Property contains the substitute values for the Process Value of the represented analog RIOforFA channels which shall be used if a failure is detected. The usage of the substitute value depends on the actual value of the SubstitutePolicy Property.

The bit numbers and array indexes in the range 0 to <number of Input Channels minus 1> constitute the RioChannelNumbers of the represented Input Channels. The bit numbers and array indexes in the range <number of Input Channels> to <number of Input Channels + number of Output Channels minus 1> constitute the RioChannelNumbers of the represented Output Channels.

The SubstituteTime Property contains the time in seconds from the detection of a failure to a reaction (substitute value is set for the Process Value).

The Damping Property contains the damping time (T63) in seconds applied to an analog signal in the Function Block.

The HighLimit Property contains the upper limit of an analog signal.

The LowLimit Property contains the lower limit of an analog signal.

7.1.3 RioPaAnalogChannelGroupType

The RioPaAnalogChannelGroupType aggregates RioPaAnalogInputChannelType Objects and RioPaAnalogOutputChannelType Objects.

The InputValues array Variable contains the Input Process Values of the Input Channels the RIO Channel Group Object represents. The InputValues Variable is linked to the associated PnIoTelegramType Object using a 0:RepresentsSameEntityAs Reference (see Figure 20).

The array indexes must be equal to the RioChannelNumber of the represented Input Channels. The RioChannelNumbers of the Input Channels shall have the value range 0 to <size of InputValues array> minus 1.

The OutputValues array Variable contains the Output Process Values of the Output Channels the RIO Channel Group Object represents. The OutputValues Variable is linked to the associated PnIoTelegramType Object using a 0:RepresentsSameEntityAs Reference.

The array indexes must be equal to the RioChannelNumber of the represented Output Channels minus <size of the InputValues array>. The RioChannelNumbers of the Output Channels shall have the value range <size of InputValues array> to <size of InputValues array + size of OutputValues array> minus 1.

The type of each array element is RioPaAnalogValueDataType which has two members: Value contains the Process Value and QualifierValue contains the status information associated with each value.

The SimulationValues array of RioPaAnalogValueDataType structures contains the values and qualifiers used as Process Value for each represented analog channel if simulation is active for the channel.

The SimulationEnabled array Variable contains True for each array element if simulation is enabled for the corresponding RIO Channel, otherwise False.

The array indexes of the SimulationValues and the SimulationEnabled arrays must be equal to the RioChannelNumber of the referenced RIO Channels.

7.1.3.1 SetSimulation Method

This Method sets the Value of array elements of the SimulationEnabled array Variable. The security constraints defined in chapter 6.7 apply.

Signature

	SetSimulation (
		[in] 0:Boolean SimulationEnabled
		[in] 0:Int16 Index
		);
	

The Method Result Codes (defined in Call Service) are defined in Table 22.

7.1.3.2 SetSimulationValue Method

This Method sets the Value of array elements of the SimulationValue array Variable. The security constraints defined in chapter 6.7 apply.

Signature

	SetSimulationValue (
		[in] RioAnalogDataType	Value
		[in] 0:Byte Qualifier
		[in] 0:Int16 Index
		);
	

The Method Result Codes (defined in Call Service) are defined in Table 23.

7.1.4 RioFaAnalogChannelGroupType

The RioFaAnalogChannelGroupType aggregates RioFaAnalogInputChannelType Objects and RioFaAnalogOutputChannelType Objects.

The InputImageValues array Variable contains the Input Process Values of the Input Channels the RIO Channel Group Object represents. The InputImageValues Variable is linked to the associated PnIoTelegramType Input Object using a 0:RepresentsSameEntityAs Reference.

The InputImageQualifiers RioBitFieldVariableType Variable contains a bit field representing the qualifier bits associated with each Input Process Value the RIO Channel Group Object represents. The InputImageQualifiers Variable is linked to the associated PnIoSignalType Input Object using a 0:RepresentsSameEntityAs Reference.

The OutputImageValues array Variable contains the Output Process Values of the Output Channels the RIO Channel Group Object represents. The OutputImageValues Variable is linked to the associated PnIoTelegramType Output Object using a 0:RepresentsSameEntityAs Reference.

The OutputImageQualifiers RioBitFieldVariableType Variable contains a bit field representing the qualifier bits associated with each Output Process Value the RIO Channel Group Object represents. The OutputImageQualifiers Variable is linked to the associated PnIoSignalType Input Object using a 0:RepresentsSameEntityAs Reference.

The array index is used as the unambiguous assignment of qualifier bit and value. The array indexes and the bit numbers of the InputImageValues array and the InputImageQualifiers bit field must be equal to the RioChannelNumber Property Values of the corresponding RIO Channel Objects. The OutputImageValues array indexes and OutputImageQualifiers bit numbers must be mapped to the value range of the RioChannelNumbers of the referenced Output Channels by adding the size of the InputImageValues array.

The RioChannelNumbers of the Input Channels shall have the value range 0 to <size of InputImageValues array> minus 1. The RioChannelNumbers of the Output Channels shall have the value range <size of InputImageValues array> to <size of InputImageValues array + size of OutputImageValues array> minus 1.

If the number of RIO Channels the RIO Channel Group represents exceeds the capacity of the RioBitFieldVariableType (which is 32), as many RioBitFieldVariableType Variables shall be part of the RIO Channel Group Object as are needed to represent the qualifiers of all RIO Channels.

The BrowseNames of the RioBitFieldVariableType Variables shall be extended with a suffix ensuring uniqueness and indicating the section of the bitfield the variable represents in this case, e.g. “_0_31”, “_32_47”, and so on.

The optional Offset Property of the RioBitFieldVariableType shall be provided in this case and contain the start of the range the RioBitFieldVariableType Variable represents. Possible Values for Offset are 0, 32, 64, and so on. The Offset Value added to the bit number is equal to the array index of the corresponding Process Value. For bit fields representing Output Channels the array index must be mapped to the value range of the RioChannelNumbers of the referenced Output Channels by adding the number of Input Channels (see above).

7.1.5 RioPaDigitalChannelGroupType

The RioPaDigitalChannelGroupType aggregates RioPaDigitalInputChannelType Objects and RioPaDigitalOutputChannelType Objects.

The InputImage array Variable contains the Input Process Values of the Input Channels the RIO Channel Group Object represents. The InputImage Variable is linked to the associated PnIoTelegramType Input Object using a 0:RepresentsSameEntityAs Reference.

The array indexes must be equal to the RioChannelNumbers of the represented Input Channels. The RioChannelNumbers of the Input Channels shall have the value range 0 to <size of InputImage array> minus 1.

The OutputImage array Variable contains the Output Process Values of the Output Channels the RIO Channel Group Object represents. The OutputImage Variable is linked to the associated PnIoTelegramType Output Object using a 0:RepresentsSameEntityAs Reference (See Figure 21).

The array indexes must be equal to the RioChannelNumbers of the represented Output Channels minus <size of the InputImage array>. The RioChannelNumbers of the Output Channels shall have the value range <size of InputImage array> to <size of InputImage array + size of OutputImage array> minus 1.

The type of each array element is RioPaDigitalValueDataType which has two members: Value contains the Process Value and QualifierValue contains the status information associated with each value.

The SimulationValues array of RioPaDigitalValueDataType structures contains the values and qualifiers used as Process Value for each represented digital channel if simulation is active for the channel.

The SimulationEnabled array Variable contains True for each array element if simulation is enabled for the corresponding RIO Channel, otherwise False.

The array indexes of the SimulationValues and the SimulationEnabled arrays must be equal to the RioChannelNumber of the referenced RIO Channels.

7.1.5.1 SetSimulation Method

This Method sets the Value of array elements of the SimulationEnabled array Variable. The security constraints defined in chapter 6.7 apply.

Signature

	SetSimulation (
		[in] 0:Boolean SimulationEnabled
		[in] 0:Int16 Index
		);
	

The Method Result Codes (defined in Call Service) are defined in Table 26.

7.1.5.2 SetSimulationValue Method

This Method sets the Value of array elements of the SimulationValue Variable. The security constraints defined in chapter 6.7 apply.

Signature

	SetSimulationValue (
		[in] 0:Boolean Value
		[in] 0:Byte Qualifier
		[in] 0:Int16 Index
		);
	

The Method Result Codes (defined in Call Service) are defined in Table 27.

7.1.6 RioFaDigitalChannelGroupType

The RioFaDigitalChannelGroupType aggregates RioFaDigitalInputChannelType Objects and RioFaDigitalOutputChannelType Objects. Alternatively, the server can omit the channel objects and provide Input- and Output image Variables only.

The InputImage Variable contains a bit field. The bit field contains the copy of one Input Telegram’s memory image associated with one PnIoSignalType Object. The InputImage Variable is linked to the associated PnIoSignalType Object using a 0:RepresentsSameEntityAs Reference.

The InputImageQualifiers Variable contains a bit field containing the qualifier bits for each bit in the InputImage Variable. The InputImageQualifier Variable is linked to the associated PnIoSignalType Object using a 0:RepresentsSameEntityAs Reference.

The bit numbers must be equal to the RioChannelNumber of the represented Input Channels. The RioChannelNumbers of the Input Channels shall have the value range 0 to <number of Input Channels> minus 1.

The OutputImage Variable contains a bit field. The bit field contains the copy of one Output Telegram’s memory image associated with one PnIoSignalType Object. The OutputImage Variable is linked to the associated PnIoSignalType Object using a 0:RepresentsSameEntityAs Reference.

The OutputImageQualifiers Variable contains a bit field containing the qualifier bits for each bit in the OutputImage Variable. The OutputImageQualifier Variable is linked to the associated PnIoSignalType Object using a 0:RepresentsSameEntityAs Reference.

The bit numbers must be equal to the RioChannelNumber of the represented Output Channels minus the number of Input Channels. The RioChannelNumbers of the Output Channels shall have the value range <number of Input Channels> to <number of Input Channels + number of Output Channels > minus 1.

If the number of RIO Channels the RIO Channel Group represents exceeds the capacity of the RioBitFieldVariableType (which is 32), as many RioBitFieldVariableType Variables shall be part of the RIO Channel Group Object as are needed to represent the qualifiers of all RIO Channels.

The BrowseNames of the RioBitFieldVariableType Variables shall be extended with a suffix ensuring uniqueness and indicating the section of the bitfield the variable represents in this case, e.g. “_0_31”, “_32_47”, and so on.

The optional Offset Property of the RioBitFieldVariableType Variables shall be provided in this case and contain the start of the range the RioBitFieldVariableType Variable represents. Possible Values for Offset are 0, 32, 64, and so on. The Offset Value added to the bit number shall be used as the RioChannelNumber of the corresponding RIO Channels. For bit fields representing Output Channels the number of Input Channels must be added also to obtain the RioChannelNumber of the represented Output Channel (see above).

7.2 OPC UA for RIO Channel Types

There are different RIO Channel types defined for each profile for digital and analog Input as well as for digital and analog Output. Table 29 lists the RIO Channel types defined in this specification for the Common Application Profiles RIOforPA and RIOforFA. All RIO Channel types are subtypes of the RioChannelType defined in chapter 7.2.1.

7.2.1 RioChannelType

The RioChannelType is the base type for all RIO-channel types. The type shall not be used directly. Instead, only the subtypes shall be instantiated.

The RioChannelNumber Property shall contain a unique channel number. Uniqueness shall be guaranteed for all RIO Channel Objects aggregated by a RIO Channel Group. The value range used for the RioChannelNumber Property Values shall be continuous and start with 0.

The ApplicationTag Variable contains information determined by configuration or by applications. The Client can change the content by invoking the SetApplicationTag Method.

7.2.1.1 SetApplicationTag Method

This Method sets the Value of the ApplicationTag Variable. The security constraints defined in chapter 6.7 apply.

Signature

	SetApplicationTag (
		[in] 0:String	 ApplicationTag
		);
	

The Method Result Codes (defined in Call Service) are defined in Table 31.

The Server might provide diagnosis data by sending RioChannelDiagnosisEventType Events and / or RioChannelDiagnosisAlarmType Events. The diagnosis data of the RioChannelGroup Object includes the diagnosis information of all aggregated RIO Channel Objects.

If the SetApplicationTag Method is invoked or if parameterization data provided by the subordinated RioChannelGroupConfigType Object is changed, the value of the LastParameterChange timestamp Variable shall be changed by the Server. This includes the EngineeringUnits and EURange Properties of Process Value Variables and any change of configuration data provided by the “Config” Objects.

The Lock Object ensures exclusive Method call for one Client. The Client locks the channel Object by invoking the InitLock Method of the Lock Object. The Client invokes ExitLock to release the lock.

Before invoking a Method of the channel Object, Clients must gain exclusive access (“lock” the channel Object) using the Lock Object.

7.2.2 Analog Input Channel Types

Figure 22 shows the block diagram for an analog Input Channel.

7.2.2.1 RioPaAnalogInputChannelType

The RioPaAnalogInputChannelType provides access to the data of an analog Rio Input Channel according to RIOforPA.

The ProcessValue Variable contains the current analog Input value for usage by a Controller.

The SignalValue Variable contains the input signal value obtained by reading the input signal through the signal coupling in the Transducer.

The Mode Variable contains the current mode of operation encoded as RioChannelModeEnumeration. If Mode has the Value MANUAL, the Value of the ManualProcessValue Variable shall be used as Process Value.

The ManualProcessValue Variable contains the value used as Process Value if the Mode Variable of the channel contains the Value MANUAL. The optional Variable is used for Devices according to the PA V3 profile and maps to the “manual out value” property defined by this profile.

The SimulationEnabled Variable contains True if the Value of the SimulationValue Variable shall be used as Process Value, otherwise False.

The SimulationValue Variable contains the value used as Process Value if the SimulationEnabled Variable contains the Value True.

The Config Variable contains the configuration properties available for the RIO Channel. See the definition of the RioPaAnalogInputConfigVariableType (see chapter 9.4.5).

7.2.2.2 SetMode Method

This Method sets the Value of the Mode Variable. The security constraints defined in chapter 6.7 apply.

Signature

	SetMode (
		[in] RioChannelModeEnumeration	 Mode
		);
	

The Method Result Codes (defined in Call Service) are defined in Table 33.

If the Mode Variable has already the same Value as the argument, the Method shall do nothing and return Good as result code.

7.2.2.3 SetManualProcessValue Method

This Method sets the Value of the ManualProcessValue Variable. The security constraints defined in chapter 6.7 apply.

Signature

	SetManualProcessValue (
		[in] RioAnalogDataType		ManualProcessValue
		);
	

The Method Result Codes (defined in Call Service) are defined in Table 34.

If the ManualProcessValue Variable has already the same Value as the argument, the Method shall do nothing and return Good as result code.

7.2.2.4 SetSimulation Method

This Method sets the Value of the SimulationEnabled Variable to the desired value. The security constraints defined in chapter 6.7 apply.

Signature

	SetSimulation (
		[in] 0:Boolean 	SimulationEnabled
	);
	

The Method Result Codes (defined in Call Service) are defined in Table 35.

If the SimulationEnabled Variable already has the Value of the argument, the Method shall do nothing and return Good as result code.

7.2.2.5 SetSimulationValue Method

This Method sets the Value of the SimulationValue Variable. The security constraints defined in chapter 6.7 apply.

Signature

	SetSimulationValue (
		[in] RioAnalogDataType		Value
		[in] 0:Byte		Qualifier
		);
	

The Method Result Codes (defined in Call Service) are defined in Table 36.

7.2.2.6 RioFaAnalogInputChannelType

The RioFaAnalogInputChannelType provides access to the data of an analog RIO Input Channel according to RIOforFA.

The ProcessValue Variable contains the current analog Input value for usage by a Controller.

The SignalValue Variable contains the input signal value obtained by reading the input signal through the signal coupling in the Transducer.

The Config Variable contains the configuration properties available for the RIO Channel. See the definition of the RioFaAnalogInputConfigVariableType (see chapter 9.4.6).

7.2.3 Analog Output Channel Types

Figure 23 shows the block diagram for an analog Output Channel.

7.2.3.1 RioPaAnalogOutputChannelType

The RioPaAnalogOutputChannelType provides access to the data of an analog RIO Output Channel according to RIOforPA.

The ProcessValue Variable contains the current analog Output value for an automated process.

The ProcessValueReadback Variable contains the readback value obtained by reading the output signal back through the Transducer and the Function Block.

The SignalValue Variable contains the output signal value fed to the signal coupling in the Transducer.

The SignalValueReadback Variable contains the output signal read back through the signal coupling in the Transducer.

The Mode Variable contains the current mode of operation encoded as RioChannelModeEnumeration. If Mode has the Value MANUAL, the Value of the ManualOutValue Variable shall be used as Output value in place of the Process Value.

The ManualOutValue Variable contains the value used as Output value to an automated process in place of the Process Value if the Mode Variable of the channel contains the Value MANUAL.

The SimulationEnabled Variable contains True if the Value of the SimulationValue Variable shall be used as Output value in place of the Process Value, otherwise False.

The SimulationValue Variable contains the value used as Output value in place of the Process Value if the SimulationEnabled Variable contains True.

The Config Variable contains the configuration properties available for the RIO Channel. See the definition of the RioPaAnalogOutputConfigVariableType (See chapter 9.4.7).

7.2.3.2 SetMode Method

This Method sets the Value of the Mode Variable. The security constraints defined in chapter 6.7 apply.

Signature

	SetMode (
		[in] RioChannelModeEnumeration	Mode	
		);
	

The Method Result Codes (defined in Call Service) are defined in Table 39.

If the Mode Variable has already the same Value as the argument, the Method shall do nothing and return Good as result code.

7.2.3.3 SetManualOutValue Method

This Method sets the Value of the ManualOutValue Variable. The security constraints defined in chapter 6.7 apply.

Signature

	SetManualOutValue (
		[in] RioAnalogDataType		ManualOutValue
		);
	

The Method Result Codes (defined in Call Service) are defined in Table 40.

If the ManualOutValue Variable has already the same Value as the argument, the Method shall do nothing and return Good as result code.

7.2.3.4 SetSimulation Method

This Method sets the Value of the SimulationEnabled Variable to the desired value. The security constraints defined in chapter 6.7 apply.

Signature

	SetSimulation (
		[in] 0:Boolean	SimulationEnabled
	);
	

The Method Result Codes (defined in Call Service) are defined in Table 41.

If the SimulationEnabled Variable already has the value of the argument, the Method shall do nothing and return Good as result code.

7.2.3.5 SetSimulationValue Method

This Method sets the Value of the SimulationValue Variable. The security constraints defined in chapter 6.7 apply.

Signature

	SetSimulationValue (
		[in] 0:RioAnalogDataType	Value
		[in] 0:Byte		Qualifier
		);
	

The Method Result Codes (defined in Call Service) are defined in Table 42.

7.2.3.6 RioFaAnalogOutputChannelType

The RioFaAnalogOutputChannelType provides access to the data of an analog RIO Output Channel according to RIOforFA.

The ProcessValue Variable contains the current analog Output value for an automated process.

The ProcessValueReadback Variable contains the readback value obtained by reading the output signal back through the Transducer and the Function Block.

The SignalValue Variable contains the output signal value fed to the signal coupling in the Transducer.

The SignalValueReadback Variable contains the output signal read back through the signal coupling in the Transducer.

The Config Variable contains the configuration properties available for the RIO Channel. See the definition of the RioFaAnalogOutputConfigVariableType (see chapter 9.4.8).

7.2.4 Digital Input Channel Types

Figure 24 shows the block diagram for a digital Input Channel.

7.2.4.1 RioPaDigitalInputChannelType

The RioPaDigitalInputChannelType provides access to the data of a discrete RIO Input Channel according to RIOforPA.

The ProcessValue Variable contains the digital Input value for a Controller.

The SignalValue Variable contains the input signal value obtained by reading the input signal through the signal coupling in the Transducer.

The Mode Variable contains the current mode of operation encoded as RioChannelModeEnumeration. If Mode has the Value MANUAL, the Value of the ManualProcessValue Variable shall be used as Process Value.

The ManualProcessValue Variable contains the value used as Process Value if the Mode Variable of the channel contains the Value MANUAL. The optional Variable is used for Devices according to the PA V3 profile and maps to the “manual out value” property defined by this profile.

The SimulationEnabled Variable contains True if the Value of the SimulationValue Variable shall be used as Process Value, otherwise False.

The SimulationValue Variable contains the value used as Process Value if the SimulationEnabled Variable contains the Value True.

The Config Variable contains the configuration properties available for the RIO Channel. See the definition of the RioPaDigitalInputConfigVariableType (See 9.4.1)

7.2.4.2 SetMode Method

This Method sets the Value of the Mode Variable. The security constraints defined in chapter 6.7 apply.

Signature

	SetMode (
		[in] RioChannelModeEnumeration	Mode	
		);
	

The Method Result Codes (defined in Call Service) are defined in Table 45.

If the Mode Variable has already the same Value as the argument, the Method shall do nothing and return Good as result code.

7.2.4.3 SetManualProcessValue Method

This Method sets the Value of the ManualProcessValue Variable. The security constraints defined in chapter 6.7 apply.

Signature

	SetManualProcessValue (
		[in] 0:Boolean		ManualProcessValue
		);
	

The Method Result Codes (defined in Call Service) are defined in Table 46.

If the ManualProcessValue Variable has already the same Value as the argument, the Method shall do nothing and return Good as result code.

7.2.4.4 SetSimulation Method

This Method sets the Value of the SimulationEnabled Variable to the desired value. The security constraints defined in chapter 6.7 apply.

Signature

	SetSimulation (
		[in] 0:Boolean	SimulationEnabled
	);
	

The Method Result Codes (defined in Call Service) are defined in Table 47.

If the SimulationEnabled Variable already has the value of the argument, the Method shall do nothing and return Good as result code.

7.2.4.5 SetSimulationValue Method

This Method sets the Value of the SimulationValue Variable. The security constraints defined in chapter 6.7 apply.

Signature

	SetSimulationValue (
		[in] 0:Boolean	Value
		[in] 0:Byte		Qualifier
		);
	

The Method Result Codes (defined in Call Service) are defined in Table 48.

7.2.4.6 RioFaDigitalInputChannelType

The RioFaDigitalInputChannelType provides access to the data of a discrete RIO Input Channel according to RIOforFA.

The ProcessValue Variable contains the digital Input value for a Controller.

The SignalValue Variable contains the input signal value obtained by reading the input signal through the signal coupling in the Transducer.

The Config Variable contains the configuration properties available for the RIO Channel. See the definition of the RioFaDigitalInputConfigVariableType (see chapter 9.4.2).

7.2.5 Digital Output Channel Types

Figure 25 shows the block diagram for a digital Output Channel.

7.2.5.1 RioPaDigitalOutputChannelType