OPC background
A standard mechanism for communicating to numerous data sources, either devices on the factory floor, or a database in a control room is the motivation for OPC. An example of the information architecture for the Process Industry involves the following levels:
- Field Management. Information not previously available for "smart" field devices can be provided. This information provides data on the health of a device, its configuration parameters, materials of construction, and so on. This information must be presented in a consistent manner.
- Process Management. The installation of Distributed Control Systems and SCADA systems to monitor and control manufacturing processes makes manually gathered data available electronically.
- Business Management. Benefits can be gained by installing the control systems. This is accomplished by integrating the information collected from the process into the business systems managing the financial aspects of the manufacturing process. Providing this information in a consistent manner minimizes the effort required to provide this integration.
To accomplish this, manufacturers must access data from the plant floor and integrate it into existing business systems. They must be able to use off the shelf tools such as SCADA packages, databases, and spreadsheets to assemble a custom system. The key is an open communication architecture that concentrates on data access rather than data types.
Current Client Application Architecture
Many client applications access data from a source by independently developing "drivers" for their packages. This leads to the following problems:
- Duplication of effort. Everyone must write a driver for a particular vendor's hardware.
- Inconsistencies between vendors drivers. Hardware features not supported by all driver developers.
- Support for hardware feature changes. A change in the hardware's capabilities may break drivers.
- Access Conflicts. Two packages generally cannot access the same device simultaneously since they each contain independent drivers.
Hardware manufacturers attempt to resolve these problems by developing drivers, but are hindered by differences in client protocols. They cannot develop an efficient driver that can be used by all clients.
Custom Application Architecture
OPC draws a line between hardware providers and software developers. A vendor can develop a reusable, optimized server to communicate to the data source, and maintain the mechanism to efficiently access data from the data source/device. Providing the server with an OPC interface allows any client to access the device.
Custom applications are developed in environments like Visual Basic (VB), Delphi, Power Builder, and so on. OPC takes this trend into account. Microsoft understands this trend and designed OLE/COM to allow components written in C and C++ for a specific domain to be used by a custom program written in VB or Delphi for an entirely different domain. Developers write software components in C and C++ to encapsulate the intricacies of accessing data from a device, so business application developers can write code in VB that requests and uses plant floor data. The intent is to facilitate the development of OPC servers and OPC client applications in the language of choice.
Provide Feedback