Em uma conversa com um cliente hoje sugeri alguns tópicos para rápido conhecimento sobre comunicação OPC os quais compartilho a seguir:
1. Em qualquer instalação de softwares OPC em sistemas operacionais MS Windows 7 ou superior é altamente recomendado clicar com o lado direito do mouse no executável e selecionar “executar como administrador” para evitar problemas de permissão após a instalação. Muitos problemas com softwares OPC ocorrem mesmo que o usuário tenha os direitos de administrador. Veja mais no artigo abaixo:
https://honeywellprocess-community.force.com/opcsupport/s/article/Why-use-the-Run-As-Administrator-option-in-Windows-7-and-Windows-2008
2. Na comunicação na mesma máquina entre cliente e servidor OPC é utilizado o COM do MS Windows e a identificação dos servidores OPC é feita pelo serviço OPC ENUM ou pelo registro do Windows. Em geral problemas para conexão na mesma máquina ocorrem por incidentes com permissão de usuário na instalação ou problemas no OPC ENUM/identificação via registro.
3. Na comunicação de clientes e servidores OPC em diferentes máquinas o DCOM do Windows é utilizado. Com a evolução dos sistemas operacionais as autorizações de acesso via DCOM tem se tornado cada vez mais restritas e isso se torna ainda mais complexo em ambientes de rede com firewall, sendo estes os maiores motivos dos problemas de conexão remota em OPC. Sugiro a leitura do artigo a seguir para detalhes das limitações e configuração do DCOM:
https://honeywellprocess-community.force.com/opcsupport/s/article/DCOM-Configuration
4. A comunicação OPC UA é a evolução do OPC clássico e não tem mais as limitações DCOM descritas acima, incluindo recursos de segurança por padrão. As principais aplicações OPC UA tem utilizado a arquitetura cliente – servidor OPC, as quais tem desempenho similar ao OPC clássico. Muitos fabricantes de controladores já tem embarcado OPC UA em seus controladores, assim como a maioria dos sistemas HMI/SCADA já inclui clientes OPC UA. Como os padrões OPC clássico e OPC UA não são compatíveis é necessário um software conversor para integrar sistemas com estes padrões, como o Matrikon OPC UA Tunneller por exemplo:
https://www.matrikonopc.com/opc-ua/products/opc-ua-tunneller.aspx
5. Um cliente OPC pode se conectar a múltiplos servidores OPC e vice versa. O principal limitante no desempenho OPC é quantidade de pontos por unidade de tempo (em geral tags/segundo), sendo que conexão com protocolos seriais (Modbus RTU por exemplo) tem valores bem menores que via ethernet. Como há diferentes interfaces na comunicação, incidentes quanto a performance devem ser investigados tanto na porta do controlador como nas configurações do servidor e do cliente OPC.
6. Servidores OPC tem se tornado plataformas para comunicação entre os mais diferentes sistemas, mas na maioria das soluções eles não armazenam dados. Dessa forma, na sua aplicação como conector de dados é necessário conhecer os tags no protocolo a ser convertido e a sintaxe utilizada pelo servidor OPC para acesso via cliente OPC. Alguns servidores OPC tem recursos para renomear tags e realizar cálculos para conversão de tipo e valores dos dados. Embora muitos servidores OPC listem automaticamente os dados após a conexão com o dispositivo ou sistema, é sugerido sempre verificar a seção do manual a respeito dos detalhes de sintaxe do servidor OPC especificos do fabricante.
Abaixo alguns links para uma introdução a comunicação OPC:
Introdução ao OPC (classic baseado em COM e DCOM)
https://www.matrikonopc.com/resources/opc-tutorials.aspx
2. Introdução ao OPC UA
2. Configuração dos softwares OPC clássico e OPC UA
No youtube há diversos vídeos mostrando o passo a passo para configuração de clientes e servidores OPC classico e OPC UA. No link abaixo indico o canal da INOVEX como referencia aos produtos Matrikon e vNode.
https://www.youtube.com/channel/UCzzpQl1SSn3LILcQoOnj_NA
