For the purposes of this document, the terms and definitions given in OPC 10000-1, OPC 10000-3, OPC 100004, OPC 10000-6 and the following apply.

ISO and IEC maintain terminology databases for use in standardization at the following addresses:

• IEC Electropedia: available at https://www.electropedia.org/
• ISO Online browsing platform: available at https://www.iso.org/obp

NOTE This document uses concepts of OPC UA information modeling to describe the concepts in this document.

CRC

<value> redundant data derived from, and stored or transmitted together with, a block of data in order to detect data corruption

<method> procedure used to calculate the redundant data

Note 1 to entry: Terms “CRC code” and “CRC signature”, and labels such as CRC1, CRC2, may also be used in this document to refer to the redundant data.

[SOURCE: IEC 61784-3:2021, 3.10]

discrepancy between a computed, observed or measured value or condition and the true, specified or theoretically correct value or condition

Note 1 to entry: Errors may be due to design mistakes within hardware/software and/or corrupted information due to electromagnetic interference and/or other effects.

Note 2 to entry: Errors do not necessarily result in a failure or a fault.

[SOURCE: IEC 60050-192:2024, 192-03-02, modified – notes added]

termination of the ability of a functional unit to perform a required function or operation of a functional unit in any way other than as required

Note 1 to entry: Failure may be due to an error (for example, problem with hardware/software design or message disruption).

[SOURCE: IEC 615084:2010, 3.6.4, modified – notes and figures deleted, new note to entry added]

abnormal condition that may cause a reduction in, or loss of, the capability of a functional unit to perform a required function

Note 1 to entry: IEV 1910501 defines “fault” as a state characterized by the inability to perform a required function, excluding the inability during preventive maintenance or other planned actions, or due to lack of external resources.

[SOURCE: IEC 615084:2010, 3.6.1, modified – figure reference deleted]

<information theory and communication theory> ordered sequence of characters (usually octets) intended to convey information

[SOURCE: ISO/IEC 2382:2015, 2123031, modified – insertion of "(usually octets)", deletion of notes and source]

PL

discrete level used to specify the ability of safety-related parts of control systems to perform a safety function under foreseeable conditions

[SOURCE: ISO 138491:2023, 3.1.5]

probability of an error undetected by the SCL safety measures

[SOURCE: IEC 61784-3:2021 3.1]

statistical rate at which the SCL safety measures fail to detect errors

[SOURCE: IEC 61784-3:2021, 3.1.35]

SCL

communication layer above the OPC UA communication stack that includes all necessary additional measures to ensure safe transmission of data in accordance with the requirements of IEC 61508

Note 1 to entry: The SCL provides several services, the most important ones being the SafetyProvider and the SafetyConsumer.

[SOURCE: IEC 61784-3:2021, 3.1.39 modified – “FAL” replaced by “OPC UA communication stack”, not to entry added]

worst case elapsed time following an actuation of a safety sensor connected to a fieldbus, until the corresponding safe state of its safety actuator(s) is achieved in the presence of errors or failures in the safety function

Note 1 to entry: This concept is introduced in IEC 617843:2021, 5.2.4 and is addressed by the functional safety communication profiles defined in the IEC 61784-3 series of documents.

[SOURCE: IEC 61784-3:2021, 3.1.44]

SIL

discrete level (one out of a possible four), corresponding to a range of safety integrity values, where safety integrity level 4 has the highest level of safety integrity and safety integrity level1 has the lowest

Note 1 to entry:  The target failure measures (see IEC 615084:2010, 3.5.17) for the four safety integrity levels are specified in Table 2 and Table 3 of IEC 615081:2010.

Note 2 to entry:  Safety integrity levels are used for specifying the safety integrity requirements of the safety functions to be allocated to the E/E/PE safety-related systems.

Note 3 to entry:  A safety integrity level (SIL) is not a property of a system, subsystem, element or component. The correct interpretation of the phrase “SIL n safety-related system” (where n is 1, 2, 3 or 4) is that the system is potentially capable of supporting safety functions with a safety integrity level up to n.

[SOURCE: IEC 615084:2010, 3.5.8]

measure to control possible communication errors that is designed and implemented in compliance with the requirements of IEC 61508

Note 1 to entry:  In practice, several safety measures are combined to achieve the required safety integrity level.

Note 2 to entry:  Communication errors and related safety measures are detailed in IEC 617843:2021, 5.3 and 5.4.

[SOURCE: IEC 61784-3:2021, 3.1.46]

SPDU

PDU transferred through the safety communication channel

Note 1 to entry: The SPDU may include more than one copy of the SafetyData using differing coding structures and hash functions together with explicit parts of additional protections such as a key, a sequence count, or a time stamp mechanism.

Note 2 to entry: Redundant SCLs may provide two different versions of the SPDU for insertion into separate fields of the OPC UA frame.

[SOURCE: IEC 61784-3:2021, 3.1.47]

ability of a system that, by adequate technical or organizational measures, prevents from hazards either deterministically or by reducing the risk to a tolerable measure

Note 1 to entry:  Equivalent to functional safety.

FSV

values which are issued or delivered instead of process values when the safety function is set to a fail-safe state

Note 1 to entry:  In this document, the fail-safe substitute values (FSV) are always set to binary “0”.

one-bit value used to indicate a certain status or control information

GUID

128-bit number used to identify information in computer systems

Note 1 to entry:  The term universally unique identifier (UUID) is also used.

Note 2 to entry:  In this document, UUID version 4 is used.

MNR

means used to ensure the correct order among transmitted safety PDUs and to monitor the communication delay

Note 1 to entry:  Instance of sequence number as described in IEC 617843.

Note 2 to entry:  The MNR starts at a random value and is incremented with each request. It rolls over to a minimum threshold value that is not zero.

Note 3 to entry:  The transmitted MNR is protected by the transmitted CRC signature of the ResponseSPDU.

predicate meaning that the respective object is a “standard” object and has not been designed and implemented to fulfil any requirements with respect to functional safety

non-safety-related part of the implementation of this document which maps the SPDU to the actual OPC UA services

Note 1 to entry:  Depending on which services of OPC UA are being used (e.g. Client/Server or PubSub), different mappers can be specified.

PV

input and output data (in a safety PDU) that are required to control an automated process

attribute (bit or Boolean), indicating whether the corresponding value is valid or not (e.g. being a fail-safe substitute value)

SafetyAC

communication partner in a unidirectional safety link

Note 1 to entry:  A SafetyAutomationComponent can be a SafetyProvider (data source), a SafetyConsumer (data sink), or both.

entity (usually software) that implements the data sink of a unidirectional safety link

application data transmitted across a safety network using a safety protocol

Note 1 to entry;  The safety communication layer does not ensure the safety of the data itself, but only that the data is transmitted safely.

entity (usually software) that implements the data source of a unidirectional safety link

randomly generated authenticity ID which is used to safely authenticate SafetyProviders having the same SafetyProviderID

Note 1 to entry:  Together with the SafetyProviderID, it is an instance of connection authentication as described in IEC 617843.

user-assigned, locally unique identifier which is used to safely authenticate SafetyProviders within a certain area

Note 1 to entry:  Together with the SafetyBaseID, it is an instance of connection authentication as described in IEC 617843.

Note 1 to entry:  All SafetyProviders within an area such defined may share an identical SafetyBaseID.

part of the transmission system (implemented in hardware and software) that is not implemented according to any safety standards

Note 1 to entry:  This document is using the services of the standard transmission system to transmit prebuilt safety packets.

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

CRC	Cyclic Redundancy Check
PDU	Protocol Data Unit	[ISO/IEC 74981]
PL	Performance Level	[ISO 138491]
PLC	Programmable Logic Controller
SCL	Safety Communication Layer
SIL	safety integrity level	[IEC 615084]
SPDU	Safety PDU, Safety Protocol Data Unit

FSV	Fail-safe substitute Values
HMI	Human-machine interface
ID	Identifier
LSB	Least significant bit
MNR	MonitoringNumber
MSB	Most significant bit
OA	Operator Acknowledgment
OPC UA PI	OPC UA Platform Interface
PI	Platform Interface
PV	Process Values
SAPI	Safety Application Program Interface
SFRT	Safety Function Response Time
SPI	Safety Parameter Interface
STrailer	Safety Trailer
TRA	threat and risk analysis

p	Bit error probability
Pre,cond	Conditional residual error probability

Italics are used to denote a defined term or definition that appears in 3.1.

Italics are also used to denote the name of a service input or output parameter or the name of a structure or element of a structure that are usually defined in tables.

The italicized terms and names are also often written in camel-case (the practice of writing compound words or phrases in which the elements are joined without spaces, with each element's initial letter capitalized within the compound). For example, the defined term is AddressSpace instead of Address Space. This makes it easier to understand that there is a single definition for AddressSpace, not separate definitions for Address and Space. Terms or names where two capital letters of abbreviations are in sequence or for separation to a suffix are written with underscores in between.

The abbreviation “F” is an indication for safety- related items, technologies, systems, and units (fail-safe, functional safe).

The default data that are used in case of unit failures or errors, are called fail-safe substitute values (FSV) and are set to binary “0”.

Reserved bits (“res”) are set to “0” and ignored by the receiver to avoid problems with future versions of this document.

The notation 0x… represents a hexadecimal value.

Requirements in this document are designated as [RQx.yz], where x denotes the chapter number, y is a counter and z is an optional character to link closely related requirements. The following are examples of valid requirements designations: [RQ8.15] (requirement 15 in chapter 8); [RQ47.11a], [RQ47.11b] (requirements 11a and 11b in chapter 47, which are closely related).

The initial numbering of requirements was chosen such that counters within each chapter are in ascending order. However, the addition of further requirements leads to deviations from this rule since existing requirements shall keep their initial designation.

For an informative index of all the requirements in this document, see 10.3.

See Table 1 for the conventions used in state machines.

Table 1 – Conventions used in state machines

Convention	Meaning
:=	Assignment: value of an item on the left is replaced by value of the item on the right.
<	Less than: a logical condition yielding TRUE if and only if an item on the left is less than the item on the right.
<=	Less or equal than: a logical condition yielding TRUE if and only if an item on the left is less or equal than the item on the right.
>	Greater than: a logical condition yielding TRUE if and only if the item on the left is greater than the item on the right.
>=	Greater or equal than: a logical condition yielding TRUE if and only if the item on the left is greater or equal than the item on the right.
==	Equality: a logical condition yielding TRUE if and only if the item on the left is equal to an item on the right.
<>	Inequality: a logical condition yielding TRUE if and only if the item on the left is not equal to an item on the right.
&&	Logical “AND” (Operation on binary values or results).
||	Logical “OR” (Operation on binary values or results).
	Logical “XOR” (Operation on binary values or digital values).
[..]	UML Guard condition, if and only if the guard is TRUE the respective transition is enabled.