Search

Scope: Core (OPC-10000-*) All specs

50 result(s) for SafetyProvider

OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

3.1.2.13 SafetyProvider

SafetyProvider entity (usually software) that implements the data source of a unidirectional safety link
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

4.3 Features

last SPDU sent and received is accessible in the Information Model of the SafetyProvider . Length of user data: 1 octet to 1 500 octets, structures of basic DataTypes
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

5.3 Safety measures

implemented: MonitoringNumber ; timeout with receipt in the SafetyConsumer ; set of IDs for the SafetyProvider ; Data Integrity check. Together, these safety measures address all possible transmission errors as listed ... Communication error Safety measures MonitoringNumber a Timeout with receipt b Set of IDs for SafetyProvider c Data integrity check d Corruption - - - X Unintended repetition X X - - Incorrect sequence X - - - Loss
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

5.4 Safety communication layer structure

Layer The safety applications in the User Layer are either directly connected to the SafetyProvider or SafetyConsumer , or they are connected via a machine-specific or process-specific interface, which ... This layer is within the scope of this document. It defines the two services SafetyProvider and SafetyConsumer as basic building blocks. Together, they form the safety communication layer ( SCL ), implemented
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

5.5 Requirements for CRC calculation

values (incl. CRC signature) being zero shall be ignored by the receiver ( SafetyConsumer and SafetyProvider ). For Client/Server communication, this means that a Method Call with all fields making
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

6.2.2.1 SafetyACSet Object

Server shall comprise one OPC UA Object derived from DataType SafetyProviderType for each SafetyProvider it implements, and one OPC UA Object derived from DataType SafetyConsumerType for each SafetyConsumer it implements ... Figure 6 ) can be found in OPC UA 10000-3. Figure 3 describes the SafetyProvider and the SafetyConsumer . NOTE 1 This document assumes (atomic) consistent data exchange between OPC mappers
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

6.2.2.3 Method ReadSafetyData

mandatory for the Facet SafetyProviderServerMapper . It is used to read SafetyData from the SafetyProvider . It is in the responsibility of the safety application that this Method is not concurrently called ... This DateType (including the DataTypeID ) is expected to be the same in both the SafetyProvider and the SafetyConsumer . Otherwise, the SafetyConsumer will not accept the transferred data and switch
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

6.2.2.4 Method ReadSafetyDiagnostics

Facet SafetyProviderServerMapper and optional for the Facet SafetyProviderPubSubMapper . It is provided for each SafetyProvider serving as a Diagnostic Interface , see 6.4.3 . See Table 9 for the arguments of Method ReadSafetyDiagnostics
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

6.2.2.5 Object SafetyPDUs

mandatory for the Facet SafetyProviderPubSubMapper and the Facet SafetyConsumerPubSubMapper It is used by the SafetyProvider to subscribe to the RequestSPDU and to publish the ResponseSPDU . The DataType of RequestSPDU
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

6.2.2.6 Objects SafetyProviderParameters and SafetyConsumerParameters

Objects SafetyProviderParameters and SafetyConsumerParameters Figure 6 shows the safety parameters for the SafetyProvider and the SafetyConsumer . Figure 6 - Safety parameters for the SafetyProvider and the SafetyConsumer Table 12 shows ... Refer to 6.3.3.3 for more details on the Safety Parameter Interface ( SPI ) of the SafetyProvider . Table 12 - SafetyProviderParametersType definition Attribute Value BrowseName SafetyProviderParametersType IsAbstract False References Node class BrowseName DataType
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

6.2.3.1 InFlagsType

communication analysis tool. It is not forwarded to the safety application by the SafetyProvider . If CommunicationError is necessary in the safety application, bidirectional communication can be implemented and the value ... error was detected in the previous ResponseSPDU . OperatorAckRequested 1 Used to inform the SafetyProvider that operator acknowledgment is requested. FSV_Activated 2 Used for conformance test of SafetyConsumer.SAPI.FSV_Activated. Bits
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

6.2.3.2 OutFlagsType

provider, hereby forwarded to the SafetyConsumer , see OperatorAckProvider in the SAPI of the SafetyProvider , 6.3.3.2 . ActivateFSV 1 Activation of fail-safe values by the safety application at the SafetyProvider , hereby ... forwarded to the SafetyConsumer , see ActivateFSV in the SAPI of the SafetyProvider , 6.3.3.2 . TestModeActivated 2 Enabling and disabling of test mode in the SafetyProvider, hereby forwarded to the SafetyConsumer
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

6.2.3.3 RequestSPDUDataType

definition of the RequestSPDUDataType. The Prefix "In" is interpreted from the SafetyProvider 's point of view and is used in a consistent manner to the parameters
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

6.2.3.4 ResponseSPDUDataType

shows the ResponseSPDUDataType Structure . The Prefix "Out" is interpreted from the SafetyProvider 's point of view and is used in a consistent manner to the parameters
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

6.2.4 SafetyProvider version

SafetyProvider version Future versions may use different identifiers (such as ReadSafetyDataV2 for the Method when using Client/Server communication or RequestSPDUV2DataType and ResponseSPDUV2DataType for the SPDU DataTypes when using PubSub communication ... allowing a SafetyProvider to implement multiple versions of this document at the same time. Hence, the same SafetyProvider can be accessed by SafetyConsumers of different versions
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

6.3.3.1 General

General Figure 8 shows an overview of the SafetyProvider interfaces. The SAPI is specified in 6.3.3.2 , the SPI is specified in 6.3.3.3 . Figure 8 - SafetyProvider interfaces
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

6.3.3.2 SAPI of SafetyProvider

SAPI of SafetyProvider [RQ6.12] The SAPI of the SafetyProvider represents the safety communication layer services of the SafetyProvider . Table 23 lists all inputs and outputs of the SAPI ... SafetyProvider . Each SafetyProvider shall implement the SAPI as shown in Table 23 , however, the details are vendor-specific. Table 23 - SAPI of the SafetyProvider SAPI Term Type I/O Definition SafetyData
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

6.3.3.3 SPI of SafetyProvider

SafetyProvider [RQ6.13a] Each SafetyProvider shall implement the parameters and constants [RQ6.13b] as shown in Table 24 . The parameters (R/W in column "Access ... shown when appropriate. The values of the constants depend on the way the SafetyProvider is implemented. They never change and are therefore not writable via any of the interfaces. Table
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

6.3.4.2 SAPI of SafetyConsumer

Definition SafetyData Structure O This output either delivers the process values received from the SafetyProvider in the SPDU field SafetyData , or FSV . NonSafetyData Structure O This output delivers ... SafetyData to "0"1 and stop sending requests to the SafetyProvider . When changing Enable to "1" the SafetyConsumer will restart safe communication. The variable
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

6.3.4.4 SPI of the SafetyConsumer

Access Note SafetyProviderIDConfigured UInt32 0x0 to 0xFFFFFFFF 0x0 R/W The default SafetyProviderID of the SafetyProvider this SafetyConsumer uses to make a connection, see Figure 8 and 3.1.2.15 . For dynamic systems ... with sixteen octets. All sixteen octets are 0x0 R/W The default SafetyBaseID of the SafetyProvider this SafetyConsumer uses to make a connection, see 3.1.2.14 . For dynamic systems, the safety application
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

6.3.6 Principle for "application variables with qualifier"

Principle for "application variables with qualifier" Qualifiers allow the SafetyProvider to indicate the correctness of values on a fine-grained level. It is good practice to attach qualifiers
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

6.4.2 Diagnostics messages of the SafetyConsumer

SafetyConsumer has switched to fail-safe substitute values at the request of the SafetyProvider . Operator acknowledgment is required.5 0x20 F Yes 1 An offset of 0x10 or larger indicates
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

6.4.3 Method ReadSafetyDiagnostics of the SafetyProvider

Method ReadSafetyDiagnostics of the SafetyProvider This Method (as part of the OPC UA Mapper ) serves as a Diagnostic Interface and exists for each SafetyProvider . For time series observation, this interface
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

7.2.1.1 General

RequestSPDU Figure 12 shows the structure of a ResponseSPDU which originates at the SafetyProvider and contains the SafetyData (1 to 1 500 octets), an additional 25 octet safety code ( STrailer ... transmitted in an atomic (consistent) way from the OPC UA Platform Interface of the SafetyProvider to the OPC UA Platform Interface of the SafetyConsumer . This is the task
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

7.2.1.5 ResponseSPDU: SafetyData

ResponseSPDU: SafetyData [RQ7.2] SafetyData shall contain the safety-related application data transmitted from the SafetyProvider to the SafetyConsumer . It is comprised of a single or multiple basic OPC UA Variables ... signature, the order in which this data is processed by the calculation is important. SafetyProvider and SafetyConsumer shall agree upon the number, type and order of application data transmitted
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

7.2.1.6 ResponseSPDU: Flags

ResponseSPDU: Flags [RQ7.3] The flags of the SafetyProvider ( ResponseSPDU.Flags ) shall be used as shown in 6.2.3.2 . [RQ7.4] Flags in the ResponseSPDU.Flags which are reserved for future use shall ... zero by the SafetyProvider and shall not be evaluated by the SafetyConsumer
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

7.2.1.7 ResponseSPDU: SPDU_ID

used by the SafetyConsumer to check whether the ResponseSPDU is coming from the correct SafetyProvider . For details
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

7.2.1.10 ResponseSPDU: CRC

used to detect data corruption. See 7.2.3.6 on how it is calculated in the SafetyProvider and how it is checked in the SafetyConsumer
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

7.2.2.1 General

General The two SCL services SafetyProvider and SafetyConsumer are specified using state diagrams
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

7.2.2.2 SafetyProvider and SafetyConsumer Sequence diagram

SafetyProvider and SafetyConsumer Sequence diagram Figure 13 and Figure 14 show sequences of requests and responses with SafetyData for this document using OPC UA Client/Server and PubSub communication mechanisms, respectively ... case of Client/Server communication, a SafetyConsumer 's OPC UA Mapper may call a SafetyProvider (either the state machine implementation itself or the SafetyProvider 's OPC UA Mapper ) with an identical
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

7.2.2.3 Duration of demand

given SafetyData (e.g. a safety demand or a command value) that originates in the SafetyProvider 's safety application is being received by a SafetyConsumer and forwarded to the SafetyConsumer ... shall be considered. In case A, repeated identical RequestSPDUs are being answered by the SafetyProvider with ResponseSPDUs which contain the initially returned value. This is the case for PubSub communication
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

7.2.2.4 SafetyProvider state diagram

SafetyProvider state diagram [RQ7.13] Figure 17 shows a simplified representation of the state diagram of the SafetyProvider . The exact behaviour is described in Table 30 , Table 31 , and Table ... SafetyProvider shall implement that behaviour. It is not required to literally follow the entries given in the tables, if the externally observable behaviour does not change. Figure 17 - Simplified representation
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

7.2.2.5 SafetyConsumer state diagram

recommended that a SafetyConsumer is started after an OPC UA connection to a running SafetyProvider has been established, or that the setting of input SAPI.Enable ... delayed until the SafetyProvider is running. Figure 18 - Principle state diagram for SafetyConsumer Table 33 shows the internal items of a SafetyConsumer . A macro is a shorthand representation for operations
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

7.2.3.1 Build ResponseSPDU

Build ResponseSPDU [RQ7.15] The ResponseSPDU shall be built by the SafetyProvider by copying RequestSPDU.MonitoringNumber and RequestSPDU.SafetyConsumerID into the ResponseSPDU . In addition, SPDU_ID , Flags , the SafetyData and the NonSafetyData shall ... overview over the task of building the ResponseSPDU . Figure 20 - Overview of task for SafetyProvider For the ResponseSPDU.Flags , see 7.2.1.6 . For the calculation of the SPDU
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

7.2.3.4 Coding of the SafetyProviderLevel_ID

Coding of the SafetyProviderLevel_ID The SafetyProviderLevel is the SIL the SafetyProvider implementation (hardware and software) is capable of. Table 37 - Coding for the SafetyProviderLevel_ID SafetyProviderLevel Value of SafetyProviderLevel ... maximal (hamming distance of 21). [RQ7.18] Measures shall be taken to avoid that a SafetyProvider is erroneously using a code value belonging to a SIL that is higher than
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

7.2.3.5 Signature over the SafetyData Structure (SafetyStructureSignature)

data transmitted in SafetyData . If the SafetyConsumer is expecting anything different than what the SafetyProvider actually provides, SafetyStructureSignature will differ, allowing the SafetyConsumer to enable fail-safe substitute values ... DataType ( SafetyStructureIdentifier ) is also taken into account when calculating SafetyStructureSignature . This ensures that the SafetyProvider and the SafetyConsumer are using the same identifier for the Structure DataType , effectively avoiding
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

7.2.3.6 Calculation of a CRC signature

Calculation of a CRC signature The SafetyProvider calculates the CRC signature ( ResponseSPDU.CRC ) and sends it to the SafetyConsumer as part of the ResponseSPDU . This enables the SafetyConsumer to check ... octets (16 octets STrailer without CRC , 12 octets of SafetyData ). The calculation of ResponseSPDU.CRC ( SafetyProvider ) or CRC_calc ( SafetyConsumer ) is done in reverse order, from bottom
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

8.2 Safety function response time part of communication

Safety. The overall SFRT also depends on the implementation of the devices the SafetyProvider and SafetyConsumer are running on. Details on how these fractions of the SFRT are calculated ... sends a RequestSPDU . At about the same time, a dangerous event occurs at the SafetyProvider , demanding the safety function to trigger. However, in the worst case, the RequestSPDU is processed
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

9.1.2 SafetyConsumerID

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
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

9.2 Initialization of the MNR in the SafetyConsumer

SafetyConsumer The MNR is used to discriminate messages stemming from the same SafetyProvider and is therefore used to detect timeliness errors such as outdated messages, messages received out-of-order
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

10.3 Index of requirements (informative)

RQ6.11 Values for Boolean DataType 6.2.5 DataTypes and length of SafetyData RQ6.12 Implementation of SafetyProvider SAPI 6.3.3.2 SAPI of SafetyProvider RQ6.13a Implementation of SafetyProvider SPI 6.3.3.3 SPI of SafetyProvider RQ6.13b ... Parameters of SafetyProvider SPI 6.3.3.3 SPI of SafetyProvider RQ6.14 Implementation of SafetyConsumer SAPI 6.3.4.2 SAPI of SafetyConsumer RQ6.15a Implementation of SafetyConsumer SPI 6.3.4.4 SPI of the SafetyConsumer RQ6.15b Parameters
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

B.2.1 Unidirectional communication

Figure B.1 ). Figure B.1 - Unidirectional communication This is accomplished by placing a SafetyProvider on Controller A and a SafetyConsumer on Controller B. The connection between SafetyProvider and SafetyConsumer ... established and terminated during runtime, allowing different consumers to connect to the same SafetyProvider at different times. Furthermore, the protocol is designed in such a way, that it is necessary
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

B.2.2 Bidirectional communication

means the exchange of data in both directions, which is accomplished by placing a SafetyProvider and a SafetyConsumer on each controller. Hence, bidirectional communication is realized using two safety connections
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

B.2.3 Safety Multicast

this document is designed in such a way that: the state machine of the SafetyProvider has a low number of states, and thus very low memory demands, all safety-related ... message-checks are executed on the consumer and thus the computational demand on the SafetyProvider is low. Therefore, even if many SafetyProviders are instantiated on a device, the performance requirements
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

B.3.1 Explanation

B.3.1 Explanation This document supports operator acknowledgment both on the SafetyProvider side and on the SafetyConsumer side. For this purpose, both the interface of the SafetyProvider and the SafetyConsumer comprise
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

B.3.2 Use case 1: unidirectional communication and OA on the SafetyConsumer side

Figure B.4 , operator acknowledgment is done on the SafetyConsumer side, operator acknowledgment on the SafetyProvider side is not possible
OPC-10000-81 – OPC Unified Architecture - Part 81: UAFX Connecting Devices and Information Model

C.1 OPC UA Safety Information Model

PubSub is assumed for the following text. As defined in OPC 10000-15 , the SafetyProvider (representing the source for safety data, such as an emergency stop button) exposes: a structured ... exposes: a structured input Variable of a DataType derived from the ResponseSPDUDataType . Note that SafetyProvider and SafetyConsumer have identical definitions of this DataType ; a structured output Variable of DataType RequestSPDUDataType
OPC-10000-81 – OPC Unified Architecture - Part 81: UAFX Connecting Devices and Information Model

C.2 Usage of OPC UA safety Variables in a FunctionalEntity

safety Variables in a FunctionalEntity Figure C.2 indicates a FunctionalEntity, which includes a SafetyProvider . The FunctionalEntity contains safety and non-safety Variables in its InputData and OutputData . Figure C.2 - FunctionalEntity ... addition, these Variables are referenced by HasComponent References from the SafetyPDUs Object of the SafetyProvider (see also OPC 10000-15 ). Safety and non-safety data can be referenced
OPC-10000-81 – OPC Unified Architecture - Part 81: UAFX Connecting Devices and Information Model

C.3 Usage of OPC UA safety Variables in Connections

Safety provides an application protocol using safety Variables , which is implemented by the SafetyProvider / SafetyConsumer . The communication layer is completely unaware that safety data is being transported. Any logical connection ... dotted lines. The logical connection contains the unidirectional safety data exchange between the SafetyProvider on Controller A and the SafetyConsumer on Controller B (CtrBRequest à CtrARequest, CtrAResponse à CtrBResponse
OPC-10000-84 – OPC Unified Architecture - Part 84: UAFX Profiles

6.6.4.11 UAFX Controller Safety Facet

includes the functionality needed for a UAFX Controller to exchange safety-related data. Both SafetyProvider and SafetyConsumer functionality are provided. Table 50 - UAFX Controller Safety Facet Group Conformance Unit / Profile ... Title Optional SafetyProvider Facet SafetyConsumer Facet SafetyProviderPubSubMapper Facet SafetyConsumerPubSubMapper Facet