The pair of SafetyProviderID and SafetyBaseID is used by the SafetyConsumer to check the authenticity of the ResponseSPDU. SafetyProviderID and SafetyBaseID are usually assigned during engineering or during commissioning. It is in the responsibility of the end user or OEM to assign unique SafetyProviderID to individual SafetyProviders whenever this is reasonable possible. For instance, a machine builder should assign unique SafetyProviderIDs within a single machine containing multiple devices which run implementations of this document.

As the effort for the administration of unique SafetyProviderIDs will reach its limits when the system becomes large, this document uses the SafetyBaseID for cases where guaranteeing unique SafetyProviderIDs is not possible.

A SafetyBaseID is a universal unique identifier version4 (UUIDv4, also called globally unique identifier (GUID)), as described in ISO/IEC 9834-8, Clause 15. Basically, it is a 128-bit number where at least 96 bits were chosen randomly. The probability that two randomly generated UUIDs are identical is extremely low (2-96 < 10-28), and can therefore be neglected, even when considering applications with a safety integrity level of 4.

It is not necessary to generate an individual SafetyBaseIDs for all SafetyProviders. If two SafetyProviders can be discriminated by their SafetyProviderIDs, they may share the same SafetyBaseID. For instance, a machine builder might generate a unique SafetyBaseID for each instance of a machine, which is reused for all SafetyProviders within a machine.

When implementing or using a generator for the UUIDs, it must be ensured that each possible value is generated with equal probability (discrete uniform distribution), and that any two values are independent from each other. When a pseudo random number generator (PNRG) is used, it is ‘seeded’ with a random source having enough collision entropy (e.g., seeds of at least 128 bits that are uniformly distributed, too; and all seeds being pairwise independent from each other).

Most commercial systems offer random number generators for applications within a cryptographic context. These applications pose even harder requirements on the quality of random numbers than the ones mentioned above. Hence, cryptographically strong random number generators are applicable to this document as well. See References [2]-[5], as well as OPC 10000-2, for detailed information.

Table 38 shows implementations of cryptographically strong random number-generators that can be used to calculate the random part of the UUIDv4:

Table 38 – Examples for cryptographically strong random number generators

Environment	Function
Microsoft® Windows® Operating Systems	BCryptGenRandom found in Bcrypt.dll
Unix®-like OS (e.g. Linux® / FreeBSD® / Solaris®)	Read from the file:/dev/urandom/
.NET®	RandomNumberGeneratorfrom System.Security.Cryptography
JavaScript®	Crypto.getRandomValues()
Java®	java.security.SecureRandom
Python®	os.urandom(size)

While being evaluated from a security point of view, probably none of these implementations has been validated with safety in mind. Therefore, there is a remaining risk that these implementations are subject to systematic implementation errors which might decrease the effectiveness of these random numbers. To overcome this problem, the output of the random number generator is not used directly, but a SHA256-hash is calculated over (1) the generator’s output, (2) a timestamp (wall-clock-time or persistent logical clock) and (3) a unique domain name. Any bits of the SHA256-hash can then be used to construct the random parts of the UUIDv4.

[RQ9.1] The parameters SafetyBaseID and SafetyProviderID shall be stored in a non-volatile, i.e., persistent, way.

The SafetyConsumerID allows for discrimination between RequestSPDUs and ResponseSPDUs belonging to different SafetyConsumers. It is mainly used for diagnostic purposes, such as detecting unintentional concurrent access of a single SafetyProvider by multiple SafetyConsumers. Safety-related communication errors which are detected by checking the SafetyConsumerID would also be detected by other mechanisms, including the MNR, the SafetyProviderID, and the SafetyConsumerTimeout.

From a safety point of view, there are no qualitative requirements regarding the generation or administration of the SafetyConsumerID. It can be assigned during engineering, commissioning, at startup, and may even change during runtime. It is not required to check for uniqueness of SafetyConsumerIDs.

However, assigning identical SafetyConsumerIDs to multiple consumers is not recommended because fault localization may become more difficult.