Com qualquer tecnologia amplamente implementada, surgem discussões sobre suas limitações ou deficiências. OPC não é exceção. Com o recente lançamento do OPC UA (Arquitetura Unificada), há muita especulação sobre se ele realmente resolve ou não os problemas existentes do OPC.
Antes do OPC UA, a reclamação mais comum era que os padrões OPC existentes eram principalmente Baseado em COM. OPC UA é uma solução multiplataforma baseada em serviços e não mais Microsoft centrado. Tirando esse problema, a maioria das outras reclamações se concentra nas especificações que não vão longe o suficiente em seu escopo de padronização. Há críticas de que o OPC não faz o suficiente para exigir segurança, configuração e fornece um espaço de endereço unificado ou “mapeamento” de item definido.
Se você considera o OPC como o padrão para comunicação de dados em tempo real, independentemente dos dados fonte, levanta uma questão interessante. Onde a linha é cruzada em uma interface geral especificação que seja aberta, interoperável e flexível sem sacrificar a usabilidade, para uma que seja especializada, rigidamente definida e altamente integrada?
A maioria concordaria que os padrões OPC existentes erram por excesso de cautela e focam especificações no nível da interface. Se você reduzir um servidor OPC à sua essência; representa o acesso a uma fonte de dados, apresenta um espaço de endereço que define os itens de dados disponíveis, fornece informações primitivas sobre cada item de dados (identificador, tipo de dados, acessibilidade) e tem a capacidade para ler e atualizar o valor de cada item de dados. OPC não exige nomeação de identificador convenções, parâmetros de configuração e regras para federar aplicativos ou segurança detalhada modelos.
No entanto, as especificações também não excluem essas coisas, ao contrário, elas as deixam decisões para a implementação do produto OPC. Muitos argumentariam que é essa simplicidade que é um dos pontos fortes do OPC e contribuir para sua ampla adoção. Uma fonte de dados do servidor OPC pode ser um PLC, DCS, banco de dados relacional, documento XML, página da Web, tag RFID, controlador HVAC ou uma das muitas outras possibilidades.
Eles têm semântica variada, casos de uso e implementação aceita convenções, ainda hoje, todos se comunicam usando OPC, apesar das coisas deixadas para implementação. Tão que incentivo existe para os fornecedores implementarem recursos que não são obrigatórios?
Há um argumento de que os verdadeiros “padrões abertos” não evoluem porque os fornecedores desejam manter sua vantagem proprietária e, como resultado, implementam apenas os requisitos básicos abertos. No entanto, confiar no conhecimento proprietário para manter e aumentar a participação no mercado é uma visão de curto prazo.
Como os usuários tentam equilibrar o conforto de um único fornecedor de origem com o desejo de flexibilidade, inovação e preços competitivos, eles inevitavelmente migram para soluções abertas que lhes dão opções onde eles precisam. OPC é suportado por muitos fornecedores concorrentes de cada fornecedor vantagem competitiva vem de como os recursos além das especificações básicas são implementados em suas ofertas de produtos. Há muito que a especificação não pode ditar e é governado por como a implementação é feita.
Existem muitos produtos OPC excelentes no mercado que possuem implementou muito bem esses aspectos da interface. Infelizmente, o usuário final não pode confiar em eles estarem em todos os produtos OPC que compram. Embora tenham base padrão comunicação isso não significa necessariamente que eles tenham um sistema verdadeiramente interoperável. Adicional é necessária a padronização no nível de integração do sistema ou da empresa.
Para atingir essa visão do OPC em toda a empresa, as especificações do OPC UA abordam vários aspectos de interface, incluindo um modelo de dados complexo e semântica de informação unificada, segurança e redundância. Então, como uma especificação pode exigir padrões detalhados para todas essas coisas, independentemente do aplicativo, fonte de dados ou caso de uso? Realisticamente, não pode.
O melhor que pode fazer é fornecer o denominador comum básico desses aspectos, mas, mais importante, fornecer um padrão maneira de estender o modelo de informação e descobrir programaticamente os níveis individuais de Apoio, suporte. É para isso que o OPC UA foi projetado. O resultado é uma especificação que é mais abrangente do que apenas os detalhes da interface, de modo que os usuários possam esperar suporte de nível básico OPC UA – Até onde vai a padronização da interface? 2 para elementos como segurança, redundância, navegação de namespace e modelos de informações mais ricos.
No entanto, a inovação na implementação ainda será um fator diferenciador nos produtos OPC UA, especialmente naqueles projetados para aprimorar ou federar instalações OPC existentes. Diante disso, OPC UA também oferece um processo de certificação mais abrangente para garantir a interoperabilidade entre os graus variados de implementação do produto.
Eric Murphy, Engenheiro de Projeto de Sistema de Arquitetura Avançada, MatrikonOPC
Eric Murphy, BSc, PEng (Alberta), Eric é Engenheiro Químico com especialização em Controle de Processos e um especialista em OPC. Eric faz parte da comunidade OPC desde seu início na meados da década de 1990. Eric está fortemente envolvido com a OPC Foundation e atualmente atua como presidente da Grupo de trabalho OPC Historical Data Access (HDA). Eric também é membro do Comitê Técnico da OPC Steering Committee (TSC) e um membro ativo da OPC Unified Architecture (UA) trabalhando grupo.
