OPC Overview

OPC (OLE for Process Control)

is a series of standards specifications. The first standard (originally called simply the OPC Specification and now called the Data Access Specification) resulted from the collaboration of a number of leading worldwide automation suppliers working in cooperation with Microsoft. Originally based on Microsoft's OLE COM (component object model) and DCOM (distributed component object model) technologies, the specification defined a standard set of objects, interfaces and methods for use in process control and manufacturing automation applications to facilitate interoperability. The COM/DCOM technologies provided the framework for software products to be developed. There are now hundreds of OPC Data Access servers and clients available.

Adding the OPC specification to Microsoft's OLE technology in Windows allowed standardization. Now the industrial devices' manufacturers could write the OPC DA Servers and the software (like Human Machine Interfaces  HMI ) could become OPC Clients. 

The benefit to the software suppliers was the ability to reduce their expenditures for connectivity and focus them on the core features of the software. For the users, the benefit was flexibility. They don't have to create and pay for a custom interface. OPC interface products are built once and reused many times, therefore, they undergo continuous quality control and improvement. 

The user's project cycle is shorter using standardized software components. And their cost is lower. These benefits are real and tangible. Because the OPC standards are based in turn upon computer industry standards, technical reliability is assured. 

The original specification standardized the acquisition of process data. It was quickly realized that communicating other types of data could benefit from standardization. Standards for Alarms & Events, Historical Data, and Batch data were launched. 

Current and emerging OPC Specifications include: 

Specification	Description
OPC Data Access	The originals! Used to move real-time data from PLCs, DCSs, and other control devices to HMIs and other display clients. The Data Access 3 specification is now a Release Candidate. It leverages earlier versions while improving the browsing capabilities and incorporating XML-DA Schema.
OPC Alarms & Events	Provides alarm and event notifications on demand (in contrast to the continuous data flow of Data Access). These include process alarms, operator actions, informational messages, and tracking/auditing messages.
OPC Batch	This specification carries the OPC philosophy to the specialized needs of batch processes. It provides interfaces for the exchange of equipment capabilities (corresponding to the S88.01 Physical Model) and current operating conditions.
OPC Data eXchange	This specification takes us from client/server to server-to-server with communication across Ethernet fieldbus networks. This provides multi-vendor interoperability! And adds remote configuration, diagnostic and monitoring/management services.
OPC Historical Data Access	Where OPC Data Access provides access to real-time, continually changing data, OPC Historical Data Access provides access to data already stored. From a simple serial data logging system to a complex SCADA system, historical archives can be retrieved in a uniform manner.
OPC Security	All the OPC servers provide information that is valuable to the enterprise and if improperly updated, could have significant consequences to plant processes. OPC Security specifies how to control client access to these servers in order to protect this sensitive information and to guard against unauthorized modification of process parameters.
OPC XML-DA	Provides flexible, consistent rules and formats for exposing plant floor data using XML, leveraging the work done by Microsoft and others on SOAP and Web Services.
OPC Complex Data	A companion specification to Data Access and XML-DA that allows servers to expose and describe more complicated data types such as binary structures and XML documents.
OPC Commands	A Working Group has been formed to develop a new set of interfaces that allow OPC clients and servers to identify, send and monitor control commands which execute on a device.

The DCOM Architecture

DCOM is an extension of the Component Object Model (COM). COM defines how components and their clients interact. This interaction is defined such that the client and the component can connect without the need of any intermediary system component. The client calls methods in the component without any overhead whatsoever.

Figure 1: COM components in the same process

In today's operating systems, processes are shielded from each other. A client that needs to communicate with a component in another process cannot call the component directly, but has to use some form of interprocess communication provided by the operating system. COM provides this communication in a completely transparent fashion: it intercepts calls from the client and forwards them to the component in another process.

Figure 2: COM components in different processes

When client and component reside on different machines, DCOM simply replaces the local interprocess communication with a network protocol. Neither the client nor the component is aware that the wire that connects them has just become a little longer.
Figure 3 shows the overall DCOM architecture: The COM run-time provides object-oriented services to clients and components and uses RPC and the security provider to generate standard network packets that conform to the DCOM wire-protocol standard.

Figure 3: DCOM: COM components on different machines

Components and Reuse

Most distributed applications are not developed from scratch and in a vacuum. Existing hardware infrastructure, existing software, and existing components, as well as existing tools, need to be integrated and leveraged to reduce development and deployment time and cost. DCOM directly and transparently takes advantage of any existing investment in COM components and tools. A huge market for off-the-shelf components makes it possible to reduce development time by integrating standardized solutions into a custom application. Many developers are familiar with COM and can easily apply their knowledge to DCOM-based distributed applications.

What is OPC Server Development?

An OPC Sever is a software application that acts as an API (Application Programming Interface) or protocol converter. An OPC  Server will connect to a device such as a PLC, DCS, RTU, etc or a data source such as a database, HMI, etc and translate the  data into a standard-based OPC format. OPC compliant applications such as an HMI, historian, spreadsheet, trending  application, etc can connect to the OPC Server and use it to read and write device data. An OPC Server is analogous to the  roll a printer driver plays to enable a computer to communicate with an ink jet printer. An OPC Server is based on a  Server/Client architecture.

There are many OPC Server Development toolkits available for developing your own OPC Server; MatrikonOPC's Rapid OPC Creation  Kit (ROCKit) is one of it and enables quick OPC Server development. ROCKit offers a flexible and affordable solution that  enables programmers to fully control their own product.

OPC ROCKit packages the complete OPC interface into a single DLL, eliminating the need to learn the complexities of Microsoft  COM, DCOM or ATL. A developer simply writes the communication protocol routines for the underlying device and ROCKit takes  care of the OPC issues.

Features include:

- Fully compliant with OPC DA 1.0a, 2.05 and 3.0 specifications.
- Free threading model on Windows NT, 2000 and XP platforms.
- Supports self-registration, browsing, data quality reporting, and timestamps.
- Can be used as a stand-alone server or as a service.
- In-proc server design for high-performance communication.
- Sample application code and comprehensive documentation illustrating how to use the ROCKit.
- OPC Explorer client that exercises the OPC COM interface for testing and debugging your server.
- The interface to the Device Specific Plug-in application code is separate from the OPC COM interface code. This means that  future OPC source code updates are simply plugged in, while your own protocol code remains untouched, resulting in minimal  engineering effort.

What are Realtime Operating Systems RTOS?

A real-time operating system (RTOS) is a class of operating system intended for real-time applications. Such applications include embedded (programmable thermostats, household appliance controllers, mobile telephones), industrial robots, spacecraft, industrial control (e.g. SCADA), and scientific research equipment.

A RTOS facilitates the creation of a real-time system, but does not guarantee the finished product will be real-time; this requires correct development of the software. A RTOS does not necessarily have high throughput; rather, a RTOS provides facilities which, if used properly, guarantee deadlines can be met generally ("soft real-time") or deterministically ("hard real-time"). A RTOS will typically use specialized scheduling algorithms in order to provide the real-time developer with the tools necessary to produce deterministic behavior in the final system. A RTOS is valued more for how quickly and/or predictably it can respond to a particular event than for the given amount of work it can perform over time. Key factors in an RTOS are therefore minimal interrupt and thread switching latency.

A significant problem that multitasking systems must address is sharing data and hardware resources among multiple tasks. It is usually "unsafe" for two tasks to access the same specific data or hardware resource simultaneously. ("Unsafe" means the results are inconsistent or unpredictable, particularly when one task is in the midst of changing a data collection. The view by another task is best done either before any change begins, or after changes are completely finished.)

General-purpose operating systems usually do not allow user programs to mask (disable) interrupts, because the user program could control the CPU for as long as it wished. Modern CPUs make the interrupt disable control bit (or instruction) inaccessible in user mode to allow operating systems to prevent user tasks from doing this. Many embedded systems and RTOSs, however, allow the application itself to run in kernel mode for greater system call efficiency and also to permit the application to have greater control of the operating environment without requiring OS intervention.

What are Manufacturing Execution Systems?

A Manufacturing Execution System (MES) is system that companies can use to measure and control production activities with the aim of increasing productivity and improving quality.

A Manufacturing Execution System MES is a shop floor control system which includes either manual or automatic labor and production reporting as well as on-line inquiries and links to tasks that take place on the production floor. MES includes links to work orders, receipt of goods, shipping, quality control, maintenance, scheduling, and other related tasks.

The ISA has defined standards regarding the structuring of MES and its integration in a larger company-wide IT architecture. ISA-95 "Enterprise-Control System Integration" defines a layer model looking at the integration aspects between ERP, MES and the production control level. It is supported by several vendors in the MES area. ISA-S88 "General and Site Recipe Models and Representation" defines a process state model for the batch industry.

What is CMMS Software?

Computerized maintenance management system (CMMS) software and enterprise asset management (EAM) software is used to manage  maintenance operations on capital equipment and other assets and properties. CMMS software and EAM software helps maintenance  personnel and departmental managers make better decisions for the allocation, maintenance, scheduling and disposal of  equipment and properties.

Computerized maintenance management software includes features such as work order generation, event logs, scheduling of  preventive maintenance checks and services, and downtime analysis. CMMS software also allows users to plan equipment  maintenance activities to coincide with the schedules of employees such as technicians, mechanics, and operators. Maintenance  management reporting may also be included. CMMS software can be industry-specific or designed for a range of industries such  as transportation, energy and utilities, manufacturing, engineering, and automation.

Enterprise asset management software is designed to improve operational productivity and processes, and track, manage, and  extend the life of critical assets. With EAM software, corporate managers and executives can monitor the status of plants,  buildings and facilities or develop a plan for inventory control. EAM software features include modules to define assets,  track asset usage, maintain asset documents (i.e., warranties, lease agreements, and contracts), and flag assets for  maintenance or other event triggers.

The strongest feature set of CMMS software and EAM software is the ability to integrate the two products into a single  maintenance and management solution. Such integration permits more efficient interaction between various departments within  an organization. For example, when an asset is reported as damaged, service requests can be entered into the system and an  alert immediately sent to maintenance personnel. Mechanics or engineers can then inspect the asset, open work orders, and  alert purchasing agents of any need for the procurement of parts, tools, or other materials to perform repairs. Managers can  run regular reports to identify areas of repeated failure or those assets that cost the most to retain and repair. This  permits the proper distribution of budgeted funds, or implementation of better maintenance and management processes.