OPC Tunnel 点击：4017 | 回复：7
发表于：2007-12-04 10:51:00
5楼
以下是转载：
COM/DCOM: The Basis of OPC
When OPC applications are installed on the same computer, they use Microsoft’s COM (Component Object Model) technology to exchange data. But, when installed on 2 separate PCs, they use DCOM (Distributed COM) for the data exchange. Unfortunately, OPC developers have no programmatic control over DCOM, and are thus bound by DCOM’s limitations. Consider two OPC applications that are installed on two PCs on two different Domains. Clearly, their OPC communication must use DCOM. Consequently, the Domains must share at least one common username and password. This can be a serious issue, especially when these domains and applications are owned by different groups (IT and Process Control), different vendors (two different DCS vendors), or even different businesses altogether (when plants must share information). OPC applications from any vendor will be stopped dead in their tracks, unless this DCOM issue can be overcome. While these may be simple technical hurdles that are easy to overcome, they may also present serious political issues.
Tunneling Eliminates DCOM
DCOM problems can sometimes be overcome with a few hours of work and good corporate maneuvers (politics). But, another approach is to eliminate DCOM altogether with Tunneling technology. In this case, an OPC Tunneller is placed on each of the two PCs. Each OPC Tunneller object communicates with its local OPC application using reliable COM. The two OPC Tunneller objects are then free to exchange data via any appropriate communication technology, such as TCP/IP, HTTP, HTTPS, XML, etc. The data transport technology can be selected by either the user or programmer to accommodate for the special needs of the required design. Third party passwords are immediately nullified, Domains become irrelevant, and network performance (bandwidth and reliability) is a non-issue. Thus, each OPC Tunneller has two objectives: to transfer the data in the most reliable way to the other OPC Tunneller object, and to translate all data back to standards-based OPC, so that the communication remains persistent and consistent. The result? All of the headaches typically associated with DCOM are alleviated. Specifying an IP address or computer name within OPC is all that is required.
COM/DCOM: The Basis of OPC
When OPC applications are installed on the same computer, they use Microsoft’s COM (Component Object Model) technology to exchange data. But, when installed on 2 separate PCs, they use DCOM (Distributed COM) for the data exchange. Unfortunately, OPC developers have no programmatic control over DCOM, and are thus bound by DCOM’s limitations. Consider two OPC applications that are installed on two PCs on two different Domains. Clearly, their OPC communication must use DCOM. Consequently, the Domains must share at least one common username and password. This can be a serious issue, especially when these domains and applications are owned by different groups (IT and Process Control), different vendors (two different DCS vendors), or even different businesses altogether (when plants must share information). OPC applications from any vendor will be stopped dead in their tracks, unless this DCOM issue can be overcome. While these may be simple technical hurdles that are easy to overcome, they may also present serious political issues.
Tunneling Eliminates DCOM
DCOM problems can sometimes be overcome with a few hours of work and good corporate maneuvers (politics). But, another approach is to eliminate DCOM altogether with Tunneling technology. In this case, an OPC Tunneller is placed on each of the two PCs. Each OPC Tunneller object communicates with its local OPC application using reliable COM. The two OPC Tunneller objects are then free to exchange data via any appropriate communication technology, such as TCP/IP, HTTP, HTTPS, XML, etc. The data transport technology can be selected by either the user or programmer to accommodate for the special needs of the required design. Third party passwords are immediately nullified, Domains become irrelevant, and network performance (bandwidth and reliability) is a non-issue. Thus, each OPC Tunneller has two objectives: to transfer the data in the most reliable way to the other OPC Tunneller object, and to translate all data back to standards-based OPC, so that the communication remains persistent and consistent. The result? All of the headaches typically associated with DCOM are alleviated. Specifying an IP address or computer name within OPC is all that is required.
热门招聘
相关主题
- VC Help
[1633] - OPCServer的注册问题[2505]
- 免费OPC转Modbus[14274]
- OPCDA客户端OCX控件[3410]
- 不懂safearray在delphi中怎么...[2521]
- OPC Group对象的DataChange事...[3840]
- 欢迎ModbusOPCServer2.0测试[13531]
- 新人不懂OPC是什么东西[9958]
- WINCC之OPC通信------[4158]
- OPC服务端软件分析[1789]
官方公众号
智造工程师
-
客服
-
小程序
-
公众号
工控网智造工程师好文精选
