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.
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.
Figure 8 – Analog Input Channel Model in Functional Aspect with 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.
Figure 9 – RioChannel ObjectTypes
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.
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.
Figure 10 – PROFINET Telegram Model
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.
Figure 11 – 2 analog RIOforPA channels
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.
Figure 12 – 2 analog RIOforPA Channels connected with Cyclic IO Telegram Model
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.
Figure 13 – RIOforPA digital Output Channel Model
No separate qualifier Signal Objects and no 0:RepresentsSameEntityAs References to qualifier Variables exist for digital RIOforPA values, as shown in Figure 14.
Figure 14 – 2 digital RIOforPA Channels connected with Cyclic IO Telegram Model
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.
Figure 16 – 2 analog RIOforFA Output Channels
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.
Figure 17 – RIOforFA Digital Input Channel Model
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 18 – RIO FA Digital Input Channel Group
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 19 – RIO FA Digital Output Channel Group
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 20 – RIOforPA Analog Input Channel Group
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.
Figure 21 – RIOforPA Digital Output Channel Group
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.
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.
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.
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.
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.
Table 13 – Condensed status restricted to NE 107
NE 107 |
Status Byte Values |
Description according to Profile |
OPC UA Status Code |
RioQualityEnumeration |
RioSpecifierEnumeration |
RioQualifierEnumeration |
|
Failure (F) |
0x24,0x26 |
BAD - maintenance alarm, more diagnosis available |
Bad, 0x80000000 |
BAD |
FAILURE |
BAD_MAINTENANCE_ALARM |
0x25, 0x27 |
BAD_MAINTENANCE_ALARM_SIMULATION_ACTIVE |
Check(C) |
0x3C, 0x3E |
BAD - function check / local override |
Bad, 0x80000000 |
BAD |
FUNCTION_CHECK |
BAD_FUNCTION_CHECK |
0x3D, 0x3F |
BAD_FUNCTION_CHECK_SIMULATION_ACTIVE |
Out of Specification (S) |
0x78, 0x7A |
UNCERTAIN - process related, no maintenance |
Uncertain, 0x40000000 |
UNCERTAIN |
OUT_OF_SPECIFICATION |
UNCERTAIN_NO_MAINTENANCE |
0x79, 0x7B |
UNCERTAIN_NO_MAINTENANCE_SIMULATION_ACTIVE |
Maintenance (M) |
0xA4, 0xA6 |
GOOD - maintenance required |
Good, 0x00000000 |
GOOD |
MAINTENANCE_REQUEST |
GOOD_MAINTENANCE_REQUIRED |
0xA5, 0xA7 |
GOOD_MAINTENANCE_REQUIRED_SIMULATION_ACTIVE |
0xA8, 0xAA |
GOOD - maintenance demanded |
Good, 0x00000000 |
GOOD |
MAINTENANCE_REQUEST |
GOOD_MAINTENANCE_DEMANDED |
0xA9, 0xAB |
GOOD_MAINTENANCE_DEMANDED_SIMULATION_ACTIVE |
Good (G) |
0x80 |
GOOD - ok |
Good, 0x00000000 |
GOOD |
NORMAL |
GOOD |
|
Check (C) |
0x81 |
GOOD - simulation active |
GoodEdited, 0x00DC0000 |
GOOD |
FUNCTION_CHECK |
GOOD_SIMULATION_ACTIVE |
|
Good (G) |
0x82 |
GOOD - update event |
Good, 0x00000000 |
GOOD |
NORMAL |
UPDATE |
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.
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.
Table 14 – Condensed status with detailed information
NE 107 |
Status Byte Range |
Description according to Profile |
OPC UA Status Code |
RioQualityEnumeration |
RioSpecifierEnumeration |
RioQualifierEnumeration |
Failure (F) |
0x00 |
BAD - non specific |
Bad, 0x80000000 |
BAD |
FAILURE |
BAD_NON_SPECIFIC |
Failure (F) |
0x08, 0x0A |
BAD - not connected |
BadNotConnected, 0x808A0000 |
BAD |
FAILURE |
BAD_NOT_CONNECTED |
0x09, 0x0B |
BAD_NOT_CONNECTED_ SIMULATION_ACTIVE |
Failure (F) |
0x20, 0x22 |
BAD - passivated |
BadOutOfService, 0x808D0000 |
BAD |
FAILURE |
BAD_PASSIVATED |
0x21, 0x23 |
BAD_PASSIVATED_SIMULATION_ACTIVE |
Failure (F) |
0x24, 0x26 |
BAD - maintenance alarm, more diagnosis available |
Bad, 0x80000000 |
BAD |
FAILURE |
BAD_MAINTENANCE_ALARM |
0x25, 0x27 |
BAD_MAINTENANCE_ALARM_ SIMULATION_ACTIVE |
Failure (F) |
0x28, 0x2A |
BAD - process related, no maintenance |
Bad, 0x80000000 |
BAD |
FAILURE |
BAD_PROCESS |
0x29, 0x2B |
BAD_PROCESS_SIMULATION_ACTIVE |
Check(C) |
0x3C, 0x3E |
BAD - function check / local override |
Bad, 0x80000000 |
BAD |
FUNCTION_CHECK |
BAD_FUNCTION_CHECK |
0x3D, 0x3F |
BAD_FUNCTION_CHECK_ SIMULATION_ACTIVE |
Failure (F) |
0x48, 0x4A |
UNCERTAIN - substitute set |
UncertainSubstituteValue, 0x40910000 |
UNCERTAIN |
FAILURE |
UNCERTAIN_SUBSTITUTE_SET |
0x49, 0x4B |
UNCERTAIN_SUBSTITUTE_SET_ SIMULATION_ACTIVE |
Check (C) |
0x4C, 0x4E |
UNCERTAIN - initial value |
UncertainInitialValue, 0x40920000 |
UNCERTAIN |
FUNCTION_CHECK |
UNCERTAIN_INITIAL_VALUE |
0x4D, 0x4F |
UNCERTAIN_INITIAL_VALUE_ SIMULATION_ACTIVE |
Maintenance (M) |
0x68, 0x6A |
UNCERTAIN - maintenance demanded |
Uncertain, 0x40000000 |
UNCERTAIN |
MAINTENANCE_REQUEST |
UNCERTAIN_MAINTENANCE_ DEMANDED |
0x69, 0x6B |
UNCERTAIN_MAINTENANCE_ DEMANDED_SIMULATION_ACTIVE |
Out of Specification (S) |
0x78, 0x7A |
UNCERTAIN - process related, no maintenance |
Uncertain, 0x40000000 |
UNCERTAIN |
OUT_OF_SPECIFICATION |
UNCERTAIN_NO_MAINTENANCE |
0x79, 0x7B |
UNCERTAIN_NO_MAINTENANCE_ SIMULATION_ACTIVE |
Good (G) |
0x80, 0x82 |
GOOD |
Good, 0x00000000 |
GOOD |
NORMAL |
GOOD |
0x81, 0x83 |
GOOD_SIMULATION_ACTIVE |
Good (G) |
0xA0 |
GOOD - initiate fail safe |
GoodInitiateFault State, 0x04080000 |
GOOD |
NORMAL |
GOOD_INITIATE_FAULT_STATE |
Maintenance (M) |
0xA4, 0xA6 |
GOOD - maintenance required |
Good, 0x00000000 |
GOOD |
MAINTENANCE_REQUEST |
GOOD_MAINTENANCE_REQUIRED |
0xA5, 0xA7 |
GOOD_MAINTENANCE_REQUIRED_ SIMULATION_ACTIVE |
0xA8, 0xAA |
GOOD - maintenance demanded |
Good, 0x00000000 |
GOOD |
MAINTENANCE_REQUEST |
GOOD_MAINTENANCE_DEMANDED |
0xA9, 0xAB |
GOOD_MAINTENANCE_DEMANDED_ SIMULATION_ACTIVE |
Good (G) |
0x9C, 0x9E |
GOOD - local override |
GoodLocalOverride, 0x00960000 |
GOOD |
NORMAL |
GOOD_LOCAL_OVERRIDE |
0x9D, 0x9F |
GOOD_LOCAL_OVERRIDE_ SIMULATION_ACTIVE |
Good (G) |
0xBC, 0xBE |
GOOD - function check |
Good, 0x00000000 |
GOOD |
NORMAL |
GOOD_FUNCTION_CHECK |
0xBD, 0xBF |
GOOD_FUNCTION_CHECK_ SIMULATION_ACTIVE |
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.
Table 15 – Classic status codes
Sub-status |
Description |
OPC UA Status Code |
Status Byte |
RioQualityEnumeration |
RioSpecifier Enumeration UNSPECIFIED |
RioQualifierEnumeration |
Quality BAD |
||||||
0 |
non-specific |
Bad, 0x80000000 |
0x00.. 0x03 |
BAD |
|
BAD_NOT_SPECIFIC |
1 |
configuration error |
BadConfigurationError, 0x80890000 |
0x04.. 0x07 |
BAD_NOT_SPECIFIC |
||
2 |
not connected |
BadNotConnected, 0x808A0000 |
0x08.. 0x0B |
BAD_NOT_CONNECTED |
||
3 |
device failure |
BadDeviceFailure, 0x808B0000 |
0x0C.. 0x0F |
BAD_NOT_SPECIFIC |
||
4 |
sensor failure |
BadSensorFailure, 0x808C0000 |
0x10.. 0x13 |
BAD_NOT_SPECIFIC |
||
5 |
no communication (LUV) |
BadCommunicationError, 0x80050000 |
0x14.. 0x17 |
BAD_NOT_SPECIFIC |
||
6 |
no communication (no LUV) |
BadNoCommunication, 0x80310000 |
0x18.. 0x1B |
BAD_NOT_SPECIFIC |
||
7 |
out of service |
BadOutOfService, 0x808D0000 |
0x1C.. 0x1F |
BAD_PASSIVATED |
||
Quality UNCERTAIN |
||||||
0 |
non specific |
Uncertain, 0x40000000 |
0x40.. 0x43 |
UNCERTAIN |
|
UNCERTAIN_NO_ MAINTENANCE |
1 |
last usable value (LUV) |
UncertainLastUsableValue, 0x40900000 |
0x44.. 0x47 |
UNCERTAIN_NO_ MAINTENANCE |
||
2 |
substitute value |
UncertainSubstituteValue, 0x40910000 |
0x48.. 0x4B |
UNCERTAIN_SUBSTITUTE_SET |
||
3 |
initial value |
UncertainInitialValue, 0x40920000 |
0x4C.. 0x4F |
UNCERTAIN_INITIAL_VALUE |
||
4 |
sensor conversion not accurate |
UncertainSensorNotAccurate, 0x40930000 |
0x50.. 0x53 |
UNCERTAIN_NO_ MAINTENANCE |
||
5 |
engineering unit violation |
UncertainEngineeringUnits Exceeded, 0x40940000 |
0x54.. 0x57 |
UNCERTAIN_NO_ MAINTENANCE |
||
6 |
sub normal |
UncertainSubNormal, 0x40950000 |
0x58.. 0x5B |
UNCERTAIN_NO_ MAINTENANCE |
||
7 |
configuration error |
UncertainConfigurationError, 0x420F0000 |
0x5C.. 0x5F |
UNCERTAIN_NO_ MAINTENANCE |
||
8 |
simulated value |
UncertainSimulatedValue, 0x42090000 |
0x60.. 0x63 |
UNCERTAIN_NO_ MAINTENANCE_SIMULATION_ACTIVE |
||
9 |
sensor calibration |
UncertainSensorCalibration, 0x420A0000 |
0x64.. 0x67 |
UNCERTAIN_NO_ MAINTENANCE |
||
Quality GOOD (Non Cascade) |
||||||
0 |
ok |
Good, 0x00000000 |
0x80.. 0x83 |
GOOD |
|
GOOD |
1 |
update event |
Good, 0x00000000 |
0x84.. 0x87 |
GOOD |
||
2 |
active advisory alarm |
GoodFaultStateActive, 0x04070000 |
0x88.. 0x8B |
GOOD |
||
3 |
active critical alarm |
GoodFaultStateActive, 0x04070000 |
0x8C.. 0x8F |
GOOD |
||
4 |
unacknowledged update event |
Good, 0x00000000 |
0x90.. 0x93 |
GOOD |
||
5 |
unacknowledged advisory alarm |
GoodFaultStateActive, 0x04070000 |
0x94.. 0x97 |
GOOD |
||
6 |
unacknowledged critical alarm |
GoodFaultStateActive, 0x04070000 |
0x98.. 0x9B |
GOOD |
||
7 |
reserved |
- |
|
|
|
|
8 |
initiate fail safe |
GoodInitiateFaultState, 0x04080000 |
0xA0 |
GOOD |
GOOD_INITIATE_ FAULT_STATE |
|
9 |
maintenance required |
Good, 0x00000000 |
0xA4.. 0xA7 |
GOOD_MAINTENANCE_ REQUIRED |
||
Quality GOOD (Cascade) |
||||||
0 |
ok |
GoodCascade, 0x04090000 |
0xC0.. 0xC3 |
GOOD |
|
GOOD |
1 |
initialization acknowledged |
GoodCascadeInitializationAcknowledged, 0x04010000 |
0xC4.. 0xC7 |
GOOD |
||
2 |
initialization request |
GoodCascadeInitializationRequest, 0x04020000 |
0xC8.. 0xCB |
GOOD |
||
3 |
not invited |
GoodCascadeNotInvited, 0x04030000 |
0xCC.. 0xCF |
GOOD |
||
4 |
reserved |
- |
|
|
|
|
5 |
do not select |
GoodCascadeNotSelected, 0x04040000 |
0xD4.. 0xD7 |
GOOD |
GOOD |
|
6 |
local override |
GoodLocalOverride, 0x00960000 |
0xD8.. 0xDB |
GOOD_LOCAL_OVERRIDE |
||
7 |
reserved |
- |
|
- |
|
|
8 |
initial fail safe |
GoodInitiateFaultState, 0x04080000 |
0xE0 |
GOOD |
GOOD_INITIATE_ FAULT_STATE |
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.
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.
Table 16 – RIOforFA StatusCodes
Status Bit Value |
Description according to Profile (See [RIO FA] chapter 7.1) |
OPC UA Status Code |
RioQualityEnumeration |
1 (good) |
Input: Process Value can be used by host application. Output: Physical signal equals Process Value. |
Good, 0x00000000 |
GOOD |
0 (bad) |
Input: Process Value should not be used by host application. Output: Substitute Value applied by (Sub)Module. |
Bad, 0x80000000 |
BAD |
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”.