Search

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

104 result(s) for devices

OPC-10000-12 – OPC Unified Architecture - Part 12: Discovery and Global Services

7.1 Overview

required. OPC 10000-21 defines the complete process to automatically authenticate and onboard new Devices that depends on the Devices having support built in by the Manufacturer . If this support ... present, Devices and OPC UA Applications shall be manually onboarded using the mechanisms defined in this document. During manual onboarding, the CertificateManager shall be able to operate in a mode
OPC-10000-12 – OPC Unified Architecture - Part 12: Discovery and Global Services

7.5 Application Setup

PushManagement and PullManagement are also integrated into OPC 10000-21 which specifies how new Devices can be authenticated when they are added to the network. Once a Device is authenticated ... used to issue Certificates to Applications used by their field technicians. For embedded devices, the Server should allow any Client that provides the proper SecurityAdmin credentials to create the secure
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

1 Scope

Scope This part defines the life cycle of Devices and Composites and mechanisms to verify their authenticity, set up their security and maintain their configuration
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

3.1.3 Composite

Composite a collection of Devices or Composites assembled into a single unit. Note 1 to entry: Each Composite has a globally unique identifier. Note 2 to entry: A Composite ... connected to a network. Note 3 to entry: A Composite may appear as multiple Devices when connected to a network
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

3.1.11 Distributor

Distributor an organization that re-sells Devices and/or Composites. Note 1 to entry: A Distributor may enhance Devices and Composites by adding customized products or services
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

3.1.13 OwnerOperator

OwnerOperator an organization deploying and operating a system that comprises of Devices , Composites or other computers connected via a network
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

3.1.16 Registrar

Registrar an OPC UA Application that registers and authenticates Devices added to the network
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

3.1.17 SystemIntegrator

organization that installs and configures a system for an OwnerOperator that comprises of Devices , Composites or other computers connected via a network
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

4.1 Device Lifecycle

Device from manufacture to decommissioning. The entire lifecycle approach is needed because Devices , unlike PC-class computers, are often shipped with automation software pre-installed and are connected directly ... sensitive networks. This requires a process to authenticate Devices before they are given access to a sensitive network. The complete life cycle of a Device is shown in Figure
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

4.2.1 Secure Elements

Device authentication depend on PrivateKeys that are stored in SecureElements . PrivateKeys stored on Devices without SecureElements can be stolen and reused on counterfeit Devices . OwnerOperators may provision Devices without SecureElements
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

4.2.3 Transfer of Physical Control

Transfer of Physical Control Implicit in the Device lifecycle is the notion that Devices and Composites will be physically delivered to different actors. The transfers of physical control that
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

4.2.4 Trust on First Use (TOFU)

TOFU) The onboarding process defined in this document describes how an OwnerOperator can authenticate Devices added to the network. This document does not define any mechanisms to allow Devices ... credentials that authorize Applications that are allowed to make changes to its security configuration. Devices should have a mechanism to return the DCA to an initial state which discards
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

4.2.5 SoftwareUpdateManager

important part of the onboarding process because it is necessary to ensure that Devices with out-of-date firmware are not allowed on the network. The interactions between the SoftwareUpdateManager ... present in systems where the OwnerOperator has other mechanisms in place to ensure the Devices have up to date firmware
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

4.2.6 Roles and Privileges

restrictions can be expressed simply by granting Role permissions on Nodes . For example, authenticated Devices are granted the ability to update only their own information which means the decision ... RegistrarAdmin The Role grants rights to manage the Tickets known the Registrar and approve Devices when automatic authentication was not possible. SoftwareUpdateAdmin The Role grants rights to set the software
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

4.3.1 Distribution

Distribution Distribution is the process of transferring physical control of Devices and Composites from one organization to another. This transfer of physical control is accompanied by the electronic transfer
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

4.3.4 Configuration

replacement for an existing Device that is no longer functioning. Some Devices may allow individual Applications to be configured while other Applications continue in Operation state described
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

4.3.5 Operation

Instance Certificate using the CertificateManager PushManagement or PullManagement described in OPC 10000-12 . Some Devices may allow the Application configuration to be changed while in this stage
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

5.1 Device Identity

installing, securing and revoking the IDevID and LDevID Certificates depend on the Manufacturer , however, Devices should provide a SecureElement storage (for an example, see ISO/IEC 11889 ) to ensure the associated ... cautious and develop strategies to protect against risks created by these unverifiable Devices . Manufacturers should develop strategies to ensure these Certificates are verifiable for the expected lifetime of the Device
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

5.3 Composite Identity

Composite Identity A Composite is a piece of equipment that contains a network of Devices . All of these Devices are internal to the Composite and can be accessed by other ... Devices within the Composite . Some of these Devices are also visible on an external network and have one or more Applications that need to be provisioned. Composites are an abstraction
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

6.1 Tickets

Ticket is the term used for a document that describes one or more Devices and has a Digital Signature that can be used to verify that the contents ... authority it trusts. For example, a CompositeBuilder re-signs the Tickets for the Devices to associate the CompositeInstanceUri with the Device Ticket (see 8.1 ). Customers of the CompositeBuilder will
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

6.2 Ticket Distribution

Ticket Distribution When physical control over Devices and/or Composites is transferred from one organization to another there needs to be a physical transfer of goods and an electronic transfer ... Tickets associated with the Devices and Composites . The Tickets allow the new user to verify the authenticity of the Devices and Composites they received by using the handshake defined
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

6.3 Authentication

Authentication When a CompositeBuilder or Integrator receives a shipment of Devices it needs to connect them to their network and verify their authenticity. This process is automated ... Registrar that detects new Devices added to the network, inspects their DeviceIdentity Certificates and finds the corresponding DeviceIdentityTicket . If a match was found the Device is accepted
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

6.4 Acquiring and Validating Tickets

rely on an out-of-band mechanism which provides the Tickets for the Devices and Composites that will be delivered to the facility before the Devices are connected
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

7.1 Overview

Overview Registrars shall not accept Devices they do not trust. The steps to determine trust are: Read all DeviceIdentity Certificates from the Device ; Locate a Ticket that has a ProductInstanceUri
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

7.2 Pull Management

shall not attempt to connect to Registrars that are not in the TrustList . Devices that support pull management shall have a way for a person with physical access
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

7.3 Push Management

Registrars since the DCA always trusts the first Registrar that provides a Certificate . Some Devices with limited resources may only support a single Server which acts as both
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

8.1 Signed Ticket Encoding

supply chain. For example, a CompositeBuilder shall add Signatures to all Tickets for Devices incorporated into the Composite. The protected header shall have the CompositeInstanceUri . The Certificate and algorithms used
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

8.2.4 CompositeIdentityTicketType

ProductInstanceUri assigned to the Composite. This value appears in LDevID Certificates assigned to Devices by the CompositeBuilder (see 5.3 ). devices 0:UriString [] A list of ProductInstanceUris for the Devices
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

8.2.6 CertificateAuthorityType

CertificateAuthorityType The CertificateAuthorityType describes a Certificate Authority (CA) used to issue Certificates to Devices , Composites or to organizations that create Tickets . The fields of this DataType are defined in Table
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

9.2.1 Overview

that implements the Information Model shown in Figure 10 . This Information Model allows new Devices to use pull management described in 7.2 to authenticate themselves. It also allows Endpoints ... Devices to be manually registered for PushManagement when no multicast discovery mechanism is available. Figure 10 - Registrar Address Space for Onboarding Workflow
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

9.2.2 DeviceRegistrarType

DeviceRegistrarType O bjectType represents an entity that provides the services needed when authenticating Devices on a network. The ObjectType is defined in Table 17 . Table 17 - DeviceRegistrarType Definition Attribute Value ... task register the Device using PullManagement . If an administration Client needs to register many Devices it can call the RegisterDeviceEndpoint Method multiple times in a single Call request. The GetManagers
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

9.2.6 GetManagers

location of other managers on a network which are needed to support onboarding of Devices . The managers have network Endpoints that may support non-OPC UA protocols
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

9.2.10 DeviceRegistrarAdminType

interface to manage the TrustLists and Tickets used by the Registrar when authenticating Devices on a network. The ObjectType is defined in Table 26 Table 26 - DeviceRegistrarAdminType Definition Attribute Value ... RegisterTickets Method allows an administration Client to provide a list of Tickets for Devices and Composites that it is expecting to install on the network. Any Device which matches
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

9.2.11 RegisterTickets

RegisterTickets Method allows an administration Client to provide a list of Tickets for Devices and Composites that it is expecting to install on the network. Any Device which
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

9.2.12 UnregisterTickets

UnregisterTickets The UnregisterTickets Method allows a RegistrarAdmin to remove Tickets for Devices and Composites that it previously provided. Removing Tickets does not affect Devices that were previously accepted using
OPC-10000-21 – OPC Unified Architecture - Part 21: Device Onboarding

9.3.1 Overview

Overview Devices that support PushManagement described in 7.3 have a Server that implements the Information Model shown in Figure 11 . This Information Model allows Registrars to authenticate Devices
OPC-10000-80 – OPC Unified Architecture - Part 80: UAFX Overview and Concepts

3.1.8 Controller-to-Device

Controller-to-Device interaction model involving Controllers exchanging data with devices
OPC-10000-80 – OPC Unified Architecture - Part 80: UAFX Overview and Concepts

3.1.11 Device-to-Compute

Device-to-Compute interaction model involving devices exchanging data with Computes
OPC-10000-80 – OPC Unified Architecture - Part 80: UAFX Overview and Concepts

3.1.12 Device-to-Device

Device-to-Device interaction model involving devices exchanging data with one another
OPC-10000-80 – OPC Unified Architecture - Part 80: UAFX Overview and Concepts

5.1 Motivation

Motivation Today's automation devices use a wide variety of different fieldbus systems and real-time Ethernet protocols to communicate on the control and field level. Although most of these ... fieldbus systems and real-time Ethernet protocols are standardised by IEC (61158/61784 series), many devices are not interoperable with each other. Many of these protocols support different network infrastructures. However
OPC-10000-80 – OPC Unified Architecture - Part 80: UAFX Overview and Concepts

5.2 The UAFX Solution

manufacturing and process industries, providing vendor-independent end-to-end interoperability of field-level devices for all relevant industrial automation use cases. Figure 2 - OPC UA FX connectivity use cases
OPC-10000-80 – OPC Unified Architecture - Part 80: UAFX Overview and Concepts

5.3 Interaction Model

represents a control automation component typically implemented in a PLC or DCS controller. Today, Devices may be connected to Controllers and can be as simple as an inductive proximity switch ... complex as a Coriolis flowmeter or servo drive. In the future, Devices may communicate directly with Compute application, eliminating the overhead of a Controller acting as an intermediary. Compute
OPC-10000-80 – OPC Unified Architecture - Part 80: UAFX Overview and Concepts

5.4.2.2 Controls Engineer

equipment. In support of this function, they are typically responsible for integrating automation devices into the controller engineering tools and parameterising those devices with all information necessary for their correct
OPC-10000-80 – OPC Unified Architecture - Part 80: UAFX Overview and Concepts

5.4.3 Application engineering

Controller B while separated in time and space and potentially without the physical devices . Using Controller A's engineering tool, Engineer A creates the User Program for Controller
OPC-10000-82 – OPC Unified Architecture - Part 82: UAFX Networking

3.1.3 device

interfaces Note 1 to entry: See IEC 61499-1. Note 2 to entry: Devices provide sensing, actuating, communication, and/or control functionality. Examples include transmitters, valve controllers, drives, motor controllers, PLCs ... gateways. Note 3 to entry: A Device can be a system (topology) of other Devices , components, or parts
OPC-10000-84 – OPC Unified Architecture - Part 84: UAFX Profiles

5.1 Overview

Table 2 - ConformanceGroups Group Description UAFX Base Defines ConformanceUnits for all UAFX Controllers and devices . UAFX AutomationComponent Defines ConformanceUnits for various features of AutomationComponents . UAFX FxAsset Defines ConformanceUnits for various
OPC-10000-100 – OPC Unified Architecture - Part 100: Devices

1 Scope

overall OPC Unified Architecture specification series and defines the information model associated with Devices . This specification describes three models which build upon each other as follows: The (base) Device Model ... intended to provide a unified view of devices and their hardware and software parts irrespective of the underlying device protocols. The Device Communication Model adds Network and Connection information elements
OPC-10000-100 – OPC Unified Architecture - Part 100: Devices

3.1.3 Communication Profile

Communication Profile fixed set of mapping rules to allow unambiguous interoperability between Devices or Applications, respectively Note 1 to entry: Examples of such profiles are the "Wireless communication network
OPC-10000-100 – OPC Unified Architecture - Part 100: Devices

3.1.5 Device

interfaces Note 1 to entry: See IEC 61499-1. Note 2 to entry: Devices provide sensing, actuating, communication, and/or control functionality. Examples include transmitters, valve controllers, drives, motor controllers, PLCs ... gateways. Note 3 to entry: A Device can be a system (topology) of other Devices , components, or parts
OPC-10000-100 – OPC Unified Architecture - Part 100: Devices

3.1.6 Device Integration Host

Device Integration Host Server that manages integration of multiple Devices in an automation system
OPC-10000-100 – OPC Unified Architecture - Part 100: Devices

3.1.7 Device Topology

Device Topology arrangement of Networks and Devices that constitute a communication topology
OPC-10000-100 – OPC Unified Architecture - Part 100: Devices

3.1.15 Software Update Client

Software Update Client update client that can be used for Devices of several vendors Note 1 to entry: There can be different Software Update Clients for different domains (e.g. process
OPC-10000-100 – OPC Unified Architecture - Part 100: Devices

4.1 General

Device where parts include mechanics and/or software. DeviceType is commonly used to represent field Devices . Modular Devices are introduced to support subdevices and Block Devices to support Blocks . Blocks ... this type will be added to the head object of the modular unit. Modular Devices , for example, will use this ObjectType to organize their modules. Block -oriented Device
OPC-10000-100 – OPC Unified Architecture - Part 100: Devices

4.5.5 OperationCounter Interface

Device has been powered and performing an activity. This counter is intended for Devices where a distinction is made between switched on and in operation. For example, a drive ... powered on but not operating. It is not intended for Devices always performing an activity like sensors always measuring data. This value shall only increase during the lifetime
OPC-10000-100 – OPC Unified Architecture - Part 100: Devices

4.5.6 SupportInfo Interface

SupportInfo Interface defines a number of additional data that a commonly exposed for Devices and their components. These include mainly images, documents, or protocol-specific data. The various types
OPC-10000-100 – OPC Unified Architecture - Part 100: Devices

4.7 DeviceType

compatibility. Although mandatory, some of the Properties are not supported for certain types of Devices . In this case vendors shall provide the following defaults: Properties with DataType String : empty string
OPC-10000-100 – OPC Unified Architecture - Part 100: Devices

4.9 DeviceSet entry point

DeviceSet entry point The DeviceSet Object is the starting point to locate Devices . It shall either directly or indirectly reference all instances of a subtype of ComponentType with a Hierarchical ... Reference . For complex Devices that are composed of various components that are also Devices , only the root instance shall be referenced from the DeviceSet Object . The components of such complex
OPC-10000-100 – OPC Unified Architecture - Part 100: Devices

4.10 DeviceFeatures entry point

Object can be used to organize other functional entities that are related to the Devices referenced by the DeviceSet . Companion specifications can standardize such instances and their BrowseNames . Figure
OPC-10000-100 – OPC Unified Architecture - Part 100: Devices

5.3 Network

logical representation of wired and wireless technologies and represents the communication means for Devices that are connected to it. A Network instance is qualified by its Communication Profile components. Figure ... InitLock is requested for a Network , it will be rejected if any of the Devices connected to this Network or any sub-ordinate Network including their connected Devices is already
OPC-10000-100 – OPC Unified Architecture - Part 100: Devices

5.4 ConnectionPoint

subtype of ComponentType . To allow navigation from a Network to the connected Devices , the ConnectionPoints shall have the inverse Reference (ComponentOf) to the Device . ConnectionPoints have Properties and other components ... implies that this ConnectionPoint can be used to connect Networks and Devices of the same Communication Profile . ConnectionPoints are between a Network and a Device . The location in the topology
OPC-10000-100 – OPC Unified Architecture - Part 100: Devices

5.5 ConnectsTo and ConnectsToParent ReferenceTypes

natural for this Reference . The ConnectsTo Reference exists between a Network and the connected Devices (or their ConnectionPoint , respectively). Browsing a Network returns the connected Devices ; browsing from a Device ... used to express topological relationships and parental relationships. In this example two Devices are connected; the module DPcomm is the communication Device for the Network . Figure 24 - Example with ConnectsTo
OPC-10000-100 – OPC Unified Architecture - Part 100: Devices

6.1 General

General A Device Integration Host is a Server that manages integration of multiple Devices in an automation system and provides Clients with access to information about Devices regardless of where ... Model is to reflect the topology of the automation system. Therefore, it represents the Devices of the automation system as well as the connecting communication networks including their properties, relationships
OPC-10000-100 – OPC Unified Architecture - Part 100: Devices

6.2 DeviceTopology Object

DeviceTopology Object The Device Topology reflects the communication topology of the Devices . It includes Devices and the Networks. The entry point DeviceTopology is the starting point within the AddressSpace ... used to organize the communication Devices for the top-level Networks that provide access to all instances that constitute the Device Topology ((sub-)networks, devices and communication elements). The DeviceTopology
OPC-10000-100 – OPC Unified Architecture - Part 100: Devices

6.3.1 General

Device Topology is a configuration task, i.e., the elements in the topology ( Devices , Networks , and Connection Points ) are usually configured "offline" and - at a later time - will
OPC-10000-100 – OPC Unified Architecture - Part 100: Devices

8.3.1 System perspective

System perspective Besides specific Clients for specific devices, this specification also describes Software Update Clients that can update devices of various vendors (for additional details see 8.3.5 ). For Devices ... performed manually by a user for a single device. However, if a lot of devices are maintained on a regular basis an automatic update is desirable. For this scenario
OPC-10000-100 – OPC Unified Architecture - Part 100: Devices

8.3.4.4 Cached-Loading option

loading option is the preferred option for best interoperability between Software Update Clients and Devices . For Cached-Loading the CachedLoadingType is used, which is described
OPC-10000-100 – OPC Unified Architecture - Part 100: Devices

9.1 General

General This section defines specialized types that are commonly used for Field Devices . It makes use of the ConfigurableObjectType as a way to add functionality using composition
OPC-10000-100 – OPC Unified Architecture - Part 100: Devices

9.3 Block Devices

Block Devices A Block -oriented Device can be composed using the modelling elements defined in this specification. A Block -oriented Device includes a configurable set of Blocks . Figure 58 shows ... general structure of Block -oriented Devices . Figure 58 - Block-oriented Device structure example An Object called Blocks is used as a container for the actual BlockType instances
OPC-30000 – OPC UA for Programmable Logic Controllers based on IEC61131-3

4.2.3.4 Introduction to OPC UA Devices

Introduction to OPC UA Devices The OPC 10000-100 specification is an extension of the overall OPC Unified Architecture specification series and defines the information model associated with Devices ... model is intended to provide a unified view of Devices irrespective of the underlying Device protocols. Controllers are physical or logical Devices and the Devices model is therefore used
OPC-30010 – OPC UA for AutoId Devices - AutoID: OPC UA for AutoId Devices

10.2 OPC UA Conformance Units and Profiles

facet for the base functionality necessary for a synchronous scan operation with AutoID Devices by pure Data Access functionality, where the OPC UA Client optional can trigger the scan operation ... facet for the base functionality necessary for a synchronous scan operation with AutoID Devices where the OPC UA Client triggers the scan operation. Table 83 - Base Sync AutoID Server Facet
OPC-30100 – OPC UA for SERCOS Devices

4.2 OPC UA

main use case for OPC standards is the online data exchange between devices and HMI or SCADA systems using Data Access functionality. In this use case the device data ... independence of the protocols, OPC UA servers and clients can be directly integrated into devices and controllers. The OPC UA Information Model provides a standard way for Servers to expose
OPC-30100 – OPC UA for SERCOS Devices

5.4 DeviceSet Entry Point

Entry Point To promote interoperability of Client s and Server s, all instantiated Sercos devices shall be aggregated in an Object called "DeviceSet". For composed Sercos devices ... various components that are also Sercos devices ), every Sercos device shall be referenced from the DeviceSet Object . The standard entry point for OPC UA devices is defined
OPC-30142 – OPC UA for PROFINET Remote IO

3.2.2 Device

Device A Device is a stand-alone unit exchanging cyclic data with a Controller . Devices are usually configured by the Controller and may also generate acyclic data like alarms
OPC-30142 – OPC UA for PROFINET Remote IO

5 Use cases

Channel Group Objects . Contribute data for Industrial Internet of Things Client applications present Devices , their properties, and their "live" data in an Industrial Internet of Things ecosystem. Support ... Client applications process a sequence of diagnosis related events and/or alarms found on the Devices to present a history of incidents to plant operators. Providing RioChannelDiagnosisEventType and/or RioChannelDiagnosisAlarmType Events . Server
OPC-30142 – OPC UA for PROFINET Remote IO

6.8.1.3 Classic Status

Classic Status For Devices generating classic status codes, OPC UA Servers shall set the status information delivered for one Process Value and the OPC UA StatusCode consistent as defined ... chapter 5.3.4.2.1, the classic status codes shall be supported for legacy Devices requiring backward compatibility only. Otherwise, only condensed status generation or condensed status with detailed information as defined
OPC-30142 – OPC UA for PROFINET Remote IO

7.2.2.1 RioPaAnalogInputChannelType

Variable of the channel contains the Value MANUAL. The optional Variable is used for Devices according to the PA V3 profile and maps to the "manual out value
OPC-30142 – OPC UA for PROFINET Remote IO

7.2.4.1 RioPaDigitalInputChannelType

Variable of the channel contains the Value MANUAL. The optional Variable is used for Devices according to the PA V3 profile and maps to the "manual out value
OPC-30143 – OPC UA for PROFINET Encoder - Part <mm>: <Part Name>

3.2.6 Process Data

Process Data For Devices , all data related to the control process (e.g. gain factor, state variables, …). The Process Data typically is mapped on parameters (access is with acyclic transmission
OPC-30144 – OPC UA for PROFINET GSD Generic Model - Part 30144: PROFINET GSD Generic Model

3.2.1 General Station Description (GSD)

General Station Description (GSD) is the definition of certain properties of PROFINET Devices which are of interest for engineering tools, such as IO Data , IO Channels , Parameters and Alarms
OPC-30144 – OPC UA for PROFINET GSD Generic Model - Part 30144: PROFINET GSD Generic Model

3.2.2 GSDML

escription M arkup L anguage is an XML-based description language for PROFINET Devices (see [ GSDML
OPC-30144 – OPC UA for PROFINET GSD Generic Model - Part 30144: PROFINET GSD Generic Model

3.2.5 IO Data

Data For Devices , all Input and Output Data (cyclic transmission
OPC-30144 – OPC UA for PROFINET GSD Generic Model - Part 30144: PROFINET GSD Generic Model

3.2.11 Device

Device A Device is a separate addressable unit exchanging IO Data with a Controller . Devices are usually configured by the Controller and may also generate acyclic data like Alarms
OPC-30144 – OPC UA for PROFINET GSD Generic Model - Part 30144: PROFINET GSD Generic Model

4.1 Introduction to PROFINET GSD Generic Model

Model is to define a specification how Servers can create an Information Model for Devices which have no application profile (API=0) and therefore also no OPC UA companion specification ... GSDML file (see [ GSDML ]). GSDML files are provided by the vendors of PROFINET Devices, and the primary usage is offering the information needed by engineering systems (TIA Portal
OPC-30144 – OPC UA for PROFINET GSD Generic Model - Part 30144: PROFINET GSD Generic Model

5 Use cases

Server with access to the related PROFINET domain provides the Information Model of PROFINET Devices . These Devices are typically profile-less but may also support an application profile. Main ... case is to support the PROFINET Devices which do not have an OPC UA Server on the Device itself and a firmware upgrade for OPC UA support
OPC-30144 – OPC UA for PROFINET GSD Generic Model - Part 30144: PROFINET GSD Generic Model

6.1 Information Model Creation

lays out a general procedure for the creation of a 'generic' Information Model for Devices the Server has access to by PROFINET means: The Server reads Vendor-ID and Device
OPC-30144 – OPC UA for PROFINET GSD Generic Model - Part 30144: PROFINET GSD Generic Model

6.10 Alarms

supporting the "Alarms" sub-aspect shall detect the Alarms generated by the Devices (using PROFINET access) and generate GsdGenAlarmEventType Events. The Events are available for Subscription directly
OPC-30144 – OPC UA for PROFINET GSD Generic Model - Part 30144: PROFINET GSD Generic Model

11.1 Conformance Units

structure (Module - Submodule - Channel ). Server PNGSDGM Parameter Server provides the Parameter data of the Devices in the Information Model . Server PNGSDGM IO Data Server provides the IO Data ... Devices in the Information Model . Server PNGSDGM Data Objects Server provides the vendor specific Data Objects yielded by vendor specific PROFINET data records. Server PNGSDGM BMP Access Server provides Data
OPC-30145 – OPC UA for PROFINET Drives - Part 30145: UA CS for PROFINET Drives

4.1.5 Drive Communication Model

Nevertheless, the OPC UA information model of this specification is not limited to PROFIdrive devices, because the mandatory parts of the information model are independent from PROFIdrive and quite common ... specification. Additional benefit for drives with PROFIdrive (using PROFINET or PROFIBUS) is, that brownfield Devices can be represented by an OPC UA Server in an edge or proxy Device (like
OPC-30145 – OPC UA for PROFINET Drives - Part 30145: UA CS for PROFINET Drives

10.2.2.2 PDRV Small Server Profile

Drives Server at least shall provide. Intended to be implemented by Servers on simple Devices . Table 51 - PDRV Small Server Profile Group Conformance Unit / Profile Title Mandatory / Optional Profile
OPC-30145 – OPC UA for PROFINET Drives - Part 30145: UA CS for PROFINET Drives

10.2.2.3 PDRV Standard Server Profile

Small Server Profile by adding Event generation. Intended be implemented by Servers on complex Devices like Drives or robots, but also on small Devices , Edge Devices and PLC's . Table
OPC-30145 – OPC UA for PROFINET Drives - Part 30145: UA CS for PROFINET Drives

10.2.2.4 PDRV Full Server Profile

Server Profile by adding Alarm generation. Intended to be implemented by Servers on Complex Devices , Edge Devices and PLC's . Table 53 - PDRV Full Server Profile Group Conformance Unit / Profile
OPC-30500-1 – OPC UA for Laboratory & Analytical Device Standard (LADS) - Part 1: Basics

5.2.1 Device and fleet management

Device and fleet management Description Devices typically come with a set of properties that identify them for discovery, management, and maintenance purposes. This set of properties is commonly summarized using ... possible to represent an individual Device as an OPC UA Server or aggregate multiple Devices into the same OPC UA Server . Therefore, an OPC UA Server can represent an arbitrary
OPC-30500-1 – OPC UA for Laboratory & Analytical Device Standard (LADS) - Part 1: Basics

6 LADS Information Model Overview

LADS Information Model Overview This Companion Specification is based on OPC 10000-100 (Devices), OPC 10000-110 (Asset Management Basics) and OPC 40001-1 ( OPC UA for Machinery ). These Companion ... Specifications create an entry point for Devices or machines in the AddressSpace . Instances of a LADSDeviceType shall either directly or indirectly referenced with a Hierarchical Reference to the DeviceSet
OPC-40082-1 – OPC UA interfaces for plastics and rubber machinery - Peripheral devices - Part 1: Temperature control devices

6.1 TCD_InterfaceType Definition

Table 1 . NOTE: To promote interoperability of Client s and Server s, all instantiated Devices shall be aggregated in an Object called "DeviceSet" (see OPC UA for Devices
OPC-40082-2 – OPC UA interfaces for plastics and rubber machinery - Peripheral devices - Part 2: Hot runner devices

6.1 HRD_InterfaceType Definition

Table 1 . NOTE: To promote interoperability of Client s and Server s, all instantiated Devices shall be aggregated in an Object called "DeviceSet" (see OPC UA for Devices
OPC-40082-3 – OPC UA interfaces for plastics and rubber machinery - Peripheral devices - Part 3: LSR Dosing Systems

6.1 LDS_InterfaceType Definition

Table 2 . NOTE: To promote interoperability of Client s and Server s, all instantiated Devices shall be aggregated in an Object called "DeviceSet" (see OPC UA for Devices
OPC-40400-1 – OPC UA for the Powertrain - Part 1: Asset Management

3.2 OPC UA for Powertrain terms

module consisting of, but not limited to, the BDM and extensions such as protection devices, transformers and auxiliaries, but excluding the motor and the sensors which are mechanically coupled ... suitable for switching motors on and off. Motor starter The combination of all the devices required to start and stop a motor in combination with suitable overload protection
OPC-40400-1 – OPC UA for the Powertrain - Part 1: Asset Management

4.2.1 What is OPC UA?

access data via generic commercial applications. The OPC UA model is scalable from small devices to ERP systems. OPC UA Servers process information locally and then provide that data
OPC-40400-1 – OPC UA for the Powertrain - Part 1: Asset Management

6.1 Powertrain

drive consists of inverter/drive and motor realizing closed loop position control by encoder feedback devices . An even more complex setup is to combine several motors to perform synchronized motion
OPC-40400-1 – OPC UA for the Powertrain - Part 1: Asset Management

6.2 Information Model Structure

which are not too fine granular but enable to represent the majority of existing devices by combining them. The level of granularity was chosen to be on basic component level ... Motor Components related AssetTypes Motor component related asset types contain the motor itself and devices which are mounted near the motor to measure actual data or affect the motion output
OPC-40400-1 – OPC UA for the Powertrain - Part 1: Asset Management

6.3 PtAssetType and Identification

Machinery OPC 10000-81 - Information Model and Connecting Devices The general assumption is that any VDMA Companion Specification shall be in line with the OPC 40001-1. So that this ... specification shall also be compliant to the OPC 10000-81 (Information Model & Connecting Devices ) specification, since the defined PtAssetType shall be usable by the OPC UA FX Motion specification
OPC-40400-1 – OPC UA for the Powertrain - Part 1: Asset Management

7.10.2.2 Object Description

Object Description TripClass provides the classification for thermal protective devices regarding the value of the maximum tripping time in seconds. The values of the MultiStateValueDiscreteType variable are defined in Table
OPC-40400-1 – OPC UA for the Powertrain - Part 1: Asset Management

7.10.3.2 Object Description

Object Description TripClass provides the classification for thermal protective devices regarding the value of the maximum tripping time in seconds. The values of the MultiStateValueDiscreteType variable are defined in Table
OPC-40400-1 – OPC UA for the Powertrain - Part 1: Asset Management

7.10.5.2 Object Description

Object Description TripClass provides the classification for thermal protective devices regarding the value of the maximum tripping time in seconds. The values of the MultiStateValueDiscreteType variable are defined in Table