OPC & DCOM DIAGNOSTICS AND OPC Date : 30/03/2009

SECURITY

DOMAIN : ENGINEERING

Knowledge Management System

Area : C&I

Title of the Programme : OPC & DCOM Diagnostics and

OPC Security

Name of the Company visited : OPC Training Institute

Date & Venue : 24/02/2009 to 27/02/2009, Singapore.

Key Words : OPC tunneling, Kepware server, Connectivity, Firewall,

Complexity

Submitted by : R. Sarangapani ,CDE(C&I) , 9868390571,

sarangapani@ntpceoc.co.in.

30/03/2009
 TRAINING ON

OPC & DCOM DIAGNOSTICS

AND
OPC SECURITY

FROM 24rd FEBRUARY TO 27th FEBRUARY, 2009

AT
TRAINING CHOICE , SINGAPORE
( ORGANISED BY OPC TRAINING INSTITUTE )

Participant Signature of participant Signature of HOD

R. Sarangapani ,CDE(C&I)
 FOREIGN TRAINING LEARNING REPORT
1
1.1 Name of the Program Level 1: OPC & DCOM Diagnostics
& Level 2: OPC Security
1.2 Duration 24th February 2009 to 27th February
2009 ( Two days for each level – Total
four days
1.3 Country visited Singapore
1.4 Name of the OPCTI( OPC Training Institute).
Industry/Company visited as Training was conducted at Training
part of Training choice, Singapore
2 Key Learning:
2.1 List of topics covered: List of topics covered in both the levels is
enclosed at Annexure-A. A brief write up on OPC is enclosed at
Annexure-B.
2.2 Key learning points: The key learning points for each topic are also
described at Annexure-A. For each topic, the presentation was followed
by hands on session in which Kepware server & OPC Quick Client
software was used. Basic connectivity by selecting items in a group was
set up, followed by various variants in the settings. The steps to
configure DCOM for establishing OPC connectivity was covered. In
each topic, the implication of the setting on the OPC connection was
practically demonstrated. Many trouble shooting examples were
included to illustrate the concepts. Firewall configurations were
explicitly covered along with working knowledge of establishing OPC
communications through firewalls.
2.3 Learning Setup: Training Choice, where the training was conducted
provided a conducive atmosphere for training. Each participant was
provided a computer, networked with the instructor’ computer. There
were in all 21-22 participants in both the levels. The complete training
material ( presentation slide handouts) was made available at the very
start of the course. Copy of the same is enclosed with this learning
report. (For internal circulation only).
2.4 Tests: At the end of Level-1 course, all participants gave a multiple
choice exam on their PC. The exam paper was discussed at the end to
reinstate the concepts. At the end of Level-2 course, all the knowledge
gained were put to test by having all participants to connect the OPC
server of instructor from their PC with a configuration messed up
deliberately.
 2.5 Certification: Copy of the certification received from OPC Training
Institute is enclosed at Annexure-C.
2.6 Quality of Training: The quality of training provided by the instructor
was good. The instructor from OPCTI, Canada kept the class going with
his enthusiasm & humor. However, the coverage given to topics could
have been more proportionate to their complexity. More time was
needed for complex topics than the generic ones. Further, one assisting
staff could have helped the instructor attend the participants problems
during hands on sessions. As regards content, OPC specifications were
not covered in sufficient details as expected; the stress was more on
getting OPC communications through. These feedbacks have been
conveyed in the on line feedback requested at the end of the course.
3 New Concepts Covered:
3.1 OPC as a communication interface with control system: OPC is
presently used in NTPC & the power industry at large, for
communications of DCS with a third party system such as PLC /PADO
or between DCS of SG-TG package & DCS of Station C&I package.
However, in most of the examples covered in the training course ( which
were also real life examples) , OPC was used for direct communications
with the PLC or DCS, thereby substituting the HMI server of the
DCS/PLC. Thus, OPC as an true DCS/PLC API has more potential than
its present use.
3.2 OPC communications with a firewall: OPC tunneling techniques were
explained for making through OPC communications through a firewall.
The tunneling software usually comes with the same vendors supplying
generic OPC software. OPC foundation does not include any
specifications for tunneling software. Another option for OPC
communications through a hardware firewall without using any
tunneling software is to use OPC XML DA, as this OPC version does
not use DCOM. This needs to be further deliberated with DCS vendors
during the finalization of the Station LAN.
4 New Trends/Practices:

a) OPC Unified architecture standard, the latest standard in draft, will

 overcome many of the limitations of current OPC specifications & many
improvements ( Eg, incorporation of a heartbeat exchange signal
between OPC server & client for verifying healthiness of OPC
communications) are being incorporated. Redundancy is now made part
of the specifications. Further, OPC versions in UA will be backward
compatible making life more easier.

b) OPC usage also is now getting extended to the core of the control
system. Example, in a combined cycle power plant in China, OPC
communications has been put into use for a common HMI for the entire
power station. The HMI of steam turbine has been retained in the
Programmer’s room. Similarly, in Ras Laffan project in Doha, Qatar,
steam turbine is being operated through a single HMI, which is not its
native HMI.
5 Applications of Learning:

5.1 Station LAN design: More insight was obtained regarding Firewall
penetration with OPC. Although OPC tunneling was taught as a solution
for OPC communications through firewall; it was a surprise that OPC
Foundation does not give any specification for OPC tunneling. More
alternatives like OPC XML emerged for OPC communications through a
firewall. This will be further taken up with DCS vendors. Further, it was
heartening when the present architecture for Station LAN design being
followed incorporating security concepts like DMZ zone was
appreciated by the instructor.
5.2 Uniform HMI project: As brought out in 3.1 above, OPC server directly
interfaces the control system as an API & OPC client acts as an HMI in
many cases in the course. This has triggered a new concept, which can
be pursued further with DCS vendors. i.e. use of OPC can be used as a
tool for providing a uniform HMI platform; One single HMI acting as
OPC client can interface to multiple OPC servers of different DCS of
multiple packages. Attempts can be made in this direction subject to
issues relating to performance guarantee & response times getting
addressed adequately.
5.3 Reduction of PC hardware in CCR areas: OPC, being based on client-
server architecture, can help in server consolidation in the plant O&M
area. At present, every application ( Eg, vibration analysis, performance
optimization, boiler flame analysis etc) is on a separate hardware with
the client & server functionality combined in the hardware. If the above
 applications are made OPC compliant ( i.e. all the processing part of the
software as OPC server & the user interface part as OPC client),
hardware can be substantially reduced. OPC clients can be directly
installed on the desktops of the end users. ( Eg, O&E, BMD,TMD,EMD
etc). These concepts will be presented as part of Technology scan in the
next Screening Committee meeting.
5.4 OPC communications specifications & engineering: Specifications can
be made more elaborate as per the application. ( Eg, Use of OPC
bridging can be explored wherever sustained bi-directional flow of data
is required, OPC tag list can be organized better based on group/item
concept for efficient communications.) Also, OPC training needs to be
specifically mentioned in the training requirements.
6 Adoptable Practices in NTPC

6.1 In Deptt./Section C&I system design: As already brought out,

the learning are already being applied in the
form of studies as part of technology scan &
will be used in detailed engineering.
6.2 In any other PMI: A half day session on the concept,
Deptt./Section applications & capabilities of OPC can be
added as part of ET ( C&I discipline) training
curriculum).
6.3 Company level 1. Due to its capabilities, OPC can be used
as a tool for providing a uniform HMI
platform as brought above in
applications section.
2. On the same lines, OPC can also be for
server consolidation as bought out at
point 5.3 above. Attempts can be made
in this direction.
3. As member of the OPC foundation,
attempts can be made to get key issues,
addressed in the latest specifications of
OPC UA, from an end user perspective
Eg, Response time & guarantee.
Annexure-B
OPC in a nutshell
Every mobile requires a different charger. A charger of Sony Ericson cannot work for a
Nokia mobile & vice versa. Even different models of the same make requires different
chargers. Basically, if we buy a mobile, we are locked on to the charger of that brand.
Presently, some kind of standardization efforts are being made in the mobile world in
order to make available a charger with universal specifications; which can work with any
mobile.
Similar is the concept behind the evolution of OPC. In the automation world also, there
are different software components developed for a specific product & which cannot be
used with the products of other manufacturers. For example, in order to use the plant
historical data for analysis, we have to use tools supplied by the historian supplier, in our
case , the DCS vendor. Accordingly, the analysis tools are also as good or bad as the one
supplied with the historian. As such, there is a dependency on the DCS vendor. Every
software has a specific purpose & unless data exchange between different software &
with DCS are made possible freely, data gets locked on to a particular system & is not
available for integration with maintenance & business software. Moreover, software
written cannot be reused leading to cost-intensive & time consuming programming.
The first attempts for enabling communication between software modules was started by
Microsoft through DDE ( Dynamic Data Exchange) & later on the more streamlined OLE
( Object Linked Embedding). OPC derived its name from the later, i.e. OLE for Process
Control. As the name suggests, OPC technology leveraged Microsoft technologies
(OLE) for communication between software modules/drivers of the automation industry.
The OPC foundation was founded as an independent non-profit organization with the aim
of developing & supporting the OPC standards. These are freely accessible technical
specifications that define sets of standard interfaces for different fields of application in
automation technology. These interfaces allow a highly efficient data exchange between
software components of different manufacturers & provide interoperability between these
products. Use of OPC technology makes the most diverse OPC components of different
manufacturers to work together.
The current OPC specifications are listed below along with its usage & latest version.
Specification Contents Version
Data access (DA) Definition of an interface for reading & 3.00
writing real time data
Historical Data access Definition of an interface for access to 1.20
(HDA) historical data
Alarms & Events ( A&E) Definition of an interface for monitoring 1.10
events
Data exchange ( DX) Communication between server & server 1.00
in process
XML DA Integration of OPC & XML for building 1.01
of Web applications
Unified Architecture(UA) Definition of an interoperability platform 1.00
providing standardized access to data in
DA, AE & HDA servers by means of
Web services
\
Out of the above standards, OPC DA is the flagship standard & is the most prevalent.
One of its main use is for real time exchange of data between two systems. It is based on
server client architecture. An OPC DA client polls or subscribes to data from an OPC DA
server. DA client consumes data & DA server produces data. DA server implements the
process data as groups & items. Item is an individual process point. Group is a collection
of items with common properties like update rate, % dead band for subscription.
OPC Alarms & Events specification defines an interface between client & server
programs for structuring, monitoring, transmitting & acknowledging events & alarms.
While DA servers make available continuous flow of data through adaptation of dead
band, Alarms & Events server sends events based on binary status change, analog limit
value exceeded, operator actions.
OPC DA only communicates ‘on the fly’ values from its Server to client. If history/trend
is needed, OPC HDA specifications come into play. Two types of data are used, one raw
data & another, processed data. Accordingly, two types of server implementations exist;
one simple trend data servers & other complex data compression & analysis servers.
The OPC UA specification, still in release stage, encompasses all the DA, A&E & HAD
into one & supports redundancy & web enabling besides many other advantages.
Barring the UA standard, none of the above standards are backward compatible. i.e. a
new version with not work with a product of different version.
As already brought out above, interoperability & concurrent working of OPC products
are only guaranteed when the products are developed complying to OPC standards. As
such , compliance certification is important. For this , OPC foundation offers a self
certification test that is run by server manufacturers. These tests are designed to verify
whether a server is compliant with the various specifications that comprise the standard.
For client vendors, the OPC foundation conducts interoperability workshops three times a
year, where client vendor gets an opportunity to test their OPC client implementation
against standard OPC server vendors. Every vendor come with their laptops which are
networked in a big conference room & OPC communications are tested. The results are
published on OPC foundation’s website. Recently, third party labs, accredited by OPC
foundation, are also known to provide certification. “OPC Certified” can only be
displayed on the product when the product passes all the three stages of testing.
OPC as implemented currently is based on Microsoft’s Distributed Component Object
Model ( DCOM). COM ( Component Object Model) is a service in Windows through
which two or more processes communicate with each other. If you have an object, which
you want to copy to another program, say from an Excel spreadsheet to a Word program,
you would be using COM on a single user account. For information exchange between
multiple user accounts, DCOM ( Distributed COM) is used. OPC is an instance of COM
class.
Use of DCOM technology made Firewall penetration difficult as DCOM opens many
ports while ports are closed by Firewalls for security purpose This is also one of the
major problems in communication between DDCMIS & IT LAN for data transfer to
ERP. The only alternative is OPC tunneling which bypasses DCOM. Tunneling software
needs to be implemented at both sides of the firewall.
Other alternative is to use OPC XML DA which does not use DCOM. XML stand for
Extensible markup language. It’s a language that describes data; not its presentation & is
text based. Due to this, it is easy to create & quite readable as compared to standard
programming languages. The main merit is that it is platform independent & can be used
straight forward on the Internet. In order to protect existing DA investments, wrapper
servers are available to connect OPC XML DA servers to OPC DA servers.
One of the main reasons for OPC foundation to go for development of UA standard is to
get rid of DCOM & use latest Web enabled technologies. It is hoped with this upcoming
standard, firewall penetration will not be an issue with OPC.

The original name of OPC “ OLE for Process control” has been replaced by “ Openness,
Productivity & Collaboration” to reflect the fact that OPC is no longer based on OLE, but on DCOM
& Web services.

********************