Bachelor of Science thesis in Computer Science
Client for OPC History Data Access
Karin Hjort Johnson1, Anna-Karin Nordekvist2
ABB Automation Products, LAA, 721 59 Västerås, Sweden
1
kht98004@student.mdh.se
2
ant98004@student.mdh.se
Department of Computer Engineering
Mälardalen University
Västerås, September 2001
Supervisor at university: Frank Lüders
Supervisor at ABB Automation Products: Mathias Andersson
Examiner: Ivica Crnkovic
Date:
2016-03-09
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
Summary
ABB has introduced a new paradigm, Industrial IT, a knowledge-based solution in the process control
industry. The Aspect Integrator Platform provides the basic functionality to Industrial IT offerings. The
connectivity between devices and applications within Industrial IT is achieved by OPC, an industry
standard that sets a common way of data access. OPC enable users to buy devices and systems from any
hardware or software vendor without any compatibility problems. Part of the platform is a History
Server. A History Server saves current data, time, value and quality, from the system. The OPC
Historical Data Access Custom Interface Specification describes the behaviour of interfaces and
methods the History Server is expected to provide.
The purpose of this thesis was to get an understanding of the OPC Historical Data Access standard and
to develop client software that can operate on any OPC HDA compliant server. The project was divided
into two parts: study relevant technologies and software development.
Relevant technologies important to be acquainted within this thesis have been: ABB Industrial IT (client
software is part of the concept), COM (implementation of client software), ATL (framework used in
client software implementation), and OPC Historical Data Access (essential to client software
development).
Emphasis of this thesis has been to develop client software that tests whether a History Server
corresponds to the OPC Historical Data Access Custom Interface Specification or not. The client
software can connect to and operate on any History Server and list functionality supported by the server.
This makes it a powerful tool when connecting software from different vendors. The client software will
be used in further development of the Aspect Integrator Platform.
Page 2 of 39
Date:
2016-03-09
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
Acknowledgements
This degree thesis was done at ABB Automation Products during the period June 2001 to September
2001. Karin Hjort Johnson and Anna-Karin Nordekvist performed the work. It was a required part of the
education, Bachelor of Science in Computer Science, at Mälardalen University in Västerås, Sweden.
We sincerely thank our supervisors Mathias Andersson and Jan Gjerseth at ABB Automation Products
and Frank Lüders at Mälardalen University.
We also want to thank Ivica Crnkovic and Magnus Larsson at Mälardalen University, Anders Hanberg
and other staff members at ABB Automation LAA, for their help and support.
We especially thank our families for their support and encouragement.
Examiner at Mälardalen University:
Name: Ivica Crnkovic
Title: Professor in Software Engineering
Email: ivica.crnkovic@mdh.se
Supervisor at Mälardalen University:
Name: Frank Lüders
Title: PhD Student in Software Engineering
Email: frank.luders@mdh.se
Supervisor at ABB Automation Products, LAA:
Name: Mathias Andersson
Title: Software Engineer
Email: mathias.ce.andersson@se.abb.com
Author:
Name: Anna-Karin Nordekvist
Title: Student in Computer Science
Email: annakarin.nordekvist@swipnet.se
Author:
Name: Karin Hjort Johnson
Title: Student in Computer Science
Email: kht98004@student.mdh.se
Page 3 of 39
Date:
2016-03-09
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
Table of Contents
1
INTRODUCTION ........................................................................................................................................... 5
1.1
1.2
1.3
1.4
2
BACKGROUND................................................................................................................................................ 5
PURPOSE ........................................................................................................................................................ 5
READING INSTRUCTION .................................................................................................................................. 5
DEFINITIONS .................................................................................................................................................. 6
RELEVANT TECHNOLOGIES ................................................................................................................... 6
2.1 COM AND ATL ............................................................................................................................................. 6
2.1.1 Introduction to COM ............................................................................................................................ 6
2.1.2 Introduction to ATL .............................................................................................................................. 9
2.2 INTRODUCTION TO OPC ............................................................................................................................... 10
2.2.1 History of OPC ................................................................................................................................... 11
2.2.2 Goals for OPC .................................................................................................................................... 11
2.2.3 OPC Specifications............................................................................................................................. 12
2.3 OPC HISTORY DATA ACCESS ...................................................................................................................... 12
2.3.1 Introduction to OPC HDA .................................................................................................................. 12
2.3.2 Purpose of OPC HDA ........................................................................................................................ 12
2.3.3 Types of Historian Servers ................................................................................................................. 13
2.3.4 OPC-HDA Fundamentals ................................................................................................................... 13
2.3.5 General Architecture and components ............................................................................................... 13
2.3.6 Overview of Object and Interfaces ..................................................................................................... 14
2.3.7 Short description of OPC-HDA Custom Interfaces ............................................................................ 16
2.4 INDUSTRIAL IT ............................................................................................................................................. 17
2.4.1 Aspect Object ...................................................................................................................................... 18
2.4.2 Aspect Systems .................................................................................................................................... 19
2.4.3 Aspect Integrator Platform ................................................................................................................. 20
3
TEST CLIENT APPLICATION DEVELOPMENT .................................................................................. 22
3.1 PROJECT PLANNING...................................................................................................................................... 22
3.2 REQUIREMENTS ........................................................................................................................................... 23
3.2.1 Main requirements ............................................................................................................................. 23
3.2.2 Additional requirements ..................................................................................................................... 24
3.3 ANALYSIS .................................................................................................................................................... 25
3.4 DESIGN OF CLIENT SOFTWARE .................................................................................................................... 26
3.4.1 System Architecture ............................................................................................................................ 26
3.4.2 Functional Description of Client ........................................................................................................ 27
3.4.3 Program Design ................................................................................................................................. 28
3.5 IMPLEMENTATION ........................................................................................................................................ 31
3.5.1 Requirements Definition Compliance ................................................................................................. 32
3.5.2 AdvHtHDAInspector Main Window ................................................................................................... 33
3.5.3 Browser Dialog .................................................................................................................................. 34
3.5.4 Attribute Dialog .................................................................................................................................. 34
3.5.5 Report Dialog ..................................................................................................................................... 35
3.5.6 ReadMe file ........................................................................................................................................ 36
3.6 HOW TO USE THE ADVHTHDAINSPECTOR APPLICATION ............................................................................. 36
3.7 POSSIBLE ERRORS ........................................................................................................................................ 37
3.8 FURTHER DEVELOPMENT AND IMPROVEMENTS ............................................................................................ 37
4
CONCLUSIONS ............................................................................................................................................ 38
5
REFERENCES .............................................................................................................................................. 39
Page 4 of 39
Date:
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
1
2016-03-09
Introduction
This chapter will give you a short introduction to the background and purpose with this thesis and also
some reading instructions and abbreviations used in the report.
1.1
Background
The main topic of this thesis is about client software to test History Servers according to the OPC
Historical Data Access Custom Interface specification 1.0. A History Server saves current data from the
system, time, value and quality. The History Server is a part of the Aspect Integrator Platform. The
platform (further described in chapter 2.4.3) is an Industrial IT solution developed by ABB Automation
Products.
OPC, an industrial standard established from the OPC Foundation (further described in chapter 2.2), is
used when developing the Aspect Integrator Platform. The standard will facilitate the development of
servers and clients in the process control industry. This technology is used to combine and access data
from different sources. The History Server developed by ABB Automation Products complies with the
OPC History Data Access requirements.
ABB Automation Products develops and delivers for example products and IT solutions for force
measurement, control, optimization and protection in industrial processes and in power applications.
Their products and solutions are used all over the world in manufacturing of pulp and paper, food,
pharmaceutical, chemical, metals, etc. - and in power plants.
1.2
Purpose
The purpose of this thesis is to explore the OPC History Data Access standard and to develop client
software that can operate on any OPC History Data Access compliant server. It has given an
understanding on design and development of software that should function in a distributed environment
and interact with software developed by many different vendors. The client software can list the
functionality supported by a History Server and ensure its compliance with the OPC History Data
Access Specification.
The client software will facilitate the further development of Aspect Integrator Platform, which is a part
of Operate IT, a product being developed by ABB Automation Product. To verify the functionality of
History Servers from different vendors this client software will be a powerful tool.
1.3
Reading instruction
Chapter 2 is a short description of relevant technologies, which are COM (2.1.1), ATL (2.1.2), OPC
(2.2), OPC History Data Access (2.3) and Industrial IT (2.4). If you are familiar with any of those
technologies, we suggest you skip that part and continue reading the paper. The description of the
project for this thesis is covered in chapter 3 and chapter 4 contains our conclusions.
Page 5 of 39
Date:
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
1.4
Definitions
Abbreviation
Definition
ASO
Aspect System Object
ATL
Active Template Library
COM
Component Object Model
DCOM
Distributed Component Object Model
DLL
Windows Dynamic Link Library
EXE
Executable program
HDA
History Data Access
OPC
OLE Process Control
OLE
Object Linking and Embedding
UI
User Interface
VB
Visual Basic
WTL
Windows Template Library
2
2016-03-09
Relevant technologies
This is a short description of some techniques that are of importance in order to assimilate this report. In
this chapter Industrial IT, COM, ATL, OPC and OPC HDA are discussed. Getting acquainted with these
techniques has been an important part of this thesis.
2.1
COM and ATL
Active Template Library, ATL, is a C++-based framework that facilitates the development of small and
efficient software components based on Microsoft’s Component Object Model (COM). COM is
Microsoft’s system-level object-oriented technology that is used extensively within its products and
tools. The primary focus of ATL is to enable the creation of small COM-based software modules. These
modules are then assembled to create larger applications. [1]
2.1.1
Introduction to COM
A Java class is of little use to a C++ developer, and some Visual Basic code won’t help a COBOL
programmer. If you write a system in C++ today, will that effort be superseded five years from now by
the arrival of a new programming language? It was issues like these that drove the authors of the COM
to their solution, which is to use language-neutral, binary components. This methodology allows
developers to write components in whatever language they choose, such as C++, Visual Basic and Java.
Component functionality housed within a DLL or EXE can be used from Visual Basic, Java, C++ or
Page 6 of 39
Date:
2016-03-09
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
even COBOL. The language implementation must support COM. It’s the compiled code that matters,
not the source code.
COM is a complicated topic, but we can write a simple one-sentence description that outlines its most
important features:
"COM is a specification and a set of services that allow you to create modular, object-oriented,
customizable and upgradeable, distributed applications using a number of programming languages."
[2]
Facilities offered by COM:

COM is a specification…
… that describes the standards you need to follow. The standard tells how COM components
should look like and how they should behave.

COM is a set of services…
… that are provided by the COM library. The library is part of the operating system on Win32
platforms.

COM allows modular programming…
… that allows components in different modules to talk to each other. COM components can be
packaged as DLL or EXE files.

COM is object-oriented…
… which means that COM components are true objects that can be treated polymorphically.

COM enables easy customization and upgrades to your applications…
… through dynamic linking of COM components with each other and individual components
can be updated and replaced without having to recompile the entire application.

COM enables distributed applications…
… to interact across a network and provides location transparency to applications. The COM
components can be written without regard to their location and they can be moved without
requiring any changes to the application.

COM components can be written in many programming languages…
… that can cope with the binary standard. A large number of languages and tools support COM,
for example C, C++, Java, JScript, Visual Basic, VBScript and Delphi..
COM is not about any particular type of application. It's not about controls (that's ActiveX); it's not
about compound documents (that's OLE); it's not about data access (that's OLE DB and ADO); and it's
not about games and graphics (that's DirectX). But COM is the object model that underlies all these
technologies. An understanding of COM is vital to programming any of these technologies successfully.
[2]
2.1.1.1
The COM interface
A COM interface is a group of definitions of methods that are usually related in the operations they
perform. The definition of an interface does not include an implementation of its methods. The interface
is the part of the component that clients interact with. The methods in an interface can be called by using
a pointer to that interface, and doing so results in the execution of the code in a COM object. The
Page 7 of 39
Date:
2016-03-09
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
definition of an interface includes the syntax of the methods it contains (return types, parameter types
and calling conventions), and the semantics of how to use them.
COM components are often drawn as ’lollipop’ diagrams, as shown Figure 1 below. By convention, the
names of all interfaces start with ‘I’ and the IUnknown interface is drawn plugged into the top of the
object.
IUnknown
IInterface1
COM
Object
IInterface2
1
Figure 1.
2.1.1.2
COM component
Virtual Method Table
Virtual Method table (see Figure 2), also known as vtable or vtbl, is created when the COM component
is compiled. A table contains descriptions of method and pointers to implementation of methods. A
pointer to an object is a pointer to a vtable. User of a COM interface has access only to the public
methods of a component, which means that a component’s interface can contain only methods. It cannot
expose data members directly.
Figure 2.
Class implementation is encapsulated by exposing only the Vtable pointer to the client.
Page 8 of 39
Date:
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
2.1.1.3
2016-03-09
Interface IUnknown
Every component inherits from IUnknown. All COM components are required to implement a standard
COM interface called IUnknown.
IUnknown contains three methods, the two first manage the lifetime of a component and the third is a
standard way for a user to ask for a specific interface within a given component.

AddRef( ) – increases reference counter.

Release( ) – decreases interface counter.

QueryInterface( )- returns a pointer to requested interface.
The basic purpose of QueryInterface is to return a Vtable pointer for the requested interface. If the
object supports that interface, QueryInterface retrieves a pointer to the interface, while also calling
AddRef to increment the instance’s internal counter. Otherwise, if the interface is not supported, it
returns an error code.
2.1.2
Introduction to ATL
Although the COM component is simple, building the infrastructure to support the component takes
quite a bit of code, and much of the support code is the same for every COM component you build. That
is why frameworks such as ATL are popular. They encapsulate the tedious, routine code and allow you
to focus on providing your components unique functionality. [1]
Active Template Library, ATL, is a class library that contains support for making the implementation
procedure of developing COM-components easier. Using ATL makes the compiled code fast, small and
efficient. The concept of using C++ templates ensures that there is no extra overhead.
The goal for ATL was to give software developers the flexibility to implement their components
without any dependencies on secondary DLL’s, including the standard C run-time DLL. Another
important goal was to make components developed with ATL as small and fast as possible. The
drawback for new users of ATL are difficulties to understand the ATL implementation because the aim
to have as small amount of code as possible.
ATL features:

AppWizard, to create the initial ATL project.

Object Wizard, produces code for basic COM components.

Built-in support for elementary COM functionality.

Support for Microsoft’s Interface Definition Language (IDL).

Support for IDispatch and dual interfaces.

Support for developing efficient ActiveX controls.
Page 9 of 39
Date:
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
2.2
2016-03-09
Introduction to OPC
The motivation for OLE for Process Control, OPC, is to have a standard technique for communicating
to numerous data sources, either devices on the factory floor or a database in a control room.
The goal of the OPC Foundation is to develop an open, flexible, plug-and-play industry standard that
allows end users to enjoy a greater choice of solutions, as well as sharply reducing development and
maintenance costs for hardware and software suppliers.
Figure 3.
Trademark for the worldwide OPC standard.
Based on Microsoft's OLE (now Active X), COM and DCOM (distributed component object model)
technologies, OPC consists of a standard set of interfaces, properties, and methods for use in processcontrol and manufacturing-automation applications. The Active X/COM technologies define how
individual software components can interact and share data. OPC provides a common interface for
communicating with diverse process-control devices, regardless of the controlling software or devices in
the process.
OPC draws a line between hardware providers and software developers. It provides a technique to
provide data from a data source and communicate the data to any client application in a standard way. A
vendor can now develop a reusable, highly optimized server to communicate to the data source, and
maintain the mechanism to access data from the data source/device efficiently. Providing the server with
an OPC interface allows any client to access their devices.
OPC
Server
Vendor A
OPC
Server
Vendor B
OPC Client
OPC
Server
Vendor C
Figure 4.
An OPC Client can connect to OPC Servers provided by one or more vendors.
Page 10 of 39
Date:
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
2.2.1
2016-03-09
History of OPC
OPC is an industry standard created with the collaboration of a number a leading worldwide automation
and hardware software suppliers working in cooperation with Microsoft. The letters O-P-C originally
stood for OLE - Object Linking and Embedding - for Process Control. OLE has since been restructured
from object-oriented to object-based and renamed Active X.
The organization that manages this standard is the OPC Foundation. The Foundation has over 270
members from around the world, including nearly all of the world's major providers of control systems,
instrumentation, and process control systems. The OPC Foundation's forerunner - a task force composed
of Fisher-Rosemount, Rockwell Software, Opto 22, Intellution, and Intuitive Technology - was able to
develop a basic, workable, OPC specification after only a single year's work. A simplified, stage-one
solution was released in August 1996.
The OPC Foundation has been able to work more quickly than many other standards groups because
OPC Foundation is simply building on an existing Microsoft standard. Microsoft is a member of the
OPC Foundation and has given strong backing to the organization. However, Microsoft has been careful
to remain in the background and let the member companies with direct industry experience guide the
organization's work.
Traditionally if a user wanted to mix and match application software systems and devices from multiple
vendors, he first had to find out if the software drivers for a given device or system were available. If
not, he had to choose another solution or invest the time and money necessary to develop a custom
driver using that vendor’s proprietary interface. OPC eliminates the compatibility problem, allowing
users to select precisely the devices and systems they want and can afford for a particular application.
“OPC will bring the same benefits to
industrial hardware and software that
standard printer drivers brought to
word-processing.”
2.2.2
Goals for OPC
A primary goal for OPC is to deliver specifications to the industry as quickly as possible.
Goals for the design of OPC were as follows:

Simple to implement

Flexible to accommodate multiple vendor needs

Provide a high level of functionality

Allow for efficient operation
Page 11 of 39
Date:
2016-03-09
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
The specifications include the following:
1. A set of custom COM interfaces for use by client and server writers.
2. References to a set of OLE Automation interfaces to support client developed with higher-level
business applications such as Excel, Visual Basics, etc.
The architecture is intended to utilize the Microsoft distributed OLE technology (DCOM) to facilitate
clients interfacing to remote servers. [4]
2.2.3
OPC Specifications
The intent of all specifications is to facilitate the development of OPC Servers in C and C++, and to
facilitate development of OPC client applications in the language of choice. The architecture and design
of the interfaces are intended to support development of OPC servers in other languages as well.
These specifications are available at this time:

OPC DataAccess
The specification about online DataAccess is the efficient reading and writing of data between
an application and a process control device flexibly and efficiently.

OPC Alarm and Event Handling
Alarm and Event Handling that is the mechanisms for OPC Clients to be notified of the
occurrence of specified events and alarm conditions.

OPC Historical Data Access
Historical Data Access is the reading, processing and editing of data of a historian engine
(further described in chapter 2.3).
2.3
2.3.1
OPC History Data Access
Introduction to OPC HDA
OPC History Data Access specification holds information about interfaces that must be implemented in
order to become a true OPC HDA server. This helps software applications from different vendors to
work together.
Currently most historical systems use their own interfaces to distribute information to users and
software clients. Vendors have independently developed infrastructures to their products. There is no
possibility to use existing historical solutions with other functionality. This requires all vendors to
recreate the infrastructure in their products to be the same.
Manufactures and consumers want to use off the shelf solutions from vendors that offer a solution to a
specific need or problem.
2.3.2
Purpose of OPC HDA
Nowadays many applications are developed in environments like Visual Basic (VB) and Delphi. This
also affects OPC. To follow this trend, Microsoft designed OLE/COM to allow components written in C
Page 12 of 39
Date:
2016-03-09
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
and C++ to be utilized by a custom program written in VB or Delphi. Developers will write software
components in C and C++ to encapsulate the implementation of accessing Historical data, so that
business application developers can write code in VB that requests and utilizes historical data.
The purpose of the OPC Historical Data Access specification is to facilitate the development of OPC
Servers for Historical Data Access in C and C++ (or any other language), and also to facilitate the
development of OPC client applications in the language of choice. The specification specifies a standard
for interfaces used to pass historical information between components. The basics are to define
interfaces to support the reading, writing, and editing of historical data between client applications and
historical data servers. From this specification there is only a loose binding to the other OPC
specifications (OPC Data Access and OPC Alarm and Event Handling). It does not inherit interfaces,
and is not derived from any another OPC specification.
2.3.3
Types of Historian Servers
There are several types of Historian servers. The simple historian may only support one or two of the
interfaces.

Simple Trend data servers. These servers provide simple raw data storage. Data would
typically be the types of data available from an OPC Data Access server, usually provided in
the form of a triplet, [Time, Value & Quality].

Complex data compression and analysis servers. These servers provided data compression
as well as raw data storage. They are capable of providing summary data or data analysis
functions, such as average values, minimums and maximums etc. They can support data
updates and history of the updates. They can support storage of annotations along with the
actual historical data storage.
2.3.4
OPC-HDA Fundamentals
An OPC Client can connect to one or several OPC Historical Servers provided by different vendors. The
client should be able to function with any of the servers. If another OPC server is required (such as Data
Access server) for full functionality, the client should still be able to operate on Historical data without
the other OPC server.
The OPC Historical Data Server provides a way to access or communicate to a set of Historical data
sources. The types of sources available are a function of the server implementation. The server may be
implemented as a stand-alone OPC HDA server that collects data from an OPC Data Access server or
another data source. It may also be a set of interfaces that are layered on top of an existing Proprietary
Historical Data Server. The clients that access the OPC HDA server may be simple trending packages
that just want values or they may be complex that require data in multiple formats.
2.3.5
General Architecture and components
OPC HDA servers may have a dual interface and a custom interface. The custom interface must be
implemented, and if desired the automation interface. The automation interface is used to support access
from script languages, such as Visual Basic, and is derived from the IDispatch interface. The client
communicates to an OPC HDA server by calling required interfaces. All functionality of required
interfaces must be implemented. There are optional interfaces and methods as well. A client cannot
expect those to be implemented. The architecture of an OPC HDA server is show in Figure 5 below.
Only the COM interfaces are specified in the specification, no implementation. It specifies the
behaviour of the interface expected by the client application.
Page 13 of 39
Date:
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
C++ Appli cation
OPC Custom I/F
OPC Hi stori cal Data Server
(In-Proc, Local, Remote,
Handler)
VB Appli cation
2016-03-09
Vendor Speci fi c Logi c
OPC Automati on I/F
Figure 5.
Architecture for OPC History Data Access server. [3]
The architecture of OPC is a client-server model, like all COM implementations, where the OPC Server
component provides an interface to the OPC object and manages them. The OPC Automation Interface
may be implemented via a wrapper. The OPC Foundation may provide a generic wrapper. This wrapper
would provide the Automation interface, to support dual interfaces for script languages, for any Custom
interface.
2.3.6
Overview of Object and Interfaces
Through the interfaces the client can access the historical data, such as read and write to the historical
server. The types of historical data are server dependent. In the figures below, Figure 6 and 7, OPC
Objects (for the client and server side) and their interfaces are shown. Optional interfaces are indicated
by [ ].
There are two ways for a client to retrieve data from a History Server, either by a synchronous or an
asynchronous interface. When using the synchronous interface the client is blocked while waiting for
the result. This is appropriate for fairly simple clients, reading rather small amounts of data where noninteractive communication is needed. Using the asynchronous interface, the client can process any other
actions while waiting for data to return. This makes it very efficient and is the most appropriate way in
big systems.
Historian Client Model
IUnk now n
IOPCHDA_Shutdow n
[IOPCHDA_Re adCallback ]
[IOPCHDA_Update Callback]
[IOPCHDA_AnnotationsCallback ]
Figure 6.
IOPCHDA_
Client
Object
Client Model Overview [3]
Page 14 of 39
Date:
2016-03-09
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
If an OPC Historian Client application wants to use an asynchronous interface in the server, it must
implement a matching callback to the interface. Requested data is returned from the server via methods
in the IOPCHDA_DataCallback interface. This interface and matching methods has to be implemented
by the client.
Historian Server Model
(Two Objects)
IUnknown
[IOPCHDA_AsyncRead]
IOPCCommon
IOPCHDA_SyncRead
[IOPCHDA_SyncUpdate]
[IOPCHDA_SyncAnnotations]
IOPCHDA_
Server
Object
[IOPCHDA_Playback]
[IOPCHDA_AsyncUpdate]
[IOPCHDA_AsyncAnnotations]
IConnectionPointContainer
IOPCHDA_Server
IUnknown
IOPCHDA_Browser
IOPCHDA_
Browser
Object
Figure 7.
Model Overview [3]
By the IOPCHDA_Browser interface a client is able to locate a particular area of the address hierarchy
with all branch names in a simple graphical browser. A server may support filtering, which is optional.
Implementation of filtering and browsing is server specific.
Historical data can be organized in OPC Groups, see Figure 8 below. The group might represent items
in a particular operator display or report. Data can be read and written. OPC Items are not the data
source, they are just connections to them within the server. The data source is the data log where value,
quality and time stamp associated to an item are saved. The OPC Item should be thought of as simply
Page 15 of 39
Date:
2016-03-09
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
specifying the address of the data, not as the actual physical source of the data that the address
references. OPC clients only have access to OPC Items via interfaces in an OPC Historical Data Access
Server.
Group
Item 1
Item 2
Item 3
Figure 8.
2.3.7
Group/Item Relationship. [4]
Short description of OPC-HDA Custom Interfaces
This is a short description of Historical Data Access Custom interfaces, interfaces and methods. More
information can be found in OPC Historical Data Access Custom Interface Specification 1.0.
IOPCCommon
This interface is required and used by all OPC Server types
(DataAccess, Alarm&Event, Historical Data). It provides the
ability to set and query a LocaleID.
IOPCHDA_Server
This interface is required and does basic actions. For example
retrieves information about data types supported by the History
Server and to get information about the current status of the
server.
IOPCHDA_Browser
This interface is required and provides a simple graphical
manager to show the address hierarchy.
IOPCHDA_SyncRead
This interface is required and provides the possibility to read
values in different ways from the History Server with a
synchronous connection.
IOPCHDA_SyncUpdate
This interface is optional and provides the possibility to update
values in different ways in the History Server with a
synchronous connection.
IOPCHDA_SyncAnnotations
This interface is optional and provides the possibility to read
and insert annotations in the History Server with a synchronous
connection.
IOPCHDA_AsyncRead
This interface is optional and provides the possibility to read
values in different ways from the History Server with a
synchronous connection.
Page 16 of 39
Date:
2016-03-09
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
IOPCHDA_AsyncUpdate
This interface is optional and provides the possibility to update
values in different ways in the History Server with a
synchronous connection.
IOPCHDA_AsyncAnnotations
This interface is optional and provides the possibility to read
and insert annotations in the History Server with a synchronous
connection.
IOPCHDA_Playback
This interface is optional and provides the capability to get an
initial set of data from the History Server and then gets
continual updates of historical data. The playback interface
supports functionality to retrieve data from the past and the
supply updates from stored data.
IConnectionPointContainer
This interface is required if any Asynchronous interface is
supported. It supports connection points for connectable
objects.
2.4
Industrial IT
ABB is committed to comprehensive software architecture for integrating diverse products and systems
as knowledge-based Industrial IT solutions.
“We call it Industrial IT . . . The Next Way of Thinking. “
(Catchphrase from ABB.)
Industrial IT is part of the new revolution, but it is not a specific product or a service. It provides users
with full integrated, real-time solutions across common hardware, software, engineering, project
management, training and service. It’s a collection of building blocks that includes Operate IT, Control
IT, Inform IT, Produce IT…
Figure 9.
The Industrial IT Solutions portfolio [5]
Page 17 of 39
Date:
2016-03-09
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
ABB’s comprehensive Industrial IT portfolio of compatible products - coupled with more than 20,000
software, application, and service professionals worldwide - is focused on delivering productivity and
profits to automation customers.
The Aspect Integrator-, Control- and Skyva Platforms are the basis for all Industrial IT offerings. These
platforms provide the basic functionality allowing product development to start from a much higher
level and thereby shortening the time-to-market. The most important platform is the Aspect Integrator
Platform.
The Industrial IT architecture is based on the Aspect Object concept, which is provided by the Aspect
Integrator Platform (see Figure 10 below). Functionality is added as Aspect Systems (described in
2.4.2), which ensures that the functionality is integrated for all users of the complete system. OPC is
used for accessing data from devices and also between different Aspect Systems.
Other SW
functions
Aspect System
“Private
Functionality”
Web Clients
SOAP/XML ,
html
OPC,
OLE-DB ,
Automation
Model,
IIT API
Internet
Information
Server
“Any protocol”
Aspect
System
Aspect
System
Aspect
System
Aspect
System
Af w interf aces
Aspect Integrator Platform
OPC
OPC
WWW,
TCP/IP,
PPP, html,
XML
OPC Server
OPC Server/
Connector
OPC Server
“Any
protocol”
Web
Devices
Generic
Devices
Control Network
Generic
Devices
Control Network
Devices
Fieldbuses
Fieldbus
Devices
Fieldbus
Devices
“Any
protocol”
Generic
Devices
Figure 10. The Industrial IT architecture [5]
2.4.1
Aspect Object
An Aspect Object represents a physical or logical part of the automation installation, such as a valve,
pump or actual batch, but also process units or combinations of hardware units. All information, aspects,
belonging to those objects are structured in functional windows called aspect views (see Figure 11).
Examples of aspects are historical data, process signal data or technical specifications. OPC connections
are also examples of aspects of an object.
Page 18 of 39
Date:
2016-03-09
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
Figure 11. Different aspects of an object. [5]
Each real world object can be described from several different perspectives. Each perspective, Aspect of
the object, defines a piece of information and a set of functions to create, access and manipulate this
information.
An Aspect Object is not an object in a strict sense (as used in traditional object oriented software
technologies), e.g. like a COM object, but rather a container of references to implementations of the
different Aspects.
2.4.2
Aspect Systems
Aspects are implemented by software systems known as Aspect Systems (see Figure 12), each of which
stores, manages and presents its information in its own optimal way. Aspect Systems interact through
COM interfaces.
An Aspect System is the build block that implements the functionality, which the aspect adds to the
object. Sometimes an Aspect System is just a wrapper that links the object to another implementation.
Aspect Systems provide their functionality through interfaces implemented by COM objects, which are
known as Aspect System Objects (ASO). Depending on which integration level is selected, the Aspect
System Objects must support different sets of framework-defined interfaces for common object and
aspect operations. Groups of Aspect Systems may agree to add specific interfaces for special purposes.
Figure 12. Different Aspects are implemented by different Aspect Systems. [5]
Page 19 of 39
Date:
2016-03-09
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
An Aspect System may provide one or more user interfaces. These shall be provided as aspect views.
An aspect view is an ActiveX component or an html page, which can be identified with a reference, and
be included in the graphical user interface managed by the platform.
The Aspect System access information associated with the aspect. The architecture with Aspect Objects
makes it possible to add new software to the system without recompiling or changing the once already
in place.
2.4.3
Aspect Integrator Platform
Aspect Integrator Platform, based on the operating system Windows 2000, provides the basic
functionality of the Aspect Objects concept. Development environment and tools used together with
Aspect Integrator Platform are Aspect Studio and Aspect Express. Aspect Studio is a development
environment and product tool for development of Aspect Systems. Aspect Express is a wizard-based
tool to make Aspect Systems out of COM or ActiveX components for Visual Basic users.
The Platform has been developed to fulfill the following seven main goals:

Performance - Real time performance from very small to very large systems.

Modularity - Product modularity and module independence.

Scalability - Designed for 50-2.000.000 objects and to provide consistent operation regardless
of size.

Fault Tolerance - Optional hardware and software redundancy.

Security – Integrated authority concept.

Openness - Based on standard technology with well-defined interfaces and efficient
development tools.

Integration - Provide an integration framework for the whole entity you want to integrate (e.g.
system, plant or enterprise). [5]
The platform includes among other things Local history and trend, which is basic historical data
logging, storage and retrieval, and basic trend display elements via OPC interfaces. OPC (OLE for
Process Control) is used as the main protocol for accessing data from devices and also between different
Aspect Systems. The Aspect Integrator Platform provides services that allow data handled by any
Aspect System to be accessed from any other Aspect System via OPC.
The Plant Explorer (shown in Figure 13) is a basic application used for navigation in and between
object structures in the platform. It is also used as the default tool to configure, manage and browse for
information. It is based on the Windows Explorer metaphor and functionality but instead of folders and
files it handles Aspect Objects and Aspects. The Plant Explorer includes powerful navigation features
such as filtering, search tools, and preview windows.
Page 20 of 39
Date:
2016-03-09
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
Figure 13. The Plant Explorer work place.
Aspect Objects can be represented in several hierarchical structures at the same time. It is possible to
dynamically move an object between different positions in the same or different structure. Structures
like functional, location or graphical structure, are used to represent how different types of aspect
objects are related in the system.
Page 21 of 39
Date:
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
3
2016-03-09
Test Client Application Development
The objective with the project was to develop a test client that could easily show if a History Server has
implemented interfaces and methods according to the OPC Historical Data Access Custom Interface
specification 1.0.
3.1
Project planning
Process model used in the project has been the Waterfall model (shown in Figure 14). The initial phase
was to study some techniques, like ATL, COM and OPC, and to analyse the requirements specification.
Requirements Analysis
System Design
Program Design
Implementaion
Testing
Operation & Maintenance
Figure 14. The Waterfall model
A Gantt chart was made to estimate the time assignment to each activity in the project. The “Ivicas
Project planning law” was taken into consideration.
Ivicas Project planning law:
”The project will take at least a double as much
time as planned. The Ivicas project planning
law is valid even if it is taken in the planning.”
[Ivica Crnkovic, Västerås, Sweden]
A helpful tool in the project has been Microsoft Visual Studio 6.0, a software development platform.
Visual SourceSafe 6.0 (VSS) has been used as a version control tool. Source code and other documents
have been saved in the VSS. All files could easily be updated and reached by all members involved in
the project. The VSS has also been useful when working in parallel and to merge files. Another
Page 22 of 39
Date:
2016-03-09
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
advantage with the VSS was when trouble-shooting. With the VSS it was possible to recover from
severe problems by using an older version of an file. As software development tool (SDK) Visual C++
was used. This is a powerful tool with useful wizards for different new files, projects and other
documents. The wizards generate code, which saves many hours of coding. Another helpful tool has
been MSDN, the Microsoft Developer Network. It contains technical programming information,
including tutorials and useful sample code. MSDN is the essential reference for developers who use
Microsoft development tools.
When beginning the project it was essential to get a fundamental structure of the project and application
development. Due to this the work had to be done sequentially until the fundamentals were confirmed.
Step by step as the project progressed the project-work was divided into small tasks, which made it
possible to work in parallel.
3.2
Requirements
ABB Automation Products, department LAA, requested a client application to test History Data Access
servers from different vendors. The test client is used to ensure that History Data Access servers are
compliant with the OPC History Data Access specification. The application will be used in future
development of the Aspect Integrator Platform (described in 2.4.3).
Definitions and motivations of the requirements are described in the tables below. (Main requirements
in 3.2.1 and additional requirements in 3.2.2.)
3.2.1
Main requirements
Ident.
Prio.
Description
R-01
1
Identify/connect to any OPC HDA server in the system.
Possibility to connect to History Data Access servers from different vendors in the
system. To make the application usable it must have the ability to verify any History
Server, independent of vendor and implementation.
R-02
1
Operate on any OPC HDA compliant server.
Ability to operate on any OPC HDA server in the system independent of vendor
and implementation. This gives the application the power to verify any OPC HDA
server. The software should also function in a distributed environment and
interact with software developed by many different vendors.
R-03
1
List functionality supported by a History Server.
A listing functionality to verify if the server is OPC HDA compliant and also
to view the functionality supported by the server in a report. This is also useful
when trouble-shooting and adding functionality to a server.
R-04
1
Utilize functionality supported by a History Server.
Ability to use functionality implemented according to the OPC HDA
specification. This is useful when trouble-shooting and verifying a History
Server.
Page 23 of 39
Date:
2016-03-09
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
Ident.
Prio.
R-05
1
Ensure that History Servers are compliant with OPC HDA specification.
To ensure that History Servers are compatible with software, from any vendor
in the system, it is necessary to check its compliance with the OPC HDA
specification. The compatibility is achieved by following the OPC HDA
specification when implementing interfaces and functionality in the server.
R-06
1
Read raw data values from the History Server.
Possibility to read raw data values in the data logs in the system. Make use of
the ReadRaw method in the IOPCHDA_SyncRead and
IOPCHDA_AsyncRead interfaces in the OPC HDA specification.
R-07
1
Read processed data values from the History Server.
Possibility to read processed data values in the data logs in the system. Make
use of the ReadProcessed method in the IOPCHDA_SyncRead and
IOPCHDA_AsyncRead interfaces in the OPC HDA specification.
3.2.2
Description
Additional requirements
Ident.
Prio.
Description
R-08
2
Update data values in the History Server.
Possibility to update data values in different ways in the data logs in the
system. Make use of the methods in the IOPCHDA_SyncUpdate and
IOPCHDA_AsyncUpdate interfaces in the OPC HDA specification.
R-09
2
Add annotations to values in the History Server.
Possibility to read and add annotations in the data logs in the system. Make
use of the methods in the IOPCHDA_SyncAnnotations and
IOPCHDA_AsyncAnnotations interfaces in the OPC HDA specification.
R-10
2
Save the report in a text document, with suitable path.
Ability to save the report for further examination and future comparison.
Page 24 of 39
Date:
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
3.3
2016-03-09
Analysis
The software to develop was a test client for History Servers, designed and developed for users familiar
with History Servers and the OPC Historical Data Access Custom Interface specification. The
application will be used as a test tool in further development of the Aspect Integrator Platform. It was
important to develop stand-alone software with no dependencies to the platform. This makes the
software useable with any History Server and independent of implementation in the server.
To get a high usability of the application, it was designed as comprehensible to the user as possible. The
aim was to create a self-instructing and intuitive User Interface (UI) with no irrelevant information.
Names of combo boxes, buttons and fields have a significant meaning. To reach a high usability,
feedback on performed actions are always given to the user.
The development approach for the software was incremental phased. The requirement was portioned
into subsystems, modules, by functionality. Functionality was added to the application by gradual
stages.
The fundamental task and first module to design was the component that identifies different History
Servers in the system. The best usability to users is if the servers are searched out when the application
is started. To make the component, which searches out History Servers, as general and reusable as
possible the COM technique (described in 2.1.1) was chosen. COM is extensively used within
Microsoft’s products (applications, tools and operating systems) and as the products are widely used in
Industrial Software Development, COM was a natural choice. This also enables the component to be
used in future software applications. The component could have been developed as a normal class
method in the application, with the loss of reusability and also the experience from developing COM
components.
The choice of programming language was C++ using Microsoft’s framework ATL (described in 2.1.2).
ATL provides the help to build small COM-based components. It is also possible to develop COM
components using VB or Microsoft’s Foundation Class (MFC). The difference is that ATL generates
small and efficient applications, which is important in the process industry with complex and large
systems. ATL also includes useful wizards that facilitate the software development. WTL (Windows
Template Library, described in 3.5) was chosen as a windowing framework when developing the UI.
Page 25 of 39
Date:
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
3.4
2016-03-09
Design of Client Software
The design was made in three steps (phases). First step was to design the COM component that is used
for finding History Servers in the system. Second step was to design the UI. This was an important part
to get the application as usable as possible. The third and last step was to divide the application into
modules and classes by functionality.
3.4.1
System Architecture
The architecture of the system, shown in Figure 15, is based on the client-server architecture model,
which is the most frequently used model today. The system is structured with the test client application
(AdvHtHDAInstpector) and COM component (FindHDAServers) on the client side and History Servers
on the server side of the system. The COM component has the interface IFindHDAServers. It is used
when the test client application is started to find History Servers in the system. AdvHtHDAInstpector
takes care of the connection to one History Server at the time. Through the connection it is possible to
test interfaces and methods in the server. Operating systems used in the system is Microsoft Windows
2000.
On the server side it is possible to get connected to History Servers from different vendors thanks to the
OPC technology. OPC Servers communicate through their compliant interfaces, which make the client
independent of the implementation of the History Server.
AdvHtHDAInspector
TEST CLIENT
APPLICATION
IFindHDAServers
COM
OPC History
Server
OPC History
Server
OPC History
Server
Vendor A
Vendor B
Vendor C
Figure 15. Design of application that shows the possibility to connect to different
OPC History Servers.
Page 26 of 39
Date:
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
3.4.2
2016-03-09
Functional Description of Client
Use Case Model for users of the test client application, show in Figure 16 below.
Figure 16. The Actor in the system is using the functionality offered by the application.
Connect/disconnect to History Server
All History Servers in the network are automatically listed when the application is started. There is a
possibility to connect to a selected History Server. If something fails an error message is displayed.
Test interface
Possibility to test if connected History Server supports an interface. The result of the test is displayed in
the application.
Test method
If connected History Server supports an interface it is possible to test its methods. A method may
require an item handle or certain data, the application demand the user for needed information.
Page 27 of 39
Date:
2016-03-09
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
Browse
To facilitate the retrieval of an item ID handle, it is possible to search for one in a graphical way. The
browse implementation is part of the History Server and described in the OPC Historical Data Access
Custom Interface specification 1.0.
Clean information field
Possibility to remove all text from the main window. The window cannot handle too much text at the
same time. The window needs to be cleaned if no new text is displayed even though new actions are
made.
Open ReadMe-file
Possibility to open ReadMe-file that contains information about the application and a User’s Guide.
View report
Possibility to get an overview what interfaces and methods connected History Server supports. This
facilitates the work to check if connected History Server is a true OPC HDA server that complies with
the OPC HDA Custom Interface Specification 1.0. The report specifies which functionality is required
and optional according to the specification. An item handle must have been retrieved before the report
can be written. A copy of the report is written to file and saved in suitable file-structure.
3.4.3
Program Design
The program design is divided into three parts, COM object, view and functionality of the server. To
make the COM object as reusable as possible it was designed to only return a list with the History
Servers name in the system. In the main window information about made actions are displayed. The
information can also make the user observant of necessary inputs, which give the user an easy way to
test different interfaces and methods. The class HDAServer is responsible to store values about the
History Server that are tested. Now the application is designed for connection to only one History
Server at the same time. The HDAServer class is designed for multi connectivity and the view class can
easily be change for connection to several History Servers.
Page 28 of 39
Date:
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
3.4.3.1
2016-03-09
Class Diagram
Class diagram in Figure 17 shows an abstract of the most important attributes and operations in the
system.
Figure 17. Class diagram of client software.
3.4.3.2
Brief Description of Classes
AdvHtHDAInspectorView
The main purpose with this class is to handle the view of the application. In the main window the user
can choose to test interfaces, methods or view a report overview. Information generated from different
tests is shown in an information field in the main window.
Page 29 of 39
Date:
2016-03-09
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
AdvHtFindHDAServers
This class is a COM component with no attributes and is only accessed through its interface. The
method GetHDAList( ) returns a list with names of History Servers in the system.
HDAServer
The class HDAServer contains information about a History Server in the system that the user wants to
test. The method Connect( ) tries to get a connection to the server, if that fails it is shown in the
information field in the main window. The attribute m_phItem is a handle to an item, which is required
to test some methods.
ReportDlg
The class ReportDlg is a dialog window. The dialog pops up when it is called from
AdvHtHDAInspectorView class to make a report.The dialog method WriteReport( ) lists and shows all
OPC HDA interfaces and methods whether they are implemented or not. It is also shown if they are
required or optional according to the OPC HDA specification.
AttributeDlg
The class AttributeDlg is a dialog window. It appears when the user wants to test a method that requires
some more information, for example start and end time. If the user has changed some attributes in the
dialog the method SaveData( ) saves those for further use. Next time the dialog appears the saved data
is shown in the attribute fields. To a specific method only the required attribute fields are enabled, that
makes it easier for the user to know which information to add.
HDACallback
The class HDACallback is used when the user is testing an asynchronous method in the History Server.
3.4.3.3
Sequence Diagram
Sequence diagram in Figure 18 shows when user makes a connection to a History Server in the system.
The second sequence diagram in Figure 19 shows when a user wants to view a report with all interfaces
and methods belonging to a specific History Server if they are implemented according to the OPC HDA
specification.
Figure 18. Connecting to a server in the system
Page 30 of 39
Date:
2016-03-09
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
Figure 19. View a report
3.5
Implementation
ABB Automation Products LAA uses Microsoft Visual Studio as software development kit, which
includes tools for Visual Basic and C++. The choice of programming language has been C++ since this
is the common language for other members in the software development team and the authors are
familiar with this language.
The test client application is made in a Windows Template Library (WTL) project, which is a part of
ATL. WTL is a windowing framework, a wrapper around the windowing portions of the Win32 API.
The choice of WTL was because it gives a small and efficient application with no DLL dependencies. It
is also easy to use when creating windows and graphical user interfaces.
The COM object was made in an ATL project. ATL has the ability to make COM objects with wizards,
which facilitate the work in many ways.
Some important issues during the implementation phase, with consideration on the code, have been to
keep the code simple and consistent, easy to understand, update and maintain and also to take care of
correct and incorrect user input.
To make the code easy to understand it is well commented with significant comments for methods,
variables and important code parts. Names of classes, methods and variables have an important meaning
and follow the same naming convention through the program. Frequent used functionality has the same
style and naming. To make the code easy to read code blocks are kept rather small with space between
and the code is also indented. To take care of user input as “safe” as possible most input are made
through combo boxes. The user only has a limited list to choose from, which makes it easy for the
program to validate user input. If an error occurs a message is displayed in the information field in the
AdvHtHDAInspector main window, shown in Figure 20.
Page 31 of 39
Date:
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
3.5.1
2016-03-09
Requirements Definition Compliance
Main requirements
Id
Requirement Description
% Completed
R-01 IDENTIFY/CONNECT TO ANY OPC HDA SERVER IN THE SYSTEM.
100
R-02 Operate on any OPC HDA compliant server.
100
R-03 List functionality supported by a History Server.
100
R-04 Utilize functionality supported by a History Server.
100
R-05 Ensure that History Servers are compliant with OPC HDA
100
specification.
R-06 Read raw data values from the History Server.
100
R-07 Read processed data values from the History Server.
100
Additional requirements
Id
Requirement Description
% Completed
R-08 Update data values in the History Server.
50
R-09 Add annotations to values in the History Server.
50
R-10 Save the report in a text document, with suitable path.
100
Comments:
In requirements R-08 and R-09, only functionality for the synchronous interface is
implemented. Functionality for the asynchronous interfaces are not implemented.
Total number of requirements
10
Number of requirements implemented
10
Requirements partially fulfilled
2
Requirements not fulfilled
0
Page 32 of 39
Date:
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
3.5.2
2016-03-09
AdvHtHDAInspector Main Window
When the user starts the application the main window appears, shown in Figure 20. From the beginning
all History Servers in the system are automatically listed in the combo box “History Servers”. To be
able to test interfaces and methods a History Server has to be selected and then press the button
“Connect”. When a server is connected the text on the button is changed to “Disconnect” to remind the
user to disconnect the server. In the information field below buttons and combo boxes information is
displayed to the user about tests of interfaces and methods. The information field also gives the user
some recommendations of actions, for example if the method requires an item to be tested.
“Clear”-button has to be used when the information field has reached the maximum character capacity
and no more information can be shown.
The functionality of the “Browse…” and “Report” buttons are described in chapter 3.5.3 and 3.5.5.
In the “Help” menu it is possible to choose to read the “About” dialog and to read the ReadMe file,
described in chapter 3.5.6.
Figure 20. User interface (UI) for the test client application, AdvHtHDAInspector.
Page 33 of 39
Date:
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
3.5.3
2016-03-09
Browser Dialog
When the button “Browser…” is pressed in the main window the dialog in Figure 21 pops up. To test
some methods an item is required. The dialog presents a hierarchical structure of items and it is possible
to browse through and find different items in the address space. When “OK”-button is pressed the main
window tries to get a handle to the selected item.
Figure 21. Browser dialog used for getting an item ID.
3.5.4
Attribute Dialog
When methods require some more information to be tested the dialog in Figure 22 pops up. Only fields
to required attributes for a specific method are enabled. This avoids the user to get distracted from
unnecessary information.
Figure 22. Dialog to get required input from user. Each method needs different input.
Data not needed have disabled fields.
If the user change some attributes in the dialog they are saved for further use. Next time the dialog
appears the saved data is shown in the attribute fields.
Page 34 of 39
Date:
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
3.5.5
2016-03-09
Report Dialog
If the user has connected to a server and chosen an item it is possible to get a report of all interfaces and
methods, shown in Figure 23. The report shows name of the server and time when the report is
generated. Below interface and methods are listed in order according to the OPC Historical Data Access
Custom Interface Specification 1.0. The field “Required/Optional” holds information about, which
interfaces OPC Historical Data server developers must implement. If there is a required (R) interface all
required methods must be implemented. An optional interface is one that the server developer may elect
to implement.
Figure 23. Dialog windows pops up when report button pressed.
The field “Comment” displays information about the History Server that is tested, whether interfaces are
supported or not and what information the methods has generated.
To easily compare several History Servers the report is saved in a text document. The path is shown in
the information field in main window when the report is closed. The text document has the same name
as the History Server, for easy recognition, but the dots (.) in the OPC History Server name are changed
to underscore (_).
Page 35 of 39
Date:
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
3.5.6
2016-03-09
ReadMe file
This ReadMe file, see Figure 24, can be reached from the menu bar below “Help” in the main window.
It describes how to use the application and some necessary information. Topics included are:
Introduction, Requirements, Running the program and User’s Guide.
Figure 24. Beginning of ReadMe file.
3.6
How to use the AdvHtHDAInspector application
To use the AdvHtHDAInspector test client application, install the AdvHtHDAInspector.exe and
README.txt files in home directory. Register the AdvHtHDAListing.dll and AdvHtBrowserDlg.dll.
After registering the files it is possible to use the program. The AdvHtBrowserDlg.dll is only necessary
for the Browse functionality. It is possible to manually write an Item ID without Browse. To start the
application execute the AdvHtHDAInspector.exe file. It is needed to install a History Server local on the
computer to make use of the application. When the application is running it is ready to get connected to
one History Server found in the system (on the same computer) History Servers are found during the
application start up. Found servers are shown in the “History Servers” combo box. If no server is found
an error message is displayed in the information field in the AdvHtHDAInspector main window, shown
in Figure 20. When connected to a server it is possible to use the application, such as test interfaces,
methods and so forth. Further information about the AdvHtHDAInspector application is found in the
README.txt file. To open README.txt from AdvHtHDAInspector main window (Figure 20), click
on the “Help” menu and then select “ReadMe”.
The AdvHtHDAInspector test client runs on Microsoft Windows 2000. It is a stand-alone application
and has no dependencies to the Aspect Integrator Platform.
Page 36 of 39
Date:
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
3.7
2016-03-09
Possible Errors
If no History Server is located on local machine it is not possible to make use of the application
functionality. The application is only tested with two different History Servers. To become more reliable
it needs more testing with other History Servers.
The Browser functionality is server dependent, for this reason the test client application may not work
properly with all servers’ implementation of Browser. To manage the problem an item ID can be
manually inserted in the “Item Name” field.
3.8
Further development and improvements
The basic functionality of the test client application works well. Further improvements to make are
continuing implementing functionality to test methods according to the OPC Historical Data Access
Custom Interface Specification.
Another desirable functionality is the possibility to connect to any History Servers on a remote machine
in the network and not only on the local machine. Implementation changes needed is to use DCOM
instead of COM.
Today it is possible to test one server and item at the time, but it may be desirable to test many
simultaneously. There are some hard coded variables in the program that need to be replaced with
dynamically functioning variables and code.
Page 37 of 39
Date:
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
4
2016-03-09
Conclusions
Our thesis “Client for OPC History Data Access” has been a pleasant experience to us, Karin and
Anna-Karin. We have met many friendly people at the department ABB Automation Product LAA,
whom we had a lot to learn from. They have encouraged and helped us during the project. We have had
the great opportunity to learn about new technologies, such as Industrial IT, ATL, OPC and OPC
Historical Data Access. It has been instructive to work in a big company with an extensive amount of
knowledge. Work experience has been important to get a complete understanding of theories and
techniques studied at University. To us it has been pleasant to develop an application useful for a real
customer.
After getting acquainted to some new technologies we think that ATL is a powerful technique that is
useful to software developer. The knowledge will certainly be to our advantage in the future. COM is
widely used in software development today and the thinking belongs to the future. For certain it will not
fade away over a night. The development of COM will continue to make software more efficient and
powerful. OPC is another established technology that will continue to expand. The industry standard
helps the collaboration between different hardware and software vendors. With OPC, applications can
easily be developed, changed and integrated with applications from different vendors. This gives the
user to enjoy a flexible plug-and-play standard with a greater choice of solutions. All OPC drivers will
work the same way. OPC is a good and necessary technology for co-operation from different software
developers.
Our task has been to develop a client application that can operate on any OPC History Server. The client
tests if the server complies with the OPC Historical Data Access Custom Interface Specification.
Another purpose of our thesis has been to get acquainted to some new technologies.
Users intended to use our application, AdvHtHDAInspector, are History Server developers. The
application will be used for testing and comparing their own History Server with servers from other
vendors. It is a powerful tool for troubleshooting a server to find errors and also useful for further
development of a History Server. We have completely implemented functionality requested by our
customer, but we recommend the test client application to be further developed to test all functionality
described in the OPC Historical Data Access Custom Interface Specification.
When finished the project we had a complete understanding of every part in it. Certainly there are a
number of things we would have done differently if we had our present knowledge when starting the
project. Now we have an understanding of how the OPC Historical Data Access Custom Interface
Specification works. That understanding had been useful when designing the program and divided into
classes. If we would start over with the project again we would divide classes differently. Smaller and
efficient classes are preferable and also a class inheritance hierarchy for testing methods according to
the specification. One advantage of our implementation is that it is modular and easy to change without
affecting other parts of the program.
To summarize our thesis, we consider that we have reached our goals to develop test client software and
learn about new technologies. Finally we hope that our work will be useful in future tests and analysis.
A-K & K
Page 38 of 39
Date:
Authors: Karin Hjort Johnson
Anna-Karin Nordekvist
Client for OPC History Data Access
5
2016-03-09
References
[1] Armstrong, T., (1998), Active Template Library: A Developer’s Guide, IDG Books Worldwide,
Foster City
[2] Grimes, R., (1999), Beginning ATL 3 COM Programming, Wrox Press, Birmingham
[3] Opc Foundation TM, (2000), OPC Historical Data Access Custom Interface Specification 1.0,
http://www.opcfoundation.org/
[4] Opc Task Force (1998), OPC Overview, http://www.opcfoundation.org/
[5] ABB Automation Products (2001), Industrial IT Architecture – Introduction and Definitions,
Page 39 of 39