®

FUNDAÇÃO
OPC Arquitetura unificada

Especificação

Parte 1: Visão geral e Conceitos

solte 1,04

22 nov 2017
OPC Unified Architecture, Part 1 ii solte 1,04

Especificação Indústria Especificação Comentários: Relatório ou vista errata:

Tipo: padrão http://www.opcfoundation.org/errat um

Título: OPC Arquitetura Encontro: 22 nov 2017

unificada

Parte 1: Visão geral e

Conceitos

Versão: solte 1,04 Programas: MS-Word

Fonte: OPC UA Parte 1 - Visão Geral e Conceitos
Solte 1,04 Specification.docx

Autor: OPC Foundation Status: Lançamento

solte 1,04 iii OPC Unified Architecture, Part 1

CONTEÚDO
Página

PREFÁCIO ................................................. .................................................. .................... v

ACORDO DE USO .................................................. .................................................. .... v Revisão 1,04 Destaques

.......................................... .................................................. ......... vii 1 Escopo .................................................

.................................................. ........................ 1

2 Documentos de referência ................................................ .................................................. 1 ..

3 Termos, definições e abreviaturas ............................................ ................................. 2

Convenções do documento ................................................ ......................................... 2

Termos e definições ............................................... ............................................ 2
Abreviaturas ................................................. .................................................. .... 6
4 Estrutura da série OPC UA ............................................ ......................................... 7

organização especificação ................................................ ..................................... 7

As peças de especificação do núcleo ............................................... ......................................... 7
partes tipo de acesso especificação .............................................. .............................. 8
As peças de especificação Utility ............................................... ........................................ 8
5 Visão geral................................................. .................................................. .................... 8

âmbito UA ................................................ .................................................. ........... 8

Geral ................................................. .................................................. ............. 9
objetivos do projeto ................................................ .................................................. ...... 9
modelos e serviços integrados .............................................. ............................ 11
modelo de segurança ................................................ ........................................ 11
modelo integrado AddressSpace ............................................... ............... 12
modelo de objeto integrado ............................................... ............................ 12
serviços integrados ................................................ ................................. 13
Sessões ................................................. .................................................. ......... 13
6 conceitos de sistemas ................................................ .................................................. ..... 13

Visão geral Server Client ............................................... ........................................ 13

Clientes OPC UA ............................................... .................................................. . 14
Servidores OPC UA ............................................... ................................................. 14
Geral ................................................. ................................................. 14
objetos reais ................................................ ........................................... 15
aplicação de servidor ................................................ ................................... 15
OPC UA AddressSpace ............................................... ............................ 15
entidades de subscrição ................................................ ................................ 16
OPC UA Service Interface .............................................. ......................... 16
Servidor para interações Servidor .............................................. ..................... 16
Redundância ................................................. .................................................. .... 17
Publish-Subscribe ............................................... ............................................... 18
Sinergia de modelos ............................................... ............................................... 18
7 Conjuntos de Serviços ................................................ .................................................. ............. 19

Geral ................................................. .................................................. ........... 19

Descoberta Service Set ............................................... ......................................... 19
SecureChannel Service Set ............................................... ................................. 19
Serviço sessão Definir ................................................. .......................................... 20
OPC Unified Architecture, Part 1 iv solte 1,04

NodeManagement Service Set ............................................... ............................. 20

Ver Serviço Definir ................................................. ............................................... 20
Consulta Service Set ............................................... ............................................... 21
Atributo Service Set ............................................... ............................................ 21
Método Service Set ............................................... ............................................. 21
MonitoredItem Service Set ............................................... ................................... 21
Serviço de Assinatura Definir ............................................... ...................................... 22

FIGURAS

Figura 1 - OPC UA Organização Especificação ........................................... .......................... 7

Figura 2 - aplicações OPC UA alvo ........................................... ................................... 10

Figura 3 - arquitetura OPC UA Sistema ........................................... .................................. 13

Figura 4 - Arquitetura cliente OPC UA ........................................... .................................... 14

Figura 5 - arquitetura OPC UA Servidor ........................................... ................................... 15

Figura 6 - peer-to-peer interacções entre Servidores ....................................... .................. 17

Figura 7 - exemplo do servidor encadeadas ............................................ ....................................... 17

Figura 8 - Integrated Client Server e PubSub modelos ......................................... ............ 19

Figura 9 - SecureChannel e Serviços Sessão ........................................... ..................... 20

TABELAS
Nenhuma tabela de entradas figuras encontrados.
solte 1,04 v OPC Unified Architecture, Part 1

OPC FOUNDATION
____________

Arquitetura unificada -

PREFÁCIO

Esta especificação é a especificação para desenvolvedores de aplicações OPC UA. A especificação é um resultado de um processo de análise e design para desenvolver
uma interface padrão para facilitar o desenvolvimento de aplicações de vários fornecedores que deverá inter-operar perfeitamente em conjunto.

Copyright © 2006-2018, OPC Foundation, Inc.

ACORDO DE USO

restrições de direitos autorais

Qualquer uso não autorizado de esta especificação pode violar leis de direitos autorais, leis de marcas comerciais, e regulamentos e estatutos de comunicações. Este documento
contém informações protegidas por direitos autorais. Todos os direitos reservados. Nenhuma parte deste trabalho coberta pelos direitos de autor aqui pode ser reproduzida ou
usada de qualquer forma ou por qualquer meio - gráfico, eletrônico ou mecânico, incluindo fotocópia, gravação, gravação ou armazenamento de informação e sistemas de
recuperação - sem a permissão do copyright proprietário.

membros OPC Foundation e não-membros são proibidos de copiar e redistribuir essa especificação. Todas as cópias devem
estar obtido em a Individual base, d irectly a partir de o Web OPC Foundation local
http://www.opcfoundation.org
HTU UTH.

PATENTES

A atenção dos adotantes é direcionado para a possibilidade de que o cumprimento ou a adopção de especificações OPC pode exigir o uso de uma invenção cobertos por
direitos de patente. OPC não será responsável por identificar as patentes para as quais pode ser necessária uma licença por qualquer especificação OPC, ou para a
realização de inquéritos judiciais sobre a validade jurídica ou extensão dessas patentes tha t são submetidos à sua atenção. Especificações OPC são prospectiva e apenas
consultivo. potenciais utilizadores são responsáveis ​por proteger-se contra a responsabilidade por violação de patentes.

Garantia e responsabilidade ISENÇÕES

ENQUANTO ESTA PUBLICAÇÃO é acreditado para ser exato, ele é fornecido "COMO ESTÁ" E pode conter erros ou erros de impressão. O Foudation OPC FAZ
NENHUMA GARANTIA DE QUALQUER TIPO, EXPRESSA OU IMPLÍCITA, NO QUE DIZ RESPEITO desta publicação, INCLUINDO, MAS NÃO SE LIMITANDO A
QUALQUER GARANTIA DE TÍTULO OU PROPRIEDADE, IMPLÍCITA GARANTIA DE COMERCIALIZAÇÃO OU GARANTIA DE ADEQUAÇÃO A UM FIM OU USO. EM
NENHUM CASO A OPC Foundation SER responsável por erros contidos neste documento ou por DIRETA, INDIRETA, ACIDENTAL, ESPECIAL, CONSEQUENTE,
CONFIANÇA OU COBRE DANOS, INCLUSIVE PERDA DE LUCROS, RECEITAS, DADOS OU USO,

Incorridos por qualquer USUÁRIO OU TERCEIROS EM RELAÇÃO AO

FORNECIMENTO, DESEMPENHO OU USO DESTE MATERIAL, MESMO QUE AVISADO DA POSSIBILIDADE DE TAIS DANOS.

todo o risco quanto à qualidade e desempenho do software desenvolvido utilizando esta especificação é suportados por si.

RESTRITO LEGENDA DOS DIREITOS

Esta especificação é fornecido com Direitos Restritos. O uso, duplicação ou divulgação pelo governo dos Estados Unidos está sujeito a restrições conforme estabelecido no
(a) deste Acordo nos termos do DFARS 227.7202-3 (a); (B) parágrafo (c) (1) (i) dos Direitos em Dados Técnicos e cláusula de Software de Computador em DFARS
252.227-7013; ou (c) da cláusula de Direitos Restritos de Software Comercial de Computador em FAR 52.227-19 subdivisão (c) (1) e (2), conforme aplicável. Contratante /
fabricante são o OPC Foundation ,. 16101 N. 82 Street, Suite 3B, Scottsdale, AZ, 85260 -1830

CONFORMIDADE

A Fundação OPC deverá sempre ser a única entidade que pode autorizar desenvolvedores, fornecedores e vendedores de hardware e software para usar marcas de
certificação, marcas comerciais ou outras designações especiais para indicar a conformidade com estes materiais. Produtos desenvolvidos utilizando esta especificação pode
reivindicar conformidade ou conformidade com esta especificação se e somente se o software de forma satisfatória atende aos requisitos de certificação estabelecidos pela
Fundação OPC. Os produtos que não atendem a esses requisitos pode reivindicar apenas que o produto foi baseado nesta especificação e não deve reivindicar o
cumprimento ou conformidade com este íon ESPECIFICA.

MARCAS

A maioria dos nomes de computador e software de marca têm marcas comerciais ou marcas registradas. As marcas individuais não foram listados aqui.
OPC Unified Architecture, Part 1 vi solte 1,04

DISPOSIÇÕES GERAIS

Caso qualquer cláusula deste Contrato ser considerada nula, inválida, ineficaz ou i llegal por um tribunal, a validade e aplicabilidade das restantes disposições não será
afectada.

O presente Acordo será regido e interpretado segundo as leis do Estado de Minnesota, excluindo sua escolha ou leis.

Este Contrato incorpora todo o entendimento entre as partes com respeito a, e substitui qualquer entendimento prévio ou acordo (oral ou escrita) em relação a, esta
especificação.

COMUNICAÇÃO EDIÇÃO

A Fundação OPC se esforça para manter os mais altos padrões de qualidade para as especificações publicadas, portanto, eles passam por uma revisão constante e
requinte. Os leitores são encorajados a relatar quaisquer problemas e visualizar qualquer errata existente aqui:
http://www.opcfoundation.org/errata
HTU UTH
solte 1,04 vii OPC Unified Architecture, Part 1

Revisão 1,04 Destaques

A tabela a seguir inclui as questões Mantis resolvidos com esta revisão.

louva a Deus
Resumo Resolução
identidade

3500 Adicionar PubSub Descrição e cláusulas adicionadas 6.5 e 6.6 e outro texto em toda a incluir
Prazo. introdução PubSub.

3787 Definição de certificado está Melhorou a definição de Certificado

incorreta
solte 1,04 1 OPC Unified Architecture, Part 1

OPC Specification Arquitetura unificada

Parte 1: Visão geral e Conceitos

1 Âmbito

Parte 1 apresenta os conceitos e visão geral do OPC Unified Architecture (OPC UA). A leitura deste documento é útil para compreender as
partes restantes deste conjunto de documentos multi-parte. Cada uma das outras partes é brevemente explicado juntamente com uma
ordem de leitura sugerido. Esta parte é não -normative.

2 Documentos de referência

Os seguintes documentos, no todo ou em parte, são normativamente referenciados neste documento e são indispensáveis ​para a sua
aplicação. Para referências datadas, somente a edição citada se aplica. Para referências não datadas, a última edição do documento
referenciado (incluindo quaisquer alterações).

Parte 2: OPC UA Especificação: Parte 2 - Modelo de Segurança

http://www.opcfoundation.org/UA/Part2/

Parte 3: OPC UA Especificação: Parte 3 - Modelo Address Space

http://www.opcfoundation.org/UA/Part3/

Parte 4: OPC UA Especificação: Parte 4 - Serviços

http://www.opcfoundation.org/UA/Part4/

Parte 5: OPC UA Especificação: Parte 5 - Modelo de Informação

http://www.opcfoundation.org/UA/Part5/

Parte 6: OPC UA Especificação: Parte 6 - Mapeamentos

http://www.opcfoundation.org/UA/Part6/

Parte 7: OPC UA Especificação: Parte 7 - Perfis

http://www.opcfoundation.org/UA/Part7/

Parte 8: OPC UA Especificação: Parte 8 - Acesso a dados

http://www.opcfoundation.org/UA/Part8/

Parte 9: OPC UA Especificação: Parte 9 - Alarmes e Condições

http://www.opcfoundation.org/UA/Part9/

Parte 10: OPC UA Especificação: Parte 10 - Programas

http://www.opcfoundation.org/UA/Part10/

Parte 11: OPC UA Especificação: Parte 11 - Acesso histórico, versão 1.01 ou posterior

http://www.opcfoundation.org/UA/Part11/

Parte 12: OPC UA Especificação: Parte 12 - Discovery e Serviços Globais

http://www.opcfoundation.org/UA/Part12/

Parte 13: OPC UA Especificação: Parte 13 - Agregados

http://www.opcfoundation.org/UA/Part13/

Parte 14: OPC UA Especificação: Parte 14 - PubSub

http://www.opcfoundation.org/UA/Part14/
OPC Unified Architecture, Part 1 2 solte 1,04

3 Termos, definições e abreviaturas

convenções do documento

Ao longo deste documento e os referenciados por outras partes da a série, determinado documento
convenções são usadas.

Itálico são usados ​para denotar um termo definido ou definição que aparece no “Termos e definição” cláusula em uma das partes da
série.

Itálicos também são utilizados para denotar o nome de uma entrada de serviço ou parâmetro de saída ou o nome de uma estrutura ou elemento de uma
estrutura, que são geralmente definidas nas tabelas.

Os termos e nomes em itálico são também muitas vezes escrito em -Case camelo (a prática de escrever palavras compostas ou frases
em que os elementos são unidos sem espaços, com letra inicial de cada elemento capitalizados dentro do complexo). Por exemplo, o
termo definido é AddressSpace em vez de espaço de endereço. Isto torna mais fácil de entender que não há uma única definição para

AddressSpace, não definições distintas para o endereço e espaço.

Termos e definições

Para efeitos do presente documento, os seguintes termos se aplicam.

AddressSpace
recolha de informação que um Servidor torna visível à sua clientes

Nota 1 da entrada: Consulte a Parte 3 para uma descrição do conteúdo e estrutura da AddressSpace Server.

Agregar

uma função que calcula valores derivados Dados não tratados

Nota 1 da entrada: Os dados brutos podem ser de um historiador ou dados em tempo real em buffer. Agregados comuns incluem médias ao longo de um determinado intervalo de tempo, mínima ao longo de
um intervalo de tempo e no máximo durante um intervalo de tempo.

Alarme
tipo de Evento associada com uma condição de estado que normalmente requer acknowl edgement

Nota 1 da entrada: Ver Parte 9 para uma descrição de Alarmes.

Atributo
característica de uma primitiva Nó

Nota 1 da entrada: Todos Atributos são definidos por OPC UA, e não pode ser definido pela clientes ou Servidores. Atributos são os únicos elementos do AddressSpace permitido
ter valores de dados.

Corretor
módulo de programa intermediário que rotas NetworkMessages a partir de Publishers para Inscritos

Nota 1 da entrada: Corretores são blocos de construção Message Oriented Middleware.

Certificado
estrutura de dados assinado digitalmente que contém uma chave pública e a identidade de um Cliente ou Servidor

Cliente
aplicação de software que envia mensagens para OPC UA servidores em conformidade com o Serviços especificados neste conjunto de especificações

Condição
termo genérico que é uma extensão para um Evento
solte 1,04 3 OPC Unified Architecture, Part 1

Nota 1 da entrada: A Condição representa as condições de um sistema ou de um dos seus componentes e sempre existe em algum estado.

Pilha comunicação
conjunto de camadas de módulos de software entre a aplicação e o hardware que proporciona diversas funções para codificar, criptografar e
formatar um mensagem para o envio de e para decodificar, descriptografar e descompactar um mensagem que foi recebido

dados complexo
dados que é composto de elementos de mais de um tipo de dados primitivos, tais como uma estrutura de

DataSet
lista de valores de dados nomeados

Nota 1 da entrada: A DataSet tipicamente consiste de Evento campos ou Variável valores ..

DataSetMessage
payload de um NetworkMessage criado a partir de um DataSet

Nota 1 da entrada: o DataSetMessage é uma carga útil imutável do NetworkMessage entregue ao mensagem
Middleware Orientado ( camada de transporte) para entrega pela Editor. o Assinante recebe o DataSetMessage como a carga de um NetworkMessage de Editor com
cabeçalhos adicionais que podem ser fornecidas por t ele Mensagem middleware orientado pelo caminho.

Descoberta

processo pelo qual Cliente obtém informações sobre Servidor s, incluindo endpoint e segurança
em formação

Evento
termo genérico utilizado para descrever uma ocorrência de algum significado dentro de um componente do sistema ou o sistema

EventNotifier
especial Atributo de um Nó que significa que uma Cliente pode se inscrever para o particular, Nó receber notificações do Evento ocorrências

Information Model
estrutura organizacional que define, caracteriza e relaciona recursos de informação de um determinado sistema ou conjunto de sistemas.

Nota 1 da entrada: O modelo de espaço de endereço de núcleo suporta a representação de Modelos de informação no AddressSpace.
Ver Parte 5 para uma descrição da base OPC UA Modelo de Informação.

mensagem
unidade de dados transmitida entre Cliente e Servidor que representa um específico Serviço pedido ou resposta

Mensagem middleware orientado

infraestrutura de apoio envio e recebimento NetworkMessages entre os sistemas distribuídos

Nota 1 de entrada: Um OPC UA Aplicação pode suportar diferentes tipos de Mensagem middleware orientado infra-estruturas e protocolos como AMQP ou UADP com
multicast IP. Outros tipos, como DDS, MQTT ou XMPP também pode ser integrado ao OPC UA PubSub modelo.

Método
função de software que pode ser chamado que é um componente de uma Objeto
OPC Unified Architecture, Part 1 4 solte 1,04

MonitoredItem
Cliente- entidade definida na Servidor Usado para monitorar Atributos ou EventNotifiers para os novos valores ou
Evento ocorrências e que gera notificações para eles

NetworkMessage
DataSetMessages e cabeçalho para facilitar a entrega, roteamento, segurança e filtragem

Nota 1 da entrada: O Editor mãos fora dos NetworkMessage ao Mensagem middleware orientado ( camada de transporte) para entregar DataSetMessages ao Assinantes.

Nota 2 à entrada: A mensagem termo é usado com várias conotações no mundo de mensagens. o Editor gostaria de
acha da mensagem como uma carga imutável entregue ao Mensagem middleware orientado para entrega. o Assinante
muitas vezes pensa da mensagem como não só que payload imutável do remetente, mas também várias anotações sup dobraram pela Mensagem middleware orientado pelo
caminho. Para evitar confusão, o termo DataSetMessage é utilizado para significar a mensagem como fornecido pela Editor para DataSet eo termo NetworkMessage é usada
para significar o DataSetMessage
além de seções para anotação na cabeça e cauda do DataSetMessage.

Nó
elemento fundamental do AddressSpace

NodeClass
classe de um Nó em uma AddressSpace

Nota 1 da entrada: NodeClasses definir os metadados para os componentes do Modelo de Objecto OPC UA. Eles também definir construções, tal como vistas, que são
usadas para organizar o AddressSpace.

Notificação
termo genérico para dados que anuncia a detecção de um Evento ou de um alterado Atributo valor;
notificações são enviados em NotificationMessages.

NotificationMessage
mensagem publicada a partir de um Inscrição que contém um ou mais notificações

Objeto
Nó que representa um elemento físico ou sumário de um sistema

Nota 1 da entrada: objetos são modelados usando o modelo de objeto OPC UA. Sistemas, subsistemas e dispositivos são exemplos de Objetos. A Objeto pode ser definido
como um exemplo de um Tipo de objeto.

Instância objeto
sinônimo de Objeto

Nota 1 da entrada: Nem todos objetos são definidos pela ObjectTypes.

Tipo de objeto
Nó que representa a definição de tipo para uma Objeto

OPC Aplicação UA

Cliente, que chama OPC UA Serviços, ou um Servidor, que executa aqueles Serviços, ou um UA OPC
Editor ou um UA OPC Assinante.

Editor
entidade de envio NetworkMessages a um Mensagem middleware orientado

Nota 1 da entrada: A Editor pode ser um OPC UA nativa Aplicação ou um aplicativo que só tem conhecimento sobre o
Mensagem middleware orientado e as regras para a codificação do NetworkMessages e DataSetMessages.
solte 1,04 5 OPC Unified Architecture, Part 1

PubSub
variante OPC UA do padrão publicar assinar mensagens

Perfil
conjunto específico de recursos para que a Servidor pode reivindicação conformidade.

Nota 1 da entrada: Cada Servidor pode reivindicar a conformidade com mais do que um Perfil

Nota 2 à entrada: O conjunto de recursos são definidos na Parte 7

Programa
executável Objeto que, quando chamado, retorna imediatamente uma resposta para indicar que a execução já começou, e em seguida, retorna
os resultados intermediários e finais através de Assinaturas identificado pela Cliente
durante a chamada

Referência
relação explícita (um ponteiro nomeado) de um Nó para outro

Nota 1 da entrada: O Nó que contém o Referência é a fonte Nó, e o referenciado Nó é o alvo Nó.
Todos Referências são definidos pela ReferenceTypes.

Tipo de referência
Nó que representa a definição de tipo de um Referência

Nota 1 da entrada: O Tipo de referência especifica a semântica de um Referência. O nome de um Tipo de referência identifica como fonte Nodes estão relacionadas com alvo Nodes
e geralmente reflecte uma operação entre os dois, tal como “A contém B”.

Servidor
aplicação de software que implementa e expõe a Serviços especificados neste conjunto de especificações

Serviço
Cliente- operação que pode ser chamado de um Servidor

Nota 1 da entrada: Serviços estão definidos na parte 4. A Serviço é semelhante a uma chamada de método em uma linguagem de programação ou uma operação em um contrato WSDL
Web Services.

service Set
grupo de relacionados Serviços

Sessão
lógica de ligação de longa duração entre um Cliente e uma Servidor.

Nota 1 da entrada: A Sessão mantém informações de estado entre Serviço chama do Cliente ao Servidor.

Assinante
receptora entidade DataSetMessages a partir de um Mensagem middleware orientado

Nota 1 da entrada: UMA Assinante pode ser um OPC UA nativa Aplicação ou um aplicativo que tem apenas o conhecimento sobre a
Mensagem middleware orientado e as regras para decodificar o NetworkMessages e DataSetMessages. UMA Inscrição no OPC UA Servidor cliente modelo tem um significado
diferente do que o Assinante no PubSub modelo.

Inscrição
Cliente- ponto de extremidade definido na Servidor, usado para retornar notificações ao Cliente

Nota 1 da entrada: “Assinatura” é um termo genérico que descreve um conjunto de Nodes seleccionado pela Cliente ( 1) que o Servidor
monitoriza periodicamente para a existência de uma condição, e (2) para o qual o Servidor envia notificações ao Cliente
quando a condição é detectada.
OPC Unified Architecture, Part 1 6 solte 1,04

Sistema subjacente
plataformas de hardware ou de software que existem como uma entidade independente. Aplicações UA são dependentes da existência de
uma entidade, a fim de realizar serviços UA. No entanto, a entidade não é dependente Aplicações UA.

Nota 1 da entrada: plataformas de hardware e software incluem hardware físico, firmware, sistema operacional, redes, aplicativos não-UA, bem como outras Aplicações UA. Um
sistema de controlo, o PLC / dispositivos distribuídos, e UA servidor são exemplos de um Sistema subjacente.

Variável
Nó que contém um valor

Visão
subconjunto específico do AddressSpace que é de interesse para o Cliente.

abreviaturas

A&E Alarmes e Eventos

AMQP Advanced Message Queuing Protocol
API Application Programming Interface
COM Component Object Model
DA Data de acesso
DCS Sistema de controle distribuído
DDS Serviço de Distribuição de Dados
DX Data Exchange
HDA Acesso a dados históricos
HMI Interface homem-máquina
LDAP Lightweight Directory Access Protocol
MES sistema de Execução de Manufatura
MQTT Transporte Message Queue Telemetria
OPC Fundação OPC (a associação da indústria sem fins lucrativos)
anteriormente um acrônimo para “OLE for Process Control”. Sigla não é mais usado.
PLC Controlador Lógico Programável
SCADA Controle de Supervisão e Aquisição de Dados
SABONETE Protocolo de acesso a objetos simples
UA Arquitetura unificada
UADP UA Datagram Protocol
UDDI Universal Description, Discovery and Integration
UML Unified Modeling Language
WSDL Web Services Definition Language
XML Extensible Markup Language
XMPP Extensible Messaging and Presence Protocol
solte 1,04 7 OPC Unified Architecture, Part 1

4 Estrutura da série OPC UA

organização especificação

Esta especificação é organizada como uma especificação de multi -part, como ilustrado na Figura 1.

OPC UA Multi-Parte Especificação

As peças de especificação do núcleo Especificação Parts

Conceitos Parte 8 - Acesso a dados

Parte 2 - Modelo de Segurança Parte 9 - Alarmes e Condições

Parte 3 - Endereço Modelo Espacial Parte 10 - Programas

Parte 4 - Serviços Parte 11 - Historical Acesso tipo de acesso

Parte 5 - Modelo de Informação

Utility Especificação Parts

Parte 6 - Mapeamentos de Serviços

Parte 12 - Discovery
Parte 7 - Perfis Parte 1 - Visão Geral e

Parte 13 - Agregados

Parte 14 - PubSub

Figura 1 - OPC UA Organização Especificação

Partes 1 a 7 e Parte 14 especificar os principais recursos de OPC UA. Estas capacidades centrais definem a estrutura do OPC AddressSpace
e a Serviços que operam nele. Parte 14 define uma OPC UA publicar subscrever padrão, além do Servidor cliente padrão definido pela Serviços

na Parte 4. Peças de 8 a 11 aplicar essas capacidades essenciais para tipos específicos de acesso anteriormente abordados pelas
especificações OPC COM separadas, tais como acesso a dados (DA), Alarmes e Eventos (A & E) e histórico de acesso a dados (HDA).
Parte 12 descreve Descoberta mecanismos de OPC UA e parte 13 descreve maneiras de agregar dados.

Os leitores são encorajados a ler partes de 1 a 5 das especificações do núcleo antes de Peças de leitura 8 a 14. Por exemplo, um leitor
interessado em UA acesso a dados deve ler Partes 1 a 5 e
8. As referências na Parte 8 de orientar o leitor para outras partes do presente especificação.

As peças de especificação do núcleo

Parte 1 - Visão Geral e Conceitos

Part 1 (esta parte) apresenta os conceitos e visão geral de OPC UA.

Parte 2 - Modelo de Segurança

Parte 2 descreve o modelo para fixar as interacções entre Aplicações OPC UA.

Parte 3 - Endereço Modelo Espacial

Parte 3 descreve o conteúdo e estrutura do AddressSpace do servidor.

Parte 4 - Serviços

Parte 4 especifica a Serviços fornecido por Servidores.

Parte 5 - Modelo de Informação

Parte 5 especifica os tipos e as suas relações definido para Servidores.

OPC Unified Architecture, Part 1 8 solte 1,04

Parte 6 - Mapeamentos

Parte 6 especifica os mapeamentos de transportar protocolos e codificações de dados suportadas por OPC UA.

Parte 7 - Perfis

Parte 7 especifica o Profiles que estão disponíveis para OPC Aplicações UA. Estes Profiles fornecer agrupamentos de funcionalidade que
pode ser usado para a certificação nível de conformidade. Aplicações OPC UA
serão testados contra o Perfis.

Tipo de acesso peças de especificação Parte 8 -

Acesso a dados

Parte 8 especifica o uso de OPC UA para acesso a dados.

Parte 9 - Alarmes e Condições

Parte 9 especifica uso de suporte OPC UA para o acesso a alarmes e Condições. O sistema básico inclui suporte para simples eventos; esta
especificação se estende que o apoio para incluir suporte para
alarmes e Condições.

Parte 10 - Programas

Parte 10 especifica apoio OPC UA para o acesso a Programas.

Parte 11 - Acesso histórico

Part 11 especifica o uso de OPC UA para o acesso histórico. Este acesso inclui tanto dados históricos e histórico Eventos.

Utility peças de especificação Parte

12 - Discovery

Parte 12 especifica como Servidores de descoberta operar em diferentes cenários e descreve como UA
clientes e servidores deve interagir com eles. Ele também define como UA informações relacionadas devem ser acessados ​por meio de protocolos
de serviço de diretório comuns, tais como LDAP.

Parte 13 - Agregados

Parte 13 especifica como calcular e retornar agregados, como mínimo, máximo, etc. média
agregados pode ser usado com dados atuais e históricos.

Parte 14 - PubSub

Parte 14 especifica o Arquitectura Unified OPC (OPC UA) PubSub modelo de comunicação. o
PubSub modelo de comunicação define uma OPC UA publicar subscrever padrão, além do Servidor cliente padrão definido pela Serviços na
Parte 4.

5 Visão geral

âmbito UA

OPC UA é aplicável a componentes em todos os domínios industriais, tais como sensores industriais e atuadores, sistemas de controle,
Manufacturing Execution Systems e Resource Planning Enterprise Systems, incluindo a Internet industrial das coisas (IIoT), máquina para
máquina (M2M), bem como Industrie 4.0 e China 2025. Estes sistemas têm a intenção de trocar informações e de usar comando e
controle para processos industriais. OPC UA define um modelo de infra-estrutura comum para facilitar esta troca de informações OPC UA
especifica o seguinte:

• O modelo de informação para representar estrutura, comportamento e semântica.

• O modelo de mensagem para interagir entre aplicações.

• O modelo de comunicação para transferir os dados entre pontos finais.

solte 1,04 9 OPC Unified Architecture, Part 1

• O modelo de conformidade para garantir a interoperabilidade entre sistemas.

Geral

OPC UA é um padrão independente de plataforma através da qual vários tipos de sistemas e dispositivos podem se comunicar através do
envio de solicitação e resposta mensagens entre clientes e Servidores ou NetworkMessages entre Publishers e Inscritos sobre vários tipos de
redes. Ele suporta comunicação robusto e seguro que garante a identidade de Aplicações OPC UA e resiste a ataques.

No Cliente Servidor modelo OPC UA define conjuntos de Serviços aquele servidores pode proporcionar, e individual
servidores especifique a clientes o que Serviço define que eles suportam. A informação é transmitida usando OPC UAdefined e tipos de dados
definidos pelo fornecedor, e servidores definir os modelos que objeto clientes dinamicamente pode descobrir. servidores pode fornecer acesso a
ambos os dados atuais e históricos, bem como
alarmes e Eventos para notificar clientes mudanças de importantes. OPC UA pode ser mapeado para uma variedade de protocolos de comunicação
e de dados podem ser codificados de várias maneiras, para balancear a portabilidade e eficiência.

Em adição ao Servidor cliente modelo, OPC UA define um mecanismo de Publishers para transferir as informações para Inscritos usando o PubSub
modelo.

objetivos do projeto

OPC UA oferece uma consistente, integrado AddressSpace e modelo de serviço. Isso permite que um único
Servidor para integrar dados, alarmes e Eventos, e história em seu AddressSpace, e fornecer acesso a eles através de um conjunto
integrado de Serviços. Estes Serviços também incluem um modelo de segurança integrado.

OPC UA também permite servidores fornecer clientes com definições de tipo para o objetos acedido a partir do AddressSpace. Isso permite
que os modelos de informação a ser usado para descrever o conteúdo do
AddressSpace. OPC UA permite que dados sejam expostos em diversos formatos, incluindo estruturas binárias e documentos XML ou
JSON. O formato dos dados pode ser definida por OPC, outras organizações padrão ou fornecedores. Através de AddressSpace, Clientes pode
consultar o Servidor para os metadados que descreve o formato para os dados. Em muitos casos, clientes sem o conhecimento
pré-programado dos formatos de dados será capaz de determinar os formatos em tempo de execução e devidamente utilizar os dados.

OPC UA adiciona suporte para muitos relacionamentos entre Nodes em vez de ser limitado a apenas uma única hierarquia. Desta forma, um Servidor pode
apresentar os dados de uma variedade de hierarquias adaptada à forma como um conjunto de clientes normalmente gostam de ver os dados. Esta
flexibilidade, combinada com o apoio para as definições de tipo, torna OPC UA aplicável a uma grande variedade de domínios de problemas. Tal
como ilustrado na Figura 2, o OPC UA não é destinada a apenas o SCADA, interface de PLC e DCS, mas também como uma forma de proporcionar
uma maior interoperabilidade entre as funções de nível superior.
OPC Unified Architecture, Part 1 10 solte 1,04

A Enterprise Corporate

OPC UA

Fabricação, produção e manutenção

OPC UA

HMI
HMI MES SCADA
OPC UA

OPC UA
Adv.
OPC UA fornada
Ao controle

Ao controle

OPC UA

PLC Aquisição
PLC Redes industriais Aquisição ?? ....... ??
DCS Redes industriais de dados ?? ....... ??
DCS de dados

Figura 2 - aplicações OPC UA alvo

OPC UA é projetado para fornecer robustez dos dados publicados. Uma das principais características de todos os servidores OPC é a
capacidade de publicar dados e Evento Notificações. OPC UA oferece mecanismos para clientes para detectar rapidamente e recuperar de falhas
de comunicação associados a essas transferências sem ter que esperar por longos tempos de espera fornecidos pelos protocolos subjacentes.

OPC UA foi projetado para suportar uma ampla gama de servidores, de PLCs de chão de fábrica para a empresa Servidores.
Estes servidores são caracterizados por um largo âmbito de tamanho, desempenho, plataformas de execução e as capacidades
funcionais. Portanto, OPC UA define um conjunto abrangente de recursos e servidores
pode implementar um subconjunto desses recursos. Para promover a interoperabilidade, OPC UA define subconjuntos, referidos como perfis, ao
qual servidores pode reivindicação conformidade. clientes pode, então, descobrir a
Profiles de um Servidor, e adequar suas interações com que Servidor baseado no Perfis. Profiles são definidas na parte 7.

As especificações OPC UA estão em camadas para isolar o projeto do núcleo da tecnologia de computação subjacente e transporte de
rede. Isso permite OPC UA a ser mapeado para futuras tecnologias como necessário, sem negar o projeto básico. Mapeamentos e
codificações de dados são descritos na Parte 6. Três codificações de dados estão definidos:

• XML / text

• UA Binary

• JSON

Além disso, vários protocolos são definidos:

• OPC UA TCP

• HTTPS

• WebSockets

Aplicações OPC UA que suportam vários transportes e codificações permitirá que os usuários finais para tomar decisões sobre trade-offs
entre desempenho e compatibilidade no momento da implantação, em vez de ter essas compensações determinadas pelo fornecedor
OPC no momento da definição do produto.

OPC UA foi concebido como o caminho de migração para clientes OPC e servidores que são baseados em Mic Rosoft tecnologia COM.
Cuidado foi tomado no projeto de OPC UA para que os dados existentes expostos por servidores OPC COM (DA, HDA e A & E) pode ser
facilmente mapeada e expostos via OPC UA. Os vendedores podem escolher migrar seus produtos nativamente para OPC UA ou usar
invólucros externos converter de
solte 1,04 11 OPC Unified Architecture, Part 1

OPC COM para OPC UA e vice-versa. Cada uma das especificações OPC anteriores definiu o seu próprio modelo de espaço de endereço e seu
próprio conjunto de Serviços. OPC UA unifica os modelos anteriores em um único espaço de endereço integrado com um único conjunto de Serviços.

OPC UA PubSub abre novos campos de aplicação para OPC UA. A seguir estão alguns exemplo usa para
PubSub:

• Configurável peer to peer comunicação entre os controladores e entre controladores e IHMs. Os pares não estão diretamente
ligados e nem sequer precisa de saber sobre a existência um do outro. A troca de dados, muitas vezes requer um tempo de
janela fixo; pode ser ponto-a-ponto ou uma ligação multi-ponto.

• fluxos de trabalho assíncronos. Por exemplo, um aplicativo de processamento de pedidos pode colocar um fim em uma fila de
mensagens ou um enterprise service bus. De lá, ele pode ser processado por um ou mais trabalhadores.

• Registrando a múltiplos sistemas. Por exemplo, sensores ou atuadores pode escrever logs para um sistema de monitoramento, uma
HMI, um aplicativo arquivo para consulta posterior, e assim por diante.

• servidores representando serviços ou dispositivos podem transmitir dados para aplicativos hospedados na nuvem. Por exemplo, os
servidores de back-end, análise de big data para otimização do sistema e manutenção preditiva.

PubSub não está ligado a um sistema de mensagens em particular. Pelo contrário, pode ser mapeado para vários sistemas diferentes como ilustrado
com dois exemplos:

• PubSub com UDP podem ser bem adequados em ambientes de produção para transmissões repetidas de pequenas quantidades de
dados. Ele também permite a troca de dados em um-para-um e um-para-muitos configurações.

• A utilização de protocolos de mensagens estabelecidas (por exemplo o protocolo ISO / IEC AMQP 1.0) com a codificação de dados JSON
suporta o caminho de integração nuvem e prontamente permite o tratamento das informações nos modernos sistemas de transmissão e de
análise em lotes.

modelos e serviços integrados

modelo de segurança

5.4.1.1 Geral

segurança OPC UA está preocupado com a autenticação de clientes e servidores, a autenticação de usuários, a integridade ea
confidencialidade das suas comunicações, ea verifiabilit y de alegações de funcionalidade. Ele não especifica as circunstâncias em que
são necessários vários mecanismos de segurança. Essa especificação é crucial, mas é pelos designers do sistema em um determinado
local e pode ser especificado por outras normas.

Em vez disso, o OPC UA fornece um modelo de segurança, descrito na Parte 2, em que as medidas de segurança podem ser seleccionados e
configurado para satisfazer as necessidades de uma determinada instalação de segurança. Este modelo inclui mecanismos de segurança e
parâmetros. Em alguns casos, o mecanismo de troca de parâmetros de segurança está definido, mas a maneira que os aplicativos usam esses
parâmetros não é. Este quadro também define um conjunto mínimo de segurança Profiles isso tudo Aplicações OPC UA apoio, mesmo que eles
não podem ser utilizados em todas as instalações. Segurança Profiles são definidas na parte 7.

5.4.1.2 Descoberta e sessão estabelecimento

segurança nível de aplicação baseia-se num canal de comunicação segura que é activa para a duração da aplicação Sessão e garante a
integridade de todos mensagens que são trocadas. Isso significa que os usuários precisam ser autenticados apenas uma vez, quando a
aplicação Sessão é estabelecida. Os mecanismos para descobrir Servidor s e estabelecer canais de comunicação seguros e aplicação sessões
são descritos na Parte 4 e Parte 6. Informações adicionais sobre o Descoberta

processo está descrito na Parte 12.

Quando um Sessão é estabelecida, a Cliente e Servidor aplicações negociar um seguro

canal de comunicações. Digital (X.509) certificados são utilizados para identificar o Cliente e Servidor.
OPC Unified Architecture, Part 1 12 solte 1,04

o Servidor autentica ainda mais o usuário e autoriza os pedidos subsequentes ao acesso objetos no Servidor.

5.4.1.3 Auditoria

OPC UA inclui suporte para auditoria de segurança trilhas com rastreabilidade entre Cliente e Servidor logs de auditoria. Se um problema
relacionado com o ty SECURI é detectada no Servidor, o associado Cliente entrada no registo de auditoria pode ser localizado e examinado. OPC
UA também fornece a capacidade de servidores para gerar As notificações de eventos que o relatório auditável Eventos para clientes capaz de
processar e log-los. OPC UA define parâmetros de auditoria de segurança que podem ser incluídos em entradas de log de auditoria e auditoria Notificações
de eventos. Parte 5 define os tipos de dados para esses parâmetros. Não tudo servidores e clientes fornecer todos os recursos de auditoria. perfis, encontrada
na Parte 7, indicar quais recursos são suportados.

5.4.1.4 segurança dos transportes

segurança OPC UA complementa a infraestrutura de segurança fornecido pela maioria das plataformas capazes de serviços web.

segurança de nível de transporte pode ser usada para criptografar e assinar Mensagens. Criptografia e assinaturas proteger contra a
divulgação de informações e proteger a integridade do Mensagens. Encryption
recursos são fornecidos pela tecnologia de comunicações subjacente usado para troca mensagens
entre Aplicações OPC UA. Parte 7 define os algoritmos de criptografia e de assinatura para ser usados ​para uma determinada Perfil.

modelo integrado AddressSpace

O conjunto de objetos e informações relacionadas que o Servidor coloca à disposição clientes é referido como a sua AddressSpace. O OPC
UA AddressSpace representa o seu conteúdo como um conjunto de Nó s ligadas pela Referências.

características primitivas de Nó s são descritas por OPC-definida Atributos. Atributos são os únicos elementos de um Servidor que têm valores de
dados. Os tipos de dados que definem os valores de atributo podem ser simples ou complexos.

Nó s no AddressSpace são digitados de acordo com seu uso e seu significado. NodeClasses definir os metadados para o OPC UA AddressSpace.
Parte 3 define o OPC UA NodeClasses.

o NodeClass de base define Atributos comum a todos Nó s, o que permite a identificação, classificação e nomenclatura. Cada NodeClass herda
estes Atributos e pode ainda definir o seu próprio Atributos.

Para promover a interoperabilidade dos clientes e servidores, o OPC UA AddressSpace está estruturado hierarquicamente com níveis
superiores a mesma para todos Servidores. Apesar Nó s no AddressSpace são tipicamente acessível através da hierarquia, eles podem ter Referências
uns com os outros, permitindo que o
AddressSpace para representar uma rede inter-relacionado de Nó s. O modelo do AddressSpace é definida na parte 3.

servidores pode subdividir a AddressSpace para dentro Visualizações para simplificar Cliente Acesso. 6.3.4.3 subseção descreve AddressSpace Visualizações em
mais detalhes.

modelo de objeto integrado

O modelo de objeto OPC UA fornece um conjunto consistente e integrado de NodeClasses para representar
objetos no AddressSpace. Este modelo representa objetos em termos da sua Variáveis ​e eventos e
Métodos, e suas relações com outras Objetos. Parte 3 descreve este modelo.

O modelo de objeto OPC UA permite servidores para fornecer definições de tipo para objetos e seus componentes. definições de tipo podem
ser uma subclasse. Eles também podem ser comuns ou podem ser específicas do sistema. ObjectTypes pode ser definida por organizações
de padrões, vendedores ou usuários finais.

Este modelo permite que os dados, alarmes e Eventos, e sua história para ser integrado em um único Servidor.
Por exemplo, servidores são capazes de representar um transmissor de temperatura como um Objeto que é composto por um valor de temperatura, um
conjunto de parâmetros de alarme, e um correspondente conjunto de limites de alarme.
solte 1,04 13 OPC Unified Architecture, Part 1

serviços integrados

A interface entre clientes e servidores é definido como um conjunto de Serviços. Estes Serviços são organizados em agrupamentos lógicos chamados Conjuntos
de serviço. Conjuntos de serviços são discutidos na cláusula 6.4 e especificado na parte 4.

OPC UA Serviços fornecer dois recursos para Clientes. Eles permitem clientes para emitir pedidos para servidores
e receber respostas a partir deles. Eles também permitem que clientes a subscrever servidores para Notificações. notificações são utilizados pela Servidor
para relatar ocorrências como alarmes, alterações de valor de dados,
Eventos, e Programa resultados da execução.

OPC UA mensagens podem ser codificados como texto XML ou em formato binário para fins de eficiência. Eles podem ser transferidos usando
vários transportes subjacentes, por exemplo TCP ou serviços web através de HTTP. servidores pode fornecer diferentes codificações e meios de
transporte tal como definido pela parte 6.

sessões

OPC UA Cliente Servidor interação exige um modelo stateful. As informações de estado é mantido dentro de uma aplicação Sessão. Exemplos
de estado-informações são assinaturas, as credenciais do usuário e pontos de continuação para operações que abrangem vários pedidos.

sessões são definidas como ligações lógicas entre clientes e Servidores. servidores podem limitar o número de concorrente sessões com
base na disponibilidade de recursos, restrições de licenciamento, ou outras restrições. Cada Sessão é independente dos protocolos de
comunicação subjacentes. Falhas destes protocolos não causam automaticamente o Sessão terminar. sessões terminar com base em

Cliente ou Servidor solicitar, ou com base em inatividade do Cliente. O intervalo de tempo de inatividade é negociado durante Sessão estabelecimento.

6 conceitos Sistemas

Visão geral Client Server

Os modelos de arquitetura de sistemas OPC UA clientes e servidores como parceiros que interagem. Cada sistema pode conter múltiplos clientes
e Servidores. Cada Cliente podem interagir simultaneamente com um ou mais
servidores, e cada Servidor podem interagir simultaneamente com um ou mais Clientes. Um aplicativo pode combinar Servidor e Cliente componentes
para permitir a interacção com outros servidores e clientes como descrito em 6.3.7.

clientes e servidores são descritos nas sub-cláusulas 6.2 e 6.3. A Figura 3 ilustra a arquitectura que inclui um combinado Servidor e Cliente.

As solicitações As solicitações

do cliente do cliente

Combinado
cliente servidor servidor
OPC UA respostas do OPC UA respostas do OPC UA
servidor servidor
e cliente

notificações notificações
publicadas publicadas

Figura 3 - arquitetura OPC UA Sistema

OPC Unified Architecture, Part 1 14 solte 1,04

Clientes OPC UA

O OPC UA Cliente modelos de arquitetura as Cliente endpoint de interações cliente / servidor. A Figura 4 ilustra os elementos principais de
um típico Cliente e como eles se relacionam entre si.

Cliente OPC UA

Cliente-Aplicação

Solicitações para Entrega do Os pedidos para Entrega de

enviar solicitações serviço recebido enviar publicação notificações
de serviço respostas solicitações de recebidas

OPC UA API Cliente

OPC UA Pilha
Comunicação Req Msg Rsp Msg publ Msg notificação Msg

para OPC De Para De

servidor servidor Servidor servidor
UA OPC UA OPC UA OPC UA

Figura 4 - Arquitetura cliente OPC UA

o Cliente A aplicação é o código que implementa a função do Cliente. Ele usa o Cliente API para enviar e receber OPC UA Serviço pedidos
e respostas à Servidor. o Serviços definido para OPC UA são descritas na cláusula 6.4, e especificados na Parte 4.

Note que o “ Cliente API”é uma interface interna que isola o Cliente código de aplicação de uma comunicação Stack OPC UA. Os
convertidos OPC UA Comunicação Pilha Cliente API põe em
mensagens e envia-los através da entidade de comunicação subjacente à Servidor a pedido do Cliente aplicação. O OPC UA Comunicação
Stack também recebe resposta e
NotificationMessages da entidade de comunicação subjacente e os entrega ao Cliente
através da aplicação Cliente API.

Servidores OPC UA

Geral

O OPC UA Servidor modelos de arquitetura as Servidor endpoint de interações cliente / servidor. A Figura 5 ilustra os elementos principais
do Servidor e como eles se relacionam entre si.
solte 1,04 15 OPC Unified Architecture, Part 1

OPC UA Servidor

OPC Aplicação UA Servidor

objetos
reais

OPC UA AddressSpace
Monitorado
nó Item
Nó Nó Assinatura

Nó
Nó Assinatura
Visão
Nó Nó

Node Assinatura
Nó

API OPC UA Servidor

OPC UA Pilha
Comunicação Req Msg Rsp Msg publ Msg notificação Msg

Do cliente Para OPC Do cliente Para OPC

OPC UA cliente UA OPC UA cliente UA

Figura 5 - arquitetura OPC UA Servidor

objetos reais

objetos reais são objetos físicos ou de software que são acessíveis pela Servidor aplicação ou que mantém internamente. Exemplos
incluem dispositivos físicos e os contadores de diagnóstico.

aplicação de servidor

o Servidor aplicação é o código que implementa a função do Servidor. Ele usa o Servidor API para enviar e receber OPC UA mensagens a
partir de Clientes. Note que o “ Servidor API”é uma interface interna que isola o Servidor código de aplicação de uma comunicação Stack
OPC UA.

OPC UA AddressSpace

6.3.4.1 AddressSpace Nodes

o AddressSpace é modelado como um conjunto de Nó é acessível pela clientes usando OPC UA Serviços
(interfaces e métodos). Nó s no AddressSpace são usados ​para representar objetos reais, suas definições e das suas Referências uns com
os outros.

6.3.4.2 organização AddressSpace

Parte 3 contém os detalhes do modelo de meta “blocos de construção” usados ​para criar uma AddressSpace fora do interconectado Nodes de
uma maneira consistente. servidores são livres de organizar a sua Nó s dentro do
AddressSpace como eles escolhem. O uso de Referências entre Nó s licenças servidores para organizar a AddressSpace em hierarquias,
uma rede de malha cheia de Nó s, ou qualquer mistura possível.

Parte 5 define OPC UA Nodes e Referências e sua organização esperado no AddressSpace.

Alguns Profiles não exigirá que toda a UA Nodes seja implementado.

6.3.4.3 AddressSpace Visualizações

UMA Visão é um subconjunto do AddressSpace. Visualizações são usadas para restringir a Nó s que o Servidor torna visível para o Cliente, restringindo,
assim, o tamanho da AddressSpace para o Serviço os pedidos apresentados
OPC Unified Architecture, Part 1 16 solte 1,04

pelo Cliente. O padrão Visão é a inteira AddressSpace. servidores pode, opcionalmente, definir outra
Pontos de vista. Visualizações esconder algum do Nó s ou Referências no AddressSpace. Visualizações são visíveis através da
AddressSpace e clientes é capaz de navegar Visualizações para determinar a sua estrutura. Visualizações são muitas vezes hierarquias, que são mais fáceis
para clientes para navegar e representam em uma árvore.

6.3.4.4 Suporte para modelos de informação

O OPC UA AddressSpace suporta modelos de informação. Este apoio é prestado através de:

a) Nó Referências que permite objetos no AddressSpace estar relacionado com o outro.

b) ObjectType Node s que fornecem informações semânticas para real Objects ( digite definições).

c) ObjectType Node s para apoiar subclasses de definições de tipo.

d) definições de tipo de dados expostos na AddressSpace que permitem que tipos de dados específicos da indústria para ser
usava.

e) os padrões de companhia OPC UA que permitem grupos da indústria para defi ne como seus modelos de informação específicos estão a ser
representado em Servidor AddressSpace.

entidades de subscrição

6.3.5.1 MonitoredItems

MonitoredItems são entidades no Servidor criado pelo Cliente esse monitor AddressSpace Node s e os seus homólogos do mundo real.
Quando detectam uma alteração de dados ou uma ocorrência de evento / alarme, eles geram uma Notificação que é transferido para o Cliente
por um Inscrição.

6.3.5.2 Assinaturas

UMA Inscrição é um ponto final no Servidor que publica notificações para Clientes. clientes controlar a taxa na qual a publicação ocorre
enviando Publicar Mensagens.

OPC UA Service Interface

6.3.6.1 Geral

o Serviços definido para OPC UA são descritas na cláusula 6.4, e especificados na Parte 4.

6.3.6.2 Pedido / Serviços de resposta

Pedido / resposta Serviços estamos Serviços invocada pela Cliente através do OPC UA Serviço
Interface para executar uma tarefa específica em um ou mais Nó s no AddressSpace e para retornar uma resposta.

6.3.6.3 Serviços de subscrição

o Publicar Serviço é invocado através do OPC UA Serviço Interface para o propósito de enviar periodicamente notificações para Clientes. As
notificações incluem Eventos, Alarmes, mudanças de dados e Programa
saídas.

Servidor para interações de servidor

Servidor para Servidor interacções na Servidor cliente modelo são interacções em que um Servidor age como um Cliente de outro Servidor.
Servidor para Servidor interações permitir o desenvolvimento de servidores que:

a) trocar informações uns com os outros em uma base peer-to-peer, este poderia incluir redundância ou remoto servidores que são
utilizados para manter as definições sistema de largura de tipo (ver Figura 6),

b) são encadeados numa arquitectura em camadas de servidores fornecer:

1) agregação de dados a partir da camada inferior servidores,

2) dados de camada superior constrói clientes, e

3) as interfaces concentrador clientes para pontos únicos de acesso a vários subjacente Servidores.

A Figura 6 ilustra as interacções entre Servidores.

solte 1,04 17 OPC Unified Architecture, Part 1

Rede

Servidor OPC Servidor OPC

interface do interface do
servidor As interacções entre cliente

servidores
interface do interface do
cliente servidor

Figura 6 - interacções ponto-a-ponto entre Servidores

Similar interacções peer-to-peer também pode ser realizada utilizando o OPC UA PubSub modelo onde cada peer Aplicação é um tanto Editor
e uma Assinante.

Figura 7 estende-se o exemplo anterior e ilustra o encadeamento de servidores juntos para o acesso vertical para os dados em uma
empresa.

cliente cliente
OPC OPC
Enterprise Network
Empresa
camada
Servidor semântica
OPC

cliente cliente
OPC OPC Camada
operações de Rede
semântica

processo
Servidor Servidor
OPC OPC

cliente cliente
OPC OPC
Dispositivo
Planta Piso de rede
camada

semântica
Servidor Servidor
OPC OPC

Figura 7 - acorrentadas exemplo Servidor

Redundância

OPC UA fornece as estruturas e serviços de dados por que Redundância pode ser conseguida de um modo padronizado. A redundância
pode ser usado para alta disponibilidade, tolerância a falhas e balanceamento de carga. Parte 4 define formalmente Servidor cliente e A
redundância de rede. Apenas alguns Profiles
Parte 7 exigirá suporte de redundância, mas não a base Perfil.

comportamentos de cliente necessário e servidor estão associados com dois modos distintos de Redundância de servidores, transparente
e não transparente. o Cliente e Servidor responsabilidades ao usar redundância transparente ou não transparente são definidos na Parte 4.
OPC Unified Architecture, Part 1 18 solte 1,04

servidores que o apoio redundância não transparente também pode apoiar controlado cliente balanceamento de carga. A saúde de uma Servidor incluindo
a sua capacidade de Serviço pedidos é definido como colectivamente Nível de serviço.
Ver Parte 5 para uma definição formal de Nível de serviço. Parte 4 define quatro distinta Nível de serviço subintervalos e exemplo de uso.

Publish-Subscribe

Com PubSub, Aplicações OPC UA não trocam diretamente as solicitações e respostas. Em vez de,
Publishers enviar mensagens a um Message Oriented Middleware, sem o conhecimento de que, se houver,
Inscritos pode ser. Similarmente, Inscritos manifestar interesse em tipos específicos de dados e mensagens de processo que contêm esses
dados, sem conhecimento do que Publishers existem.

mensagem Middleware orientado é um software ou hardware infraestrutura de apoio envio e recebimento de mensagens entre sistemas
distribuídos. Depende do Mensagem middleware orientado
como esta distribuição é implementado.

Para cobrir um grande número de casos de uso, OPC UA PubSub suporta dois muito diferente Mensagem middleware orientado variantes.
Esses são:

• Uma forma corretor-menos, onde o Mensagem middleware orientado é a infra-estrutura de rede que é capaz de mensagens
baseadas em datagramas de rota. Inscritos e Publishers usar protocolos de datagramas como UDP multicast.

• Uma forma de base corretor, onde o Mensagem middleware orientado é um Corretor. Inscritos e
Publishers usar protocolos de mensagens padrão como AMQP ou MQTT se comunicar com o
Corretor. Todas as mensagens são publicados para filas específicas (por exemplo, temas, nós) que o Corretor expõe e Inscritos pode
ouvir essas filas. o Corretor pode traduzir mensagens do protocolo de mensagens formal da Editor ao protocolo de mensagens
formal da Assinante.

PubSub é usado para transmitir mensagens entre diferentes sistemas componente s sem esses componentes têm de saber a identidade
do outro.

UMA Editor é pré-configurado com os dados para enviar. Não há estabelecimento de conexão entre
Editor e Assinante.

O conhecimento sobre quem Inscritos são e o encaminhamento de publ ished dados para o Inscritos
é descarregadas para o Message Oriented Middleware. o Editor não sabe ou se importa se há um ou muitos Assinantes. Disposições
relativas ao esforço e recursos para o Editor são previsíveis e não depender do número de Assinantes.

Parte 14 descreve os detalhes do OPC UA PubSub modelo.

Sinergia de modelos

PubSub e Servidor cliente são ambos baseados no OPC UA Modelo de Informação. PubSub portanto, pode ser facilmente integrado em servidores
e Clientes. Muito tipicamente, uma Editor será um Servidor ( o proprietário da informação) e uma Assinante é muitas vezes uma Cliente. Acima
de tudo, o PubSub Information Model
para configuração promove a configuração de Publishers e Inscritos utilizando o OPC UA Servidor cliente modelo. A Figura 8 representa
uma única OPC UA Aplicação que atua como um Servidor e uma
Editor.
solte 1,04 19 OPC Unified Architecture, Part 1

assinante 1 assinante N
OPC UA
Cliente A

Mensagem middleware orientado

OPC UA Servidor Editor

Cliente Um Session

DataSetWriter
Inscrição
DataSet

espaço de endereço

OPC
Aplicação UA

Figura 8 - Integrated Client Server e modelos PubSub

No entanto, o PubSub A comunicação não exigem uma tal dependência papel. isto é, clientes pode ser Publishers e servidores pode ser Assinantes.
Na verdade, não há necessidade de Publishers ou
Inscritos para ser um Servidor ou um Cliente participar em PubSub comunicações.

7 Define Serviços

Geral

OPC UA Serviços são divididos em Conjuntos de serviços, definindo cada um agrupamento lógico de Serviços utilizado para aceder a um aspecto
particular da Servidor. o Conjuntos de serviços são descritos abaixo. o Conjuntos de serviços
e sua Serviços são especificados na Parte 4. Seja ou não uma Servidor suporta uma Service Set, ou um específico Serviço dentro de um Service
Set, é definido pelo seu Perfil. Profiles estão descritos na Parte 7.

Descoberta Service Set

este service Set define Serviços usado para descobrir servidores que estão disponíveis em um sistema. Ele também fornece uma maneira pela qual
os clientes podem ler a configuração de segurança necessária para a conexão ao
Servidor. o Descoberta Serviços são implementadas por indivíduo servidores e por dedicado Servidores Discovery. Bem conhecido dedicado Servidores de
descoberta fornecer uma maneira para os clientes para descobrir todas nominativas
Servidores. Parte 12 descreve como usar o Serviços de descoberta com dedicado Servidores Discovery.

SecureChannel Service Set

este service Set define Serviços usada para abrir um canal de comunicação que assegura a
confidencialidade e integridade de todos mensagens trocadas com o Servidor. Os conceitos de base para a segurança UA estão definidos na parte
2.

o SecureChannel Serviços são ao contrário de outros Serviços porque normalmente não são implementadas pelo OPC UA Aplicação diretamente.
Em vez disso, eles são fornecidos pela pilha de comunicação que a
OPC UA Aplicação é construído. Aplicações OPC UA simplesmente precisa verificar se um SecureChannel é activa sempre que receba um Mensagem
Parte 6 descreve como o Serviços SecureChannel são implementadas com diferentes tipos de pilhas de comunicação.
OPC Unified Architecture, Part 1 20 solte 1,04

UMA SecureChannel é uma conexão lógica de longa duração entre um único Cliente e uma única Servidor.
Este canal mantém um conjunto de chaves que são conhecidos apenas para a Cliente e Servidor e que são usados ​para autenticar e criptografar mensagens
enviados através da rede. o Serviços SecureChannel permitir que o Cliente e Servidor para negociar com segurança as chaves de usar.

Os algoritmos exatos usados ​para autenticar e criptografar mensagens são descritos nas políticas de segurança para uma Servidor. Estas
políticas são expostos através da Descoberta Service Set. UMA Cliente seleciona o ponto final apropriado que apoia a política de
segurança desejado pela Servidor quando se cria um
SecureChannel.

Quando um Cliente e Servidor estão a comunicar através de um SecureChannel eles verificar se todas as chamadas
mensagens Foram assinados e / ou criptografados de acordo com a política de segurança. A aplicação UA é esperado para ignorar qualquer mensagem
que não estão em conformidade com a política de segurança para o canal.

UMA SecureChannel é separado a partir da Sessão Aplicação UA; no entanto, uma única Sessão Aplicação UA só podem ser acedidos por
meio de uma única SecureChannel. Isto implica que o aplicação UA é capaz de determinar o que SecureChannel está associado com cada Mensagem
Uma pilha de comunicação que fornece uma SecureChannel mecanismo, mas que não permite que o aplicativo para saber o que

SecureChannel foi utilizado para uma dada mensagem não pode ser usado para implementar a SecureChannel Service Set.

A relação entre o Sessão Aplicação UA e a SecureChannel é ilustrado na figura

9. As aplicações UA utilizar a pilha de comunicação para a troca Mensagens. Primeiro, a
SecureChannel Serviços são usados ​para estabelecer uma SecureChannel entre as duas pilhas de comunicação, permitindo a troca de mensagens
de forma segura. Em segundo lugar, as aplicações UA usar o
Sessão service Set para estabelecer uma UA Session aplicação.

Cliente OPC UA OPC UA Servidor

Sessão
aplicação UA aplicação UA

Pilha comunicação Pilha comunicação

SecureChannel

Figura 9 - SecureChannel e serviços de sessão

Session Service Set

este service Set define Serviços utilizado para estabelecer uma ligação de camada de aplicação no contexto de uma Sessão em nome de um
usuário específico.

NodeManagement Service Set

O NodeManagement Service Set permite que os clientes para adicionar, modificar e excluir nós no AddressSpace. Estes serviços
oferecem uma interface para a configuração de servidores.

Ver Service Set

Visualizações são definidos publicamente, Servidor- subconjuntos criados do AddressSpace. a inteira AddressSpace
é o padrão Visão, e, por conseguinte, o Visualização de Serviços são capazes de operar em todo o
AddressSpace. Versões futuras do presente especificação pode também definir Serviços para criar Cliente
definiram Pontos de vista.
solte 1,04 21 OPC Unified Architecture, Part 1

o Visão service Set permite clientes descobrir Nó s numa Visão por navegação. navegação permite
clientes para navegar para cima e para baixo na hierarquia, ou seguir Referências entre Nó s contido no Visão. Desta forma, a navegação
também permite clientes para descobrir a estrutura do Visão.

Consulta Service Set

A consulta do conjunto de serviços permite aos usuários acessar o espaço de endereço sem navegar e sem conhecimento do esquema
lógico usado para armazenamento interno de dados.

Consultando permite clientes para seleccionar um subconjunto da Nó s numa Visão com base em alguns Cliente- critérios de filtro fornecidos. o Nó s seleccionados a
partir do Visão pela instrução de consulta são chamados de um conjunto de resultados.

servidores pode ter dificuldade para processar consultas que requerem acesso a tempo de execução de dados, tais como dados do dispositivo, que envolve
operações com uso intensivo de recursos ou atrasos significativos. Nestes casos, o Servidor
pode achar que é necessário rejeitar a consulta.

Atributo Service Set

o Atributo Service Set é usado para ler e escrever Atributo valores. Atributos são características de primitivas Nodes que são definidos por
OPC UA. Eles podem não ser definido por clientes ou
Servidores. Atributos são os únicos elementos do AddressSpace permitido ter valores de dados. Um especial Atributo, a valor do atributo é
utilizado para definir o valor de Variáveis.

Método Service Set

Métodos representam as chamadas de função de Objetos. Eles são definidos na Parte 3. Métodos são invocados e retornar após a
conclusão, se bem sucedido ou mal sucedido. tempos de execução para Métodos pode variar, dependendo da função que está a executar.

o Método Service Set define os meios de invocar Métodos. UMA Método é sempre um componente de uma Objeto. Descoberta é fornecido
através da navegação e consulta Serviços. clientes descobrir a
Métodos suportado por uma Servidor navegando para a posse objetos que identificam suas suportado
Métodos.

Porque Métodos pode controlar algumas das operações aspecto de plantas, chamada de método pode depender das condições ambientais
ou outros. Isso pode ser especialmente verdadeiro quando se tenta re -invoke um
Método imediatamente após ter concluído sua execução. Condições que são necessárias para invocar o
Método pode ainda não ter retornado ao estado que permite a Método para começar de novo. Além disso, alguns Métodos pode ser capaz de
suportar chamadas simultâneas, enquanto outros podem ter uma única chamada de execução de um determinado tempo.

MonitoredItem Service Set

o MonitoredItem Service Set é usado pela Cliente para criar e manter MonitoredItems. MonitoredItems monitor Variáveis, Atributos e EventNotifiers.
geram notificações quando detectam certas condições. eles monitoram variáveis para uma mudança de valor ou estado; Atributos para uma
mudança de valor; e EventNotifiers para recém-gerado Alarme e Evento relatórios.

Cada MonitoredItem identifica o item para monitorar e Inscrição para usar para publicar periodicamente
notificações ao Cliente ( ver 7.11). Cada MonitoredItem também especifica a taxa à qual o produto é para ser monitorizada (amostrada) e,
por variáveis e EventNotifiers, os critérios de filtro usado para determinar quando um Notificação está a ser gerado. critérios de filtro para Atributos
são especificadas pelo seu Atributo
definições na Parte 4.

A taxa de amostragem definidos para um MonitoredItem pode ser mais rápido do que a taxa de publicação do
Inscrição. Por esta razão, a MonitoredItem pode ser configurado para qualquer fila Todas as comunicações ou a fila apenas a última Notificação
para a transferência de pelo Inscrição. Neste último caso, o tamanho da fila é um.

Serviços MonitoredItem também definir um modo de monitorização. O modo de monitorização está configurado para desactivar de amostragem e
geração de relatórios, para permitir apenas a amostragem, ou para permitir que tanto a amostragem e geração de relatórios. Quando a amostragem
é ativado, o Servidor amostras do item. Além disso, cada amostra é avaliada para determinar se um Notificação deve ser gerado. Se assim for, o Notificação
está na fila. Se o relatório estiver ativada, a fila é disponibilizado ao Inscrição para a transferência.
OPC Unified Architecture, Part 1 22 solte 1,04

Finalmente, MonitoredItems pode ser configurado para provocar a comunicação de outros MonitoredItems. Neste caso, o modo de
monitoramento dos itens a relatar é tipicamente definido para a amostragem apenas, e quando o item provocando gera um Notificação, qualquer
fila notificações dos itens ao relatório são disponibilizados ao Inscrição para a transferência.

Subscription Service Set

o Subscription Service Set é usado pela Cliente para criar e manter Assinaturas.
Assinaturas são entidades que publicam periodicamente NotificationMessages para o MonitoredItem
atribuída a eles (ver 7.9). o NotificationMessage contém um colector comum, seguido por uma série de Notificações. O formato notificações é
específica para o tipo de item a ser monitorizado (ou seja
variáveis, Atributos, e EventNotifiers).

Uma vez criada, a existência de um Inscrição é independente do Sessão do Cliente com o Servidor.
Isso permite que um Cliente para criar uma Inscrição, e uma segunda, possivelmente um redundante Cliente, receber NotificationMessages a partir
dele.

Para se proteger contra não-utilização por clientes, Assinaturas têm um tempo de vida que configurado clientes
periodicamente renovar. Caso existam Cliente falha para renovar a vida, a vida útil expira eo Inscrição
é fechada pela Servidor. Quando um Inscrição está fechada, todas MonitoredItems atribuído ao
Inscrição são excluídos.

Assinaturas incluem recursos que suportam a detecção e recuperação de perdido Mensagens. Cada
NotificationMessage contém um número de sequência que permite clientes para detectar perdeu Mensagens.
Quando não há notificações para enviar dentro do intervalo de tempo de keep-alive, o Servidor envia um keepalive mensagem que contém
o número de sequência do próxima NotificationMessage enviei. Se um Cliente
não receber um mensagem após o intervalo keep-alive expirou, ou se ele determina que ele perdeu um Mensagem, ele pode solicitar a Servidor
para reenviar um ou mais Mensagens.

___________