OPC and DCOM/COM Issues

My working experience with OPC and DCOM/COM can be tracked back to more than 10 years ago. I remember that when I was working at a SCADA software company in Calgary, I was assigned to a project to write OPC Client app. OPC technology is based on Microsoft Windows DCOM/COM infrastructure to provide automation for industries. At that time, it was very advanced technology and has been quickly adopted by many industry companies, specially in SCADNA system.

Since then, I have been on and off on OPC development and support. Even COM was very nice library based design infrastructure, it has it is drawbacks. Microsoft has been moved to .Net based infrastructure, COM and DCOM becomes old technology. However, so many software and applications have been developed and they are in use in various systems, it is really hard to cut it off.

Recently I have been working on a project to build a new historian system. The system is based OPC technology. In the past week, I have been working to set up a new historian system. I expected OPC configuration being the hardest task. Basically, an OPC client application has be set up to communicate with a remote OPC server. I have been struggled for almost a week on the project. I almost reached the point to make them to talk. The OPC client could talk to the remote OPC server by using local Administrator, but not a domain user. The DCOM settings on the OPC server side should be OK since we have a production OPC Client collecting data. It is just a new Windows 2008 Server not being able to collect data. Windows 2008 Server is a kind of Windows Vista, which is based on a more complicated secure framework, such as firewall, network configuration and system security configurations, in addition to OPC configurations.

My past experience and my knowledge in this area still benefit me a lot for my current work. I have changed my careers in a wide range of areas. Never know what you have done may continue to impact your future.