OPC for CRISP Automation
OPC is an industry-standard protocol for process automation. CRISP Automation
can use OPC in several different ways:
- OPC server on CRISP
- OPC client for IDI
- OPC server for I/Onyx
- OPC server for CC Server
These have the advantages of:
Allowing customers to replace the CRISP HMI with any OPC compliant package, i.e. Wonderware, Intellution, InduSoft, etc.
Provide a generic way for CRISP’s IDI product to control OPC devices without having to create drivers for each new device.
Provide a way for CRISP customers to replace everything but the CRISP
I/Onyx I/O and CC Servers communicating with CRISP Classic I/O. This would allow customers to replace the entire CRISP/32 VAX-based control system with any OPC compliant DCS or SCADA package.
Phase 1: Part A: OPC Server on CRISP
Introduction
An Alpha can serve CRISP data via the OPC protocol. The CRISP OPC Server
can run on the same Alpha that CRISP Alpha is running on. Or for those
customers with CRISP on VAX, the server does not have to be running CRISP;
instead,
it
can communicate with both Alphas and VAX’s that are running CRISP. This
allows our customers running on VAX’s or a mixture of VAX’s
and Alphas to utilize the OPC Server technology.
Benefits
There are several benefits of this project:
The custom CRISPview network driver can be retired, since Indusoft and other
MMI solutions act as OPC clients.
Existing CRISP/32 systems will be able to interoperate with other industry-standard
systems.
Background
Every CRISP system has a Database Access Server, known as the DBASRV.
This process serves real-time data across three interfaces: the Software
Bus, IEEE 802.3 messages, and UDP/IP.
An existing API is available which can communicate with the DBASRV
on every system. This API is already available for Alpha OpenVMS
systems. It can
be installed on a system on which CRISP is not installed. This
API is
known as WORF.
Platform: Alpha OpenVMS
Because a critical code piece known as “DCOM” is
available only for Alpha, the OPC server will only be provided
for Alpha.
However, WORF can communicate with all CRISP systems across the
network using IEEE 802.3 messages. Existing VAX customers can
install a small
Alpha (about
$1000 on the used market) and begin accessing their data via
OPC immediately. This can ease their migration to Alpha.
Because the code does not have to carry the VAX C baggage, it
will be easy to port to Itanium.
Requirements
All necessary CRISP development systems exist. Remote access
for subcontractors is available.
Solution Process
Create an OPC server “front end”. This will be the published
entry point for accessing CRISP data.
Use the WORF API to access CRISP data on the “back end”.
Phase 1: Part B: OPC Client for IDI
Introduction
The IDI product, which is a layered product of CRISP, is used to communicate
with and control external devices. These devices include Programmable Controllers
(“PLC”) , Single Loop Controllers, Intelligent I/O Subsystems,
Weigh Systems, etc.
Some of these devices are now coming with OPC interfaces.
Benefits
There are several benefits of this project:
Existing CRISP customers can use the latest devices.
A single IDI driver can be used for multiple devices.
When Phases 2 and 3 are complete, I/Onyx and CC Server appear as just another
OPC devices. Complicated support code can be eliminated.
Background
IDI has a standardized structure for controlling a device. Creating a new
device driver is relatively straightforward. At a minimum, an IDI driver
needs the
following capabilities:
- Initialization and connection to the device
- Graceful shutdown of connection
- Read data
- Write data
The important parameters for the driver include:
- Address of device
- Name of variables to read from the device
- Name of variables to write to the device
- Where these variables are mapped into CRISP databases
Platform: Alpha OpenVMS
Because a critical code piece known as “DCOM” is available
only for Alpha, the OPC client can only be provided for Alpha.
Therefore, only IDI
on Alpha can have this capability.
Requirements
All necessary CRISP development systems exist. Remote access for
subcontractors is available.
A device with an OPC server interface must be available. Initially,
this could be a CRISP system with an OPC server from Phase
1 Part A.
Solution Process
Using the IDI driver template, create a list of functions that
are needed.
Implement those functions in the OPC client program.
Phase 2: OPC Server for I/Onyx
Introduction
A present CRISP client wishes to abandon OpenVMS. They want to keep their
current I/Onyx hardware, but move to an Intel platform. The client wishes
to control
the I/O hardware using OPC. They also want a dual system, either of which
can control the I/O, to guard against hardware failure.
Benefits
There are several benefits of this project:
Expensive replacement of existing CRISP I/Onyx is not required
No extensive plant down time required in switching over to a non-CRISP SCADA
or DCS System.
Background
Operation of I/Onyx hardware is built into CRISP/32. The source code is
written in C, but is VMS-specific. The following pieces are part of CRISP/32
that
have to be modified:
ICF Used to configure the I/O hardware and how it is mapped to a database.
ICM Sends configuration data to the I/O hardware, and monitors hardware
status.
LGS Performs the I/O operations with the hardware. This is compiled into
a user-written control program, called a “logic”.
There are several configuration files, which can be used on Intel without
change.
Communications from ICM and LGS to the I/Onyx Module Server uses IEEE
802.3 messages. Each Module Server connects to a cabinet of I/O modules,
which
it controls.
The three pieces share a common API to perform the necessary communications
with the Module Server(s). The API has two levels:
I/Onyx-specific code
802.3 messaging
Platform: Microsoft Windows
Requirements
All necessary systems exist. Remote access for subcontractors is available.
Salem Automation will have to supply a small quantity of I/Onyx hardware
for unit testing.
Solution Process
Create an OPC server “front end”. This will be the
published entry point for accessing I/Onyx data. Use the code from
Phase 1
as a starting point.
The OPC server’s “back end” will interface with
processes that are functionally identical to their CRISP counterparts.
Phase 3: OPC Server for CC Server
Introduction
A present CRISP client wishes to abandon OpenVMS. They want to keep
their current CC Server hardware, but move to an Intel platform.
The client
wishes to control
the I/O hardware using OPC. They also want a dual system, either
of which can control the I/O, to guard against hardware failure.
Benefits
There are several benefits of this project:
Allows customer to keep his CRISP Classic I/O without expensive replacement.
No extensive plant down time required in switching over to a non-CRISP
SCADA or DCS System.
Background
Operation of CC Server hardware is built into CRISP/32. The source
code is written in C, but is VMS-specific. The following pieces
are part of
CRISP/32
that have to be modified:
CCF Used to configure the I/O hardware and how it is mapped
to a database.
CCM Sends configuration data to the I/O hardware, and monitors
hardware status.
Calls Performs the I/O operations with the hardware. This is
called from a user-written control program, called a “logic”.
There are several configuration files, which can be used on
Intel without change.
Communications from CCM and Calls to the CC Server uses IEEE
802.3 messages. Each CC Server connects to a cabinet of I/O
modules, which it controls.
The three pieces share a common API to perform the necessary
communications with the CC Server(s). The API has two levels:
CC Server-specific code
802.3 messaging
Platform: Microsoft Windows
Requirements
All necessary systems exist. Remote access for subcontractors
is available. Salem Automation will have to supply a small
quantity of CC Server
hardware for unit testing.
Solution Process
Use the OPC Server code from Phase 3 as a starting point.
The OPC server’s “back end” will interface with processes
that are functionally identical to their CRISP counterparts.
Use the IEEE 802.3 messaging code developed in Phase
2 as a starting
point.
