Search

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

68 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