Profiles no OPC UA

Existem duas características do OPC UA que são aparentemente incompatíveis: o elevado número de funcionalidades e a escalabilidade. Apenas como ilustração, o OPC UA disponibiliza:

  • um modelo de objetos poderoso capaz de integrar toda a informação disponibilizada em servidores DA, A&E, HDA.
  • um modelo completo de autenticação, autorização e criptografia.
  • várias opções de transporte, como SOAP/XML e UA TCP.
  • independência de plataforma.
  • mecanismos robustos de publicação de dados.

A escalabilidade foi um requisito primário para os projetistas das especificações do OPC UA. Assim, espera-se que aplicações OPC possam preencher ambientes desde um simples equipamento embarcado de baixo custo até uma estação poderosa responsável pelas operações ERP de uma empresa.

Porém, como garantir que apesar da heterogeneidade dos ambientes os produtos possam agregar todas as funcionalidades que o tornam um produto OPC UA?

Os profiles são a chave para gerenciar este problema. Os profiles, definidos na parte 7 da especificação, são agrupamentos de funcionalidades que as aplicações devem (no caso do profile ser mandatório) ou podem (no caso do profile ser opcional) implementar. No estabelecimento de uma sessão UA, o cliente e o servidor trocam os profiles (através dos seus certificados de software) que eles implementam, assim verificando se as funcionalidades requeridas pelas aplicações estão disponíveis.

Sendo mais específico, as funcionalidades são agrupadas em unidades de conformidade (”conformance units”, CUs daqui em diante). Como ilustração, vamos analisar uma CU definida para um servidor OPC UA:

Título: Session Base

Descrição: Suporte aos serviços CreateSession, ActivateSession e CloseSession, exceto o uso do ActivateSession para alterar o usuário da sessão.

Esta CU agrupa as funcionalidades de gerenciamento de sessões de um servidor OPC UA. Como o gerenciamento de sessões é algo inevitável, esta CU deve ser sempre implementada.

Os profiles são apenas agrupamentos de CUs. A parte 7 define as várias CUs e também como os profiles organizam tais CUs.

Como uma uma imagem (na verdade uma tabela) vale mais que mil palavras, vamos olhar um profile real. A OPC Foundation armazena aqui as CUs e os profiles definidos na parte 7. A lista de profiles é mantida pela OPC Foundation, que detem o direito de criar novos profiles, que eventualmente são espelhados nesta página.

Acesse a página, e no menu à esquerda, procure por Server Category -> Facets -> Core Server Facet. Este é um profile básico que todo servidor deve implementar. Note que o profile possui um URI (http://opcfoundation.org/UA-Profile/Server/CoreFacet), que é usado pelas aplicações para identificar os profiles disponíveis. Na tabela à direita, estão todas os CUs que compõe este profile. Em Session Services é possível encontar a CU que discutimos anteriormente, “Session Base”. Note que esta CU não é opcional, como supomos. Na última coluna da tabela podemos encontrar a descrição de qual profile a CU origina. Isto indica que um profile pode consistir de CUs e também de outros profiles. Para visualizar isto, selecione a opção “Show also conformance units from included profiles”, disponível no topo da página.

Para que toda essa complexidade? Não vivemos todos os anos de OPC DA sem essa parafernália toda? A resposta é que o número de funcionalidades presentes no OPC UA é muito superior ao número presente no OPC clássico, e não é razoável exigir que todas as aplicações implementem o conjunto completo. Os profiles são uma resposta adequada para essa nova situação.

Profiles no OPC UA

Certificação no OPC UA

O grupo que define o processo de certificação de produtos OPC UA (Compliance Working Group, coordenado pela OPC Foundation), do qual faço parte, está trabalhando intensivamente para que todas as ferramentas e casos de teste estejam disponíveis até o final do ano. A disponibilidade de ferramentas de teste durante o desenvolvimento dos produtos é fundamental. Infelizmente, no caso do OPC DA, o Compliance Test Tool (CTT) foi disponibilizado um bom tempo após o surgimento dos primeiros produtos, o que deu margem a alguns problemas de interoperabilidade.

Na última reunião do grupo, tivemos a oportunidade de conhecer o novo CTT, voltado para OPC UA, e a primeira impressão foi fantástica. Para quem já usou o CTT tradicional, basta lembrar que todos os testes eram “estáticos”, ou seja, a inclusão e correção de testes requerem recompilação da ferramenta, processo extremamente não interativo já que o código é mantido pela OPCF. No novo CTT, todos os testes são escritos em Javascript, permitindo fácil inclusão e alteração. Além disso, é possível incluir breakpoints no código de teste, facilitando a depuração. Como disse um dos colegas do grupo, é praticamente um Visual Studio dentro do CTT!

A ferramenta ainda se encontra em estágio alfa, e em pouco tempo estarei com ela em mãos. Mais notícias quando isto ocorrer!

Para quem quiser saber mais sobre certificação OPC, basta seguir este link.

Certificação no OPC UA

Buracos no PKI

Um assunto que precisei explorar um pouco para trabalhar com OPC UA foi PKI (Public Key Infrastructure). É um campo extenso, mas basicamente  o objetivo é associar entidades (usuários, máquinas, domínios) com sua respectiva chave pública de criptografia. A associação entre a entidade e a chave é feita por um certificado digital. Mesmo que você nunca tenha ouvido falar de um certificate digital, provavelmente já foi beneficiado por um dele. Quando você entra em um site de comércio eletrônico e aparece o “cadeadinho” no seu navegador, a identidade do site é comprovada pelo seu certificado. Isto garante que você está falando com o Submarino, por exemplo, e não com um possível impostor.

Mas quando recebo um certificado, como posso ter certeza que este certificado é falso? É aí que entra o papel dos CAs (autoridades certificadoras). Os CAs são responsáveis por verificar a identidade do solicitante do certificado antes de emiti-lo. Por isso, os CAs precisam ter ótima reputação, estarem acima de qualquer suspeita. Isso é alcançado através de auditorias constantes e também por regras claras para verificação de identidade.

O modelo PKI é muito interessante, porém conta com um elemento não tão confiável: o ser humano. Por exemplo, o que acontece se um CA fornece um certificado para uma pessoa que se diz responsável pelo domínio mozilla.com quando esta pessoa não tem qualquer relação com a Mozilla? Esta pessoa pode assumir a identidade do domínio para qualquer fim. Parece improvável que isto aconteça, não? Pois isto aconteceu no final do mês passado, e gerou um bocado de discussão do que fazer com o CA (no caso, a Comodo) e como controlar os possíveis estragos.

Para os interessados, o post contando a estória e a discussão na lista da Mozilla sobre como agir.

Buracos no PKI

OPC UA é complicado?

Um dos capítulos do livro “OPC Unified Architecture”, de Wolfgang Mahnke, Stefan-Helmut Leitner e Matthias Damm, aborda a suposta complexidade do OPC UA. Este capítulo foi disponibilizado para download através do página da OPC Foundation, e é uma leitura interessante para os curiosos sobre OPC UA. Pegue o capítulo aqui (requer a criação de uma conta, sem custo).

OPC UA é complicado?

UA and EDDL Demo – How the Things Come Together

Esse é o nome da apresentação que conduzi em 2006 (Munique) e 2007 (Phoenix) no OPC UA Developers Conference. Sendo muito breve, o objetivo foi apresentar um protótipo de um servidor OPC UA que expõe as descrições EDDL de equipamentos de campo. No evento de 2007, a OPC Foundation capturou o áudio e os slides expostos, e disponibilizou para download em seu site.

Pegue o vídeo aqui (requer a criação de uma conta, sem custo).

Para quem prefere o YouTube, o vídeo foi dividido em 2 partes: veja a parte 1 aqui e a parte 2 aqui.

UA and EDDL Demo – How the Things Come Together

RIP, Randy Pausch

Vinha acompanhando recentemente a trajetória do professor de ciência da computação Randy Pausch. O dr. Randy foi diagnosticado como portador de um câncer grave no pâncreas em agosto de 2006, passou por uma cirurgia e diversas sessões de quimioterapia. Em agosto de 2007, o câncer voltou e os médicos deram no máximo 6 meses de vida com saúde.

O dr. Randy encarou a doença de frente, e passou a dedicar seu tempo para construir lembranças para que seus três filhos pudessem “conhecê-lo”. Em setembro de 2007, o dr. Randy proferiu uma palestra na universidade Carnegie Mellon, onde lecionava, denominada “Atingindo seus sonhos de criança”. A palestra é uma aula de otimismo e de vida, e tornou-se um fenômeno graças à Internet.

Li recentemente que ele lançou um livro chamado “A Lição Final”, contando os detalhes da batalha contra a doença. Sábado passei na Paraler e vi o livro, e na segunda li que o dr. Randy faleceu na sexta-feira, dia 25.

O seu maior legado para a computação foi o projeto Alice, cujo objetivo é ensinar jovens a programar um computador “brincando” com personagens em um mundo 3D (o dr. Randy era um especialista em realidade virtual).

No Youtube é possível encontrar duas palestras completas do dr. Randy, a famosa sobre os sonhos de criança e uma interessante sobre gerenciamento de tempo (ele diz no começo que sabendo dos poucos dias de vida que ele tinha, tornou-se um especialista nisso!). Os links para as palestras são:

“Atingindo seus sonhos de criança”

“Gerenciamento de tempo”

Eu confesso que passei um bom tempo nos últimos dias pesquisando sobre a vida dele. Nos dias atuais em que as pessoas não valorizam a vida que tem, é realmente comovente “conhecer” uma pessoa assim.

Descanse em paz, dr. Randy Pausch!

RIP, Randy Pausch

Procurando servidores OPC no mundo DCOM

Passei a semana toda implementando os mecanismos de descoberta de servidores e de endpoints em nosso servidor UA, e esse assunto me trouxe lembranças dos problemas de descoberta de servidores OPC baseados em DCOM.

Todo componente DCOM armazena no registro as informações que o Windows necessita para partir o processo, configurar as opções de autenticação/autorização, e colocá-lo em modo passivo esperando por clientes ávidos por suas funcionalidades. Para quem não brincou com DCOM ainda, todo componente e toda interface são identificados por GUIDs. Como não é razoável esperar que um ser humano normal decore GUIDs, todo componente também ganha um nome mais amigável, o ProgId. Existem algumas boas práticas para nomear um componente com um ProgId, mas não vou entrar nessa discussão. Para ilustrar, alguns ProgIds de servidores OPC do System302, da Smar:

  • smar.snmpopcserver.0
  • smar.hseoleserver.0
  • smar.dfioleserver.0

A amarração GUID/ProgId também fica no registro. Uma funcão da API Win32 transforma ProgIds em GUIDs, permitindo selecionar o componente a ser instanciado.

Até agora tudo muito bonito, mas… como responder a uma pergunta básica como: “quais são os servidores DA versão 2.0 existentes em determinado nó da rede?”. Nos primórdios do OPC, a solução era arregaçar as mangas, aprender as nada simpáticas funções de navegação no registro e filtrar os servidores DA “na raça”. O filtro é viabilizado por um conceito chamado “CATID”, ou “Category Id”, que não é nada mais que outro GUID usado para agrupar diversos componentes DCOM em categorias. A OPC Foundation define (ou melhor, definia, DCOM é coisa do passado!) CATIDs para cada especificação de servidor OPC baseado em DCOM.

A coisa piorava para enumerar servidores remotamente, já que não é qualquer conta de usuário que tem permissão para fuçar no registro alheio. Um belo dia, uma mente privilegiada surgiu com a seguinte idéia: “por que não criamos um componente DCOM, que pode ser acessado por todo mundo (autenticação nula na sua configuração DCOM), que seja instalado em todo nó que possui um cliente ou servidor OPC e que se encarregue de fuçar no registro e disponibilizar o serviço de enumeração através de suas interfaces?”. Pronto, nasceu o “OPC Server Enumerator”, o vulgo OpcEnum!

O OpcEnum implementa a interface IOPCServerList, que retorna um enumerador de GUIDs dos aplicativos OPC registrados na máquina, além do ProgId. Com isto fica fácil instanciar o servidor desejado.

Após começar a trabalhar com UA, estou mais atento para vulnerabilidades na arquitetura OPC. O que impede que uma pessoa mal intencionada substitua o OpcEnum em uma determinada máquina por uma versão alterada, que pode, por exemplo, enumerar os GUIDs maliciosamente? Um exemplo simplista seria rotear o cliente para um servidor diferente, sem que o usuário perceba. Resposta para o mundo OPC-DCOM: nada impede. O cliente não dispõe de artifícios para verificar se o GUID fornecido pelo OpcEnum realmente é de quem ele deseja-se conectar. No OPC UA, no momento da criação de uma sessão o cliente tem informação suficiente para descobrir se está falando com quem deveria, mas isto é assunto para um post futuro!

Procurando servidores OPC no mundo DCOM