3 Terms, definitions, symbols, abbreviated terms and conventions

3.1 Terms and definitions

For the purposes of this document, the terms and definitions given in OPC 10000-1, OPC 10000-3, OPC 10000‑4, 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

3.1.1 Common terms and definitions

3.1.1.1 Cyclic Redundancy Check

<method> procedure used to calculate the redundant data

3.1.1.2 error

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

3.1.1.3 failure

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

3.1.1.4 fault

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

3.1.1.5 message

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

3.1.1.6 performance level

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

3.1.1.7 residual error probability

probability of an error undetected by the SCL safety measures

3.1.1.8 residual error rate

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

3.1.1.9 safety communication layer

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

3.1.1.10 safety function response time

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

3.1.1.11 safety integrity level

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

3.1.1.12 safety measure

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

3.1.1.13 safety PDU

PDU transferred through the safety communication channel

3.1.2 Additional terms and definitions

3.1.2.1 fail-safe

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

3.1.2.2 fail-safe substitute values

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

3.1.2.3 flag

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

3.1.2.4 Globally Unique Identifier

128-bit number used to identify information in computer systems

3.1.2.5 MonitoringNumber

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

3.1.2.6 Non-safety-

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

3.1.2.7 OPC UA Mapper

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

3.1.2.8 process values

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

3.1.2.9 qualifier

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

3.1.2.10 SafetyAutomationComponent

communication partner in a unidirectional safety link

3.1.2.11 SafetyConsumer

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

3.1.2.12 SafetyData

application data transmitted across a safety network using a safety protocol

3.1.2.13 SafetyProvider

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

3.1.2.14 SafetyBaseID

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

3.1.2.15 SafetyProviderID

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

3.1.2.16 standard transmission system

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

3.2 Symbols and abbreviated terms

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

3.2.1 Abbreviated terms from IEC 61784-3

3.2.2 Additional symbols and abbreviated terms

3.2.2.1 Abbreviated terms

3.2.2.2 Symbols

3.3 Conventions

3.3.1 General conventions

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.

3.3.2 Conventions for requirements numbering

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.

3.3.3 Conventions in state machines

See Table 1 for the conventions used in state machines.