Search

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

16 result(s) for SafetyConsumers

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

5.4 Safety communication layer structure

single clock in the SafetyConsumer , thus eliminating the necessity for synchronized clocks. When SafetyConsumers connect to SafetyProviders , they have prior expectations regarding the pair of SafetyProviderID and SafetyBaseID ... safety applications to exchange SafetyData in both directions, two pairs of SafetyProviders and SafetyConsumers shall be established, one pair for each direction. The OPC UA Mapper implements the parts
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

6.2.1 General

purposes: support of the safe exchange of SPDUs at runtime online browsing, to identify SafetyConsumers and SafetyProviders , and to check their parameters for diagnostic purposes offline engineering: the Information Model
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

6.2.2.1 SafetyACSet Object

with a fixed NodeID in the Namespace of this document. Because all SafetyProviders and SafetyConsumers on this Server contain a hierarchical Reference from this Object to themselves ... used to directly access all SafetyProviders and SafetyConsumers . SafetyACSet is intended for safety-related purposes only. It should not reference non-safety -related items. See Table 3 for the definition
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

6.2.2.3 Method ReadSafetyData

responsibility of the safety application that this Method is not concurrently called by multiple SafetyConsumers . Otherwise, the SafetyConsumer can receive invalid responses resulting in a safe reaction which can lead
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

6.2.2.6 Objects SafetyProviderParameters and SafetyConsumerParameters

viable optimization that a Property SafetyBaseIDConfigured is referenced by either multiple SafetyProviders or SafetyConsumers , or both. For releases up to Release 2.0 of the document, the value for the SafetyStructureSignatureVersion
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

6.2.4 SafetyProvider version

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.3 SPI of SafetyProvider

SAPI are 0x0, this means that the SafetyProvider is not properly configured. SafetyConsumers will never try to communicate with SafetyProviders having a SafetyProviderID of 0x0, see Transitions T13/T27 in Table ... SAPI are 0x0, this means that the SafetyProvider is not properly configured. SafetyConsumers will never try to communicate with SafetyProviders having a SafetyBaseID of 0x0, see Transitions T13/T27 in Table
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

7.2.2.4 SafetyProvider state diagram

requests even if it is incorrectly configured (e.g. its SafetyProviderID is zero). However, SafetyConsumers will never try to communicate with SafetyProviders having incorrect parameters, see Transitions
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

9.1.2 SafetyConsumerID

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

9.4 PFH and PFD values of a logical safety communication link

effect on the PFH and PFD values of the components the SafetyProviders and SafetyConsumers are running on. The requirements for the implementation of these components are specified
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

9.5 Safety manual

safety manual shall address how this can be accomplished. 6 Operator acknowledgment If the SafetyConsumers makes a transition to fail-safe substitute values requiring operator acknowledgment "frequently", this
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

9.6 Indicators and displays

whenever the output SAPI.OperatorAckRequested is true of at least one of the SafetyConsumers running on the device. This LED may also be used for other purposes. For instance, normal operation
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

10.3 Index of requirements (informative)

calculation RQ6.1 Singleton SafetyACSet Folder 6.2.2.1 SafetyACSet Object RQ6.2 Objects for SafetyProviders and SafetyConsumers 6.2.2.1 SafetyACSet Object RQ6.3a Usage of Call Service for Client/Server 6.2.2.1 SafetyACSet Object RQ6.3b Usage
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

B.2.1 Unidirectional communication

only, it is not necessary for the SafetyProvider to check the ID of the SafetyConsumers . Hence, Controller A can - one after another - serve an arbitrarily large number of SafetyConsumers ... SafetyConsumers can be introduced into the system without having to update Controller
OPC-10000-15 – OPC Unified Architecture - Part 15: Safety

B.2.3 Safety Multicast

Each of the SafetyProviders running on Controller A is connecting to one of the SafetyConsumers running on one of the Controllers B1, B2, … BN. See Figure B.3 for an example ... multicast; different sets of consumers can connect to SafetyProviders at different times, and new SafetyConsumers can be introduced into the system without having to reconfigure the SafetyProvider instances
OPC-10000-81 – OPC Unified Architecture - Part 81: UAFX Connecting Devices and Information Model

C.3 Usage of OPC UA safety Variables in Connections

reference any number of safety and non-safety Variables , even from different SafetyProviders or SafetyConsumers . There is nothing special in establishing a connection containing safety Variables . In fact, the connection