Alarms and events in WS500

Alarms and events in WS500
Alarms and events in WS500
Author
Peter Adleff
Paf99002@student.mdh.se
Master thesis in computer science, 20p
June 9, 2005
ABSTRACT
ABB is a supplier to electrical energy consumers and power distribution companies.
ABB Power Technologies AB in Västerås is a part of the Power System division.
ABB is currently interested in finding a new technique that can transfer a large
amount of alarms and events data in a fast and efficient way from their server to the
WS500 (Workstation 500) client systems. Today’s solution does not allow the clients
to filter and browse the alarms and events with a scroll bar because the information
must be transferred from the server. This would give a large server and bandwidth
load if there are many clients. It also gives an unwanted delay while browsing so the
current solution sends a limited number of alarm and event lists to clients when
information is asked for. This gives the impression that the system is turning pages
until the wanted information appears in client system.
The solution presented in this report is to distribute alarm and event messages from
the server to all client nodes in a faster and more efficient way than today’s solution.
This will be achieved by having a ‘Multicast Alarm and Event Server/Client’ on each
client computer that will replicate the alarms and events from the server. The
‘Multicast Alarm and Event Server/Client’ will then provide the WS500 system locally
on each computer with the cached information. This approach will meet the following
requirements:
•
•
•
Better performance while browsing and filtering alarm/event lists.
Reduce network traffic
Reduce server load.
2
Contents
Preface .............................................................................................................6
1. Introduction..................................................................................................7
2. Technologies overview ...............................................................................8
2.1 TCP/IP Reference Model ..................................................................8
2.1.1 The Layers ..........................................................................8
2.1.1 Internet addresses ..............................................................10
2.1.2 Port number ........................................................................10
2.1.3 TCP .....................................................................................11
2.1.4 UDP.....................................................................................11
2.2 Routers/Switches ..............................................................................12
2.2.1 Routers................................................................................12
2.2.2 Routing protocols ................................................................12
2.2.3 Multicast routers .................................................................12
2.2.4 Switches..............................................................................12
2.2.5 Hubs....................................................................................13
2.3 Unicast..............................................................................................13
2.4 Broadcast..........................................................................................13
2.5 Multicast............................................................................................13
2.5.1 Multicast groups ..................................................................14
2.5.2 Multicast Backbone (MBone) ..............................................14
2.5.3 Reliable multicasting ...........................................................14
2.6 OPC (OLE for Process Control) ........................................................15
2.6.1 OPC Alarm & Events Specification .....................................15
2.7 Component technologies ..................................................................17
2.8 Microsoft ATL/COM .........................................................................17
2.8.1 Identifiers ............................................................................18
2.8.2 IUnknown ............................................................................18
2.8.3 MIDL – Microsoft Interface Definition Language .................19
2.9 ActiveX..............................................................................................20
2.10 CORBA ...........................................................................................21
2.10.1 IDL –Interface Definition Language ...................................21
2.10.2 The ORB ...........................................................................23
2.11 SIDL – SPIDER IDL ........................................................................25
3. Alarm and events in WS500 .......................................................................26
3.1 SPIDER and WS500.........................................................................26
3.2 Current solution.................................................................................26
3.3 System performance ........................................................................27
4. Result of thesis............................................................................................28
4.1 Problem description ..........................................................................28
4.2 Problem Analysis ..............................................................................28
4.3 Data transfer .....................................................................................28
4.3.1 Broadcast vs. Multicast .......................................................28
4.3.2 OPC A&E ............................................................................29
4.3.3 Conclusion ..........................................................................29
4.4 Sort/filter and browsing capability .....................................................29
4.5 Component architecture....................................................................30
3
4.5.1 Multicast A&E server/client..................................................31
4.5.2 A&E viewer..........................................................................31
4.5.3 SPIDER A&E server............................................................31
4.6 Data storage .....................................................................................31
4.7 Prototype overview ...........................................................................31
4.8 SPIDER A&E server role .................................................................33
4.8.1 Multicast A&E server registration ........................................33
4.8.2 The alarm/event lists ...........................................................33
4.8.3 Downloading missing alarms/events ...................................34
4.9 WS500 Multicast A&E server/client ..................................................35
4.10 WS500 Multicast A&E Server Role .................................................35
4.10.1 Sending multicast packages..............................................36
4.11 WS500 Multicast A&E Client Role ..................................................37
4.11.1 Receiving multicast packages ...........................................38
4.12 WS500 A&E Viewer ........................................................................39
4.12.1 Scrolling alarm/event lists..................................................39
4.12.2 Modifying an alarm/event ..................................................40
4.13 Analysis ..........................................................................................41
4.13.1 Advantages .......................................................................41
4.13.2 Disadvantages ..................................................................41
5. Future development ....................................................................................43
6. Conclusion ...................................................................................................44
A. Duplicating a remote SIDL object ..............................................................47
B. Creating a multicast socket in C++............................................................48
C. Constructed types in SIDL .........................................................................49
D. Cyclic Redundancy Check (CRC) ..............................................................50
E1. Unicast transmission example.................................................................52
E2. Broadcast transmission example ............................................................53
E3. Multicast transmission example ..............................................................54
4
List of figures
2.1 TCP/IP model layers....................................................................................8
2.2 Two hosts on a LAN communicating with FTP ............................................9
2.3 The five classes of the Internet addresses. .................................................10
2.4 The three-way handshake ..........................................................................11
2.5 Interaction between several OPC Alarm and Event Servers and Clients.....16
2.6 COM IDL file ...............................................................................................19
2.7 CORBA IDL example...................................................................................22
2.8 CORBA communications within a single process ........................................23
2.9 ORB-to-ORB communications.....................................................................24
3.1 Current communication configurations ........................................................26
4.1 Overview of the components architecture ...................................................30
4.2 The prototype topology overview.................................................................32
4.3 Alarm list with 100 000 alarms.....................................................................33
4.4 Alarm list with over 100 000 alarms .............................................................33
4.5 Alarm cache list points out the latest alarm updates in the Alarm list ..........34
4.6 State-chart for the Multicast A&E server......................................................35
4.7 State- chart for the Multicast A&E client ......................................................37
4.8 Alarms displayed in WS500 A&E Viewer.....................................................39
4.9 The data flow when acknowledge an alarm.................................................40
5
Preface
This is my thesis for a Master degree in Computer Science; it covers a different
approach to transfer alarm and event messages in their WS500 system in a more
efficient way. The work was made at ABB Power Technologies in Västerås.
To begin with, I would like to thank Stefan Bengtzing and Peter Freyhult for coming
up with this idea. I would also send special thanks to Johan Odin and Håkan
Bernström at ABB for helping me to get started in their development environment and
a big thanks to my supervisor at Mälardalens University Daniel Flemström who has
encouraged me and helping me complete this thesis.
Examiner at Mälardalens University
Ivica Crnkovic
ivica.crnkovic@mdh.se
Supervisor at Mälardalen University
Daniel Flemström
daniel.flemstrom@mdh.se
Supervisor at ABB Power Technologies AB
Peter Freyhult
peter.freyhult@se.abb.com
6
1. Introduction
This Master Thesis describes my exam work at ABB Power Technologies AB in
Västerås. It was performed in close cooperation with experienced software
developers and designers for their SPIDER operator system.
The main goal was to find a new approach for distributing large amount of alarm and
event information from the server to all connected clients in a more effective way than
with today’s solution and also give the clients browsing capability and filtering
options.
This report is divided into different sections. The first section, called “Technologies
overview”, will explain the basics of technologies I used or came in contact with. This
section should be read as a reference for the following sections.
The next section, “Alarm and events in WS500”, describes how the alarm and event
information is distributed to the clients in the current solution and some of the
limitations.
The third section, “Result of thesis”, gives a problem overview, analysis and the
choice of technologies for the prototype.
The “Future work” section describes how the prototype can be further develop and
improved.
In the last section,”Conclusions”, you will find my reflections and conclusions on this
work.
7
2. Technologies overview
2.1 TCP/IP Reference Model
The Transmission Control Protocol (TCP) and Internet Protocol (IP) are the two
primary protocols used in the current Internet architecture. TCP and IP protocols
were developed by Department of Defense (DoD). It was a research project where
the major goal was to build a flexible architecture [1]. This new architecture gave the
ability to connect multiple networks together seamlessly and to remain the
connections intact as long as the source and destination devices were functional.
TCP/IP made it possible for any two computers to communicate regardless their
physical location in the world [2].
The U.S Department of defense created the TCP/IP model so it would work under
any conditions, even under a nuclear war. It was important that the data packets get
through from one point to any other point, even if any particular node or network
failed for some reason on the Internet [2]. The TCP/IP protocol stack has four layers
where each has its own responsibility for different tasks of the communication.
2.1.1 The Layers
Figure 2.1 TCP/IP model layers
When an application sends data using TCP, the data is sent down the protocol stack
through each layer until it comes to the physically layer where it is sent as a stream of
bits across the network through some media, like cable. Every layer adds its own
control information to the data from the layer above by adding a header and
sometimes a trailer. The receiving host will send the received packet up in its protocol
stack reading and removing the headers and the trailers until it reaches the
application it was meant for.
Here follows a brief description of the 4-layers:
The Network access layer sometimes called data-link layer or host-to-network layer.
This layer normally includes the device driver in the operating system and the
corresponding network interface in the computer [3] and handles all issues that an IPpacket requires to actually being transferred physically through some kind of media
from one device to a directly connected one.
8
The Internet layer (sometimes called network layer) handles the packet movement
from any network to the destination by best path determination. The packets may
arrive in different order than they were sent because the packets can travel different
ways through the network and it’s up to the ‘higher’ layers to resort them if desired.
The Transport layer (also called host-to-host layer) handles issues like reliability,
retransmissions and flow control for the application layer above. There are two
transport protocols, TCP (Transmission Control Protocol) and UDP (User Datagram
Protocol).
TCP protocol ensures a reliable connection-oriented flow of data between two hosts
without errors. UDP is a simpler protocol and just sends packets called datagrams. It
does not guarantee that the datagram reaches its destination without any errors or
even reaches the destination.
The Application layer contains all the higher-level protocols such as Telnet for remote
login, the File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP) and so
on.
Figure 2.2 shows an example of two hosts communicating on a local are network
(LAN) through FTP. It shows the involved the protocols.
Figure 2.2 Two hosts on a LAN communicating with FTP [3]
9
2.1.2 Internet addresses
Figure 2.3 The five classes of the Internet addresses. [1]
Every host and router on the Internet has a unique Internet address (IP address),
which encodes a network and a host number. No two devices can have the same IP
address. IP addresses are 32-bit numbers (4 bytes). These numbers is usually
written as four decimal numbers separated with a dot, therefore called the dotted
decimal notation. Each of the four decimals has a range from 0 to 255. The lowest IP
address is 0.0.0.0 and the highest is 255.255.255.255. IP addresses are used in the
source address and the destination address fields in every IP packet. Figure 2.3
shows the five different classes. The first decimal number in the dotted decimal
notation for an Internet address shows what class it belongs to.
There are three different IP addresses. The IP address for a single host is called
unicast address (see section 2.3) and for all hosts on a specific network it’s called
broadcast address (see section 2.4). The third IP address is the multicast address
(see section 2.5), which addresses a set of hosts that belongs to a multicast group.
2.1.3 Port Number
A TCP connection is created having both the sender and the receiver to create their
own end points, called sockets. Each socket has a socket number consisting of the
hosts IP address and a 16-bits port number. A client usually does not care about
what port number it uses on the server as long as it will remain unique on its host.
The client port number are “short lived”, it lives only until the user running the client
needs its service, while a server port number lives as long as the host is operational
and running. Most application implementations use a port number between 1024 and
5000 unless the application uses services that have reserved port numbers. The
Internet Assigned Numbers Authority (IANA) manages these reserved or well-known
port numbers [3]. These port numbers has a range from 1 to 1023. For example a
File Transfer Protocol (FTP) server application should use the port 21.
10
2.1.4 TCP
TCP is a connection-oriented end-to-end protocol where the source and destination
has a conversation. It is a transport layer protocol that sends data as a stream of
bytes [4]. The protocol ensures a reliable connection with error free data exchange by
using sequence numbers, acknowledgement messages and retransmissions if data
has been lost. It also handles flow control so a fast sender cannot send faster than
the slower receiver can handle.
Figure 2.4 The three-way handshake [2]
The connection-oriented service has three phases [2]: connection establishment
phase, data transfer phase, and connection termination phase. In the connection
establishment phase a connection or session is created between the sender and
receiver by using a three-way handshake where they synchronize the initial starting
sequence numbers. Figure 2.4 shows the procedure. Host A begins sending a packet
with its initial sequence (SEQ) number of x with a certain bit set in the header
indicating a connection request. Host B then receives the packet, records the
sequence number and replies with a packet with an acknowledgement (ACK) of x+1
and includes its own initial sequence number of y. The acknowledgement of x+1
means that x has been received and is expecting x+1 in the next packet. This
synchronization ensures the detection of missing sequence numbers during
transmission. In data transfer phase, data is sent sequentially over the established
path, arriving in the same order it was sent. The last phase is the connection
termination phase, the connection between the source and destination host will be
terminated when it no longer is needed.
2.1.5 UDP
UDP works at the transport layer protocol just like TCP but it is a simpler protocol.
The UDP protocol sends its data in a UDP datagram to the Internet layer where it is
embedded into an IP datagram. It gives no guarantees that the data ever reaches its
destination. Error processing and retransmission must be handled by other protocols.
The order the packets been received can also differ from the order they were sent.
11
2.2 Routers/switches
2.2.1 Routers
A router is a device used to forward unicasted data packets between networks.
Routers can also be programmed to handle multicast packets (see 2.4.3). A router is
connected to at least two networks, commonly two LANs. Routers examine all
incoming packets, read the header information and uses forwarding tables to
determine the best path for the packet and then switch it to the proper outgoing port.
Because of their ability to route packets between networks the routers have become
the backbone of the Internet, running the IP protocol [2].
2.2.2 Routing protocols
Routing protocols is a protocol that provides a mechanism for sharing routing
information. Routers use these protocols to communicate with other connected
routers and to update and maintain their routing tables with their own knowledge of
the routes between routers in the network or on the Internet. This gives them a map
and allows routing to occur. If one router fails by some reason the nearby routers will
know about in a short time and they will try to route the packets around it to reach the
final destination. There are a lot of routing protocols and to describe them is out of
this reports scope but they all calculate some kind of metric value to determine the
best path to the destination. For example the Routing Information Protocol (RIP) are
the most common routing protocol within a domain. RIP allows routers to decide the
best path to use by using the concept known as distance-vector routing. Whenever
data passes a router this equals to one hop. A path that has hop counts of 4 means
that data going that path must pass through 4 routers to reach its destination. If there
are multiple paths to that destination the router will choose the one with least number
of hops [2].
2.2.3 Multicast routers
Multicast router or an mrouter is a router that is programmed to forward multicast
messages between unicast routers like the ones that build up the Internet network
topology. To forward the multicasted packet the mrouter disguise it to a unicast
packet and sets the destination mrouters IP address in the header. This process is
called IP tunneling and makes it possible for the multicast sending host to reach more
multicast group members outside its own LAN. The mrouters that supports it on the
Internet make up the Multicast Backbone, also called the MBone.
2.2.4 Switches
A switch makes decisions on LANs and not like routers between LANs. It has multiple
connection ports that allow many devices to be connected to a single point. A switch
only sends the packet out the correct port where the destined host is connected.
Switches store the connected hosts MAC address. A MAC address is a unique
number of the hosts NIC (Network interface card). Switching is done by examine the
destination IP address in the packet and map it to MAC address through the switches
look up table and then chooses the proper outgoing port.
12
2.2.5 Hubs
Hubs have multiple ports just like switches but they are simpler. They cannot filter
network traffic and they forward every incoming packet to all ports because they have
no knowledge about the connected hosts.
2.3 Unicast
Unicast is the term for a data exchange between two nodes, one sender and one
receiver. TCP and UDP support unicast transmissions. Class A, B and C addresses
are unicast addresses and are supported by all LAN’s (Local area network). Web
browsers, FTP- and email applications are common unicast applications.
See appendix E1 for an example.
2.4 Broadcast
Broadcasting means that UDP data is sent from one node to all other connected
nodes on the LAN. The problem with broadcasting is that it produces unnecessary
network- and host load on the hosts that are not interested in the broadcasts. Every
time a host receives a broadcast it processes the message and checks the
destination port number. If no process or application uses the port number for
incoming broadcasts the message will be discarded.
See appendix E2 for an example.
2.5 Multicast
The purpose with multicasting is to send a single IP datagram from one node to many
connected nodes. The biggest advantages with multicast transmission is that more
clients does not mean more bandwidth load since only one packet is send and then
spread to all other through switches and mrouters. The main difference to
broadcasting is that only the interested host will get the datagrams. To actually be
able to receive multicast datagrams the host needs to join a certain “multicast group”.
Multicast traffic is usually handled at the transport layer with UDP datagram, as TCP
only provides point-to-point connections [6] so there are no guarantees on delivery or
error processing and retransmissions. But there are a lot of protocols that supports
reliable multicasting we will go through a couple of them in detail later.
Unlike the broadcast domain that is inside the sending hosts own LAN, the multicast
domain can extend over several networks if the routers between them has the proper
software to handle multicast packets, like the MBone.
The multicasts addresses are class D with the range of 224.0.0.0 to
239.255.255.255. Every IP datagram whose destination address starts with “1110” is
an IP Multicast datagram, see fig 2.3. The remaining 28 bits identify the “multicast
group” the datagram is sent to.
See appendix E3 for an example.
13
2.5.1 Multicast groups
Every client who wishes to accept multicast messages from a sender needs to join a
multicast group. To join a group the clients need to send an IGMP (Internet Group
Management Protocol) packet to a router or a switch or a similar device. The IGMP
packet tells what multicast packets it’s interested in by leaving the multicast IP
address and port number for the group. The router/switch knows then exactly which
clients to send to if a multicast packet with exactly that IP address and port number
arrives. When a client does not want any more packets it will send a new IGMP
messages which tells the router/switch to delete it from the group list.
2.5.2 Multicast Backbone (MBone)
Since most routers only support unicast traffic on the Internet a virtual network was
created by IETF (Internet Engineering Task Force) in 1992 [7]. This virtual network
runs on top on the Internet and it’s called the MBone (Multicast Backbone). The
MBone allows multicast packets to travel through unicast routers by programming
them so the multicast packets will be embedded into regular unicast packets so that
unicast routers can handle them. This router who uses this software is called
mrouters. The technique to hide multicast packets in unicast ones is called tunneling.
The MBone size is relatively small compared to the Internet. In 1995 there was about
1700 networks in 20 countries on the MBone (3,5 percent of the Internets networks)
[7].
2.5.3 Reliable multicasting
Reliable multicast often means that it gives the same guarantees as with TCP and
unicast transmission. The criteria’s usually are delivery guarantees on each packet,
flow control and also that all packets are received in the same order they was sent.
14
2.6 OPC (OLE for Process Control)
OPC is a series of standard specifications developed by OPC Foundation in 1996.
The first standard was the Data Access Specification and it resulted in that many
leading worldwide automation suppliers was collaborating and cooperating with
Microsoft. The specification defined a standard of interfaces for use in process
control and manufacturing automation applications. It is a server/client architecture
based on Microsoft’s OLE COM (component object model) and DCOM (distributed
component object model) technologies. Today there is hundreds of OPC Data
Access Servers and Clients.
There are also other data types then the original Data Access. Now there are
communication standards for Alarm & Events, Historical Data, Batch Data, and many
more [10].
2.6.1 OPC Alarm & Events Specification
OPC Alarm & Events (A&E) is a standard set of interfaces for managing alarm and
event notifications. It allows OPC A&E Clients to subscribe on the alarms and events
it needs by filtering.
The OPC standard defines different types of Alarm and Event servers.
•
Components that can detect alarms and/or events and report them to one or
more clients.
•
Components that can collect alarm and event information from multiple
sources, whether by subscribing to other OPC alarm and event servers or by
detecting alarms and events on it’s own, and report such information to one or
more clients.
15
The figure below illustrates the interaction in an OPC client-server system.
Figure 2.5 Interaction between several OPC Alarm and Event Servers and Clients [21].
The figure shows several types of OPC Alarm and Event (A&E) clients and servers
including a Device, Module, Operator Stations, Event Logger, and an OPC
Alarm/Event Management server. The Alarm/Event Management server is also a
client to more than one OPC Alarm and Event server. In this system, the
Alarm/Event Management server is acting as kind of a collector or data concentrator,
providing its clients with possibly more organized information or a more advanced
interface. The Device and Modules could possibly implement a simpler Alarm/Event
server interface.
16
2.7 Component technologies
The applications that use components consist of individual objects that encapsulate
functionality and data. In object oriented programming, objects often represent
something in the real world, and this type of thinking is very suitable when – for
example – creating a web store. A customer would need his very own shopping cart,
and these would in turn be instances of a shopping cart object. The more customers
there are the more instances will be created of the same object.
Component programming is split into a server part and a client part. The server
object requires an Interface Definition Language (IDL), which specifies the services
that the object has to offer. The only way for a client to communicate with a server
object is through interfaces. For clients and server objects to understand each other
on any platform, operating system, programming language and so on, the interfaces
need to be defined for both the client and server objects.
An interface definition must specify the operation to be performed and all of the input
and output parameters with their types, allowing client and server to encode and
decode values for their travel over the network.
2.8 Microsoft ATL/COM
ATL (Active Template Library) is a set of template-based C++ classes which was
developed by Microsoft to let the programmer more easily build COM objects. COM
(Component Object Model) is a model developed by Microsoft in the early 90’ to
make it easy to develop component based object oriented applications.
Every COM object has its unique identity with a set of exposed interface that allows
other applications and/or other components to access its features. They are binary
components written in any language It will work with new programming languages
years from now. It is the compiled code that matters, not the source code. [11].
COM is not the first and only way of reusing compiled code. C-style DLLs, for
example has been used for Windows programming for a long time. DLLs advantages
and disadvantages are:
Advantages:
•
•
•
Parts of an application can be swapped or changed without the need for
recompilation of the whole system.
Code can be loaded on a just-in-time basis, so it does not allocate any system
memory if it’s not needed.
Code can be shared between processes, which can be more memory-efficient
than statically linking it (Compiling it into the application).
Disadvantages:
•
•
•
Callable from most languages but there are relatively few that allow you to
create them.
Not object-oriented.
Traditionally, DLLs have been loaded by filename, which means if the name or
location of the DLL is changed, the application cannot load it.
17
•
It is difficult to provide different versions of a DLL on the same system,
because it can cause conflicts between different vendors’ products.
Because of the benefits of a DLL a COM component can be packaged as one too.
But they have overcome many of the disadvantages of an ordinary DLL.
A coclass is named from component object class and is a piece of binary code that
implements some kind of functionality. Coclasses can be distributed in DLL (Dynamic
linked library) or in EXE (executable) files.
The COM object is an instance of a coclass that gets loaded into the system memory.
COM interfaces are the connection by which other component or applications get
access to the functionality of the COM component.
2.8.1 Identifiers
COM associates the name of everything you define with strings of numbers that get
called different thing depending on how they are used. Some of the identifiers used
by COM:
•
•
•
CLSID
IID
AppID
-
Class identifier
Interface Identifier
Application identifier
These identifiers all have the same format. They are all globally unique identifiers
(GUIDs) also known as universally unique identifier (UUID). GUIDs are a very
large statistically unique number. It is a 128-bit number generated from the address
of the Ethernet card in the current computer together with the current time in 100nanoseconds interval since 1582 and some other things. The generation algorithm
are capable of coming up with 10 million unique numbers every second.
These GUIDs are very useful because they ensure that there will be no two different
components with the same CLSID.
2.8.2 IUnknown
The only way to communicate with a component is trough its interfaces. To get a
pointer to different interfaces the client needs to call a method named QueryInterface
(). This method can return pointers to all other interfaces on the same object. The
QueryInterface () is one of three “IUnknown” methods. IUnknown is an interface that
every COM components need to implement otherwise it is not a COM component.
The other two IUnknown methods are Addref () and Release ().
The Addref () and Release () methods increases and decreases an objects reference
counter. If QueryInterface () successfully returns a pointer to an interface it calls the
Addref () to increase the reference counter and the returning pointer can be used to
call the objects methods thru the interface.
Before destroying the pointer the Release () method must be called to decrease the
reference counter.
18
2.8.3 MIDL – Microsoft Interface Definition Language
The definition of an interface does not include an implementation of its methods, the
implementations is done in the component that is going to implement the interface.
Here follows a simple example of an IDL file:
Import “oaidl.idl”;
The IID
[
object,
uuid(F0059062-C99B-4bcc-B616-058CCE7AFBAC)
]
Interface IHello : IUnknown
The IUnknown interface that all
{
components must implement
HRESULT SayHello ();
};
Figure 2.6 COM IDL file
The import statement at the top of this example brings in the standard types by the
oaidl.idl file, which include many of the standard COM interfaces. The import
statement is similar to C++’s #include.
Then we have one interface, “IHello”, with a single method, called SayHello ()
besides the three IUnknown methods (see 2.8.2).
19
2.9 ActiveX
ActiveX is a set of two other Microsoft technologies called OLE (Object Linking and
Embedding) and COM. An ActiveX control is self-registering and can for example
automatically be downloaded and executed in a Web browser. ActiveX is not a
programming language, but rather a set of rules for how applications should share
information. They can be programmed in a numerous of languages including C, C++,
Visual Basic. [15]
Java applets and ActiveX are similar in some sense but an ActiveX unlike the applet
has full access to Windows operating system. This gives the ActiveX control more
functionality but with it comes a risk that an ActiveX can be programmed to harm the
computer. Microsoft has developed a registration system so the browser can identify
and authenticate the ActiveX control before downloading it. Another difference
between Java applet and an ActiveX is that an ActiveX only runs on Window
platforms.
20
2.10 CORBA
CORBA is the acronym for Common Object Request Broker Architecture, an
architecture and infrastructure that computer applications of various kinds can use to
interact over networks.
It was developed by OMG (Object Management Group), a consortium founded in
1989 [12].
The essence of this technology is the ability to integrate units with little or no
similarities.
CORBA-based applications that are written for different vendors, on different
operating systems and in different programming languages can interoperate through
the “middleware” that is CORBA.
A “middleware” is simply put a type of program that enables other applications to
communicate, taking care of the complexity that lies in the connection. This is a big
help to the programmer who can concentrate on developing the application rather
than for example worrying about how to retrieve data from a remote server object.
CORBA is often used in high rate servers that must handle many clients and has high
reliability.
2.10.1 IDL – Interface Definition Language
A CORBA application can have a numerous of individual objects that encapsulate the
data and its functionality. The objects often represent something from the “real
world”, for example a shopping cart at a web store. There can be many instances
created of the shopping cart object, typically one for each customer. The instances
would be identical in functionality but differ in contained data depending on what
each customer put in their shopping cart.
Every CORBA object requires an interface written in Interface Definition Language
(IDL), which specifies what the object has to offer to the clients that invoke it. When a
client calls the server side object, it must use the interface to specify the operation it
wants to perform.
For successful communication, both client and server objects, regardless of their
platform, operating system and programming language, need to understand the IDL.
An interface definition specifies the operations available, and all of the input and
output parameters including their types, so that both client and server side objects
can encode and decode the values as they are being passed over the network.
Each CORBA object must have a type name, which is the same as the interface
name assigned in its IDL declaration. This name creates a new CORBA type that
contains the operations that are declared inside the interface in the specific IDL.
The variable types that are accepted as in- and out parameters are called “IDL
variables”, these types can be found in a official list. The list includes base types like
integers, floating-points, standard and wide characters, strings and Booleans. It also
includes constructed types such as “struct”, “union” and “enum”. Finally it offers an
“any” type that can be applied to any IDL type under runtime.
21
Here is a very simple example of an IDL definition:
Module Alarm_Event
{
struct Alarm
{
short status;
short acknowledged;
short persistant;
long sequenceNr;
long index;
long alarmID;
long versionNr;
wstring msg;
};
interface IAlarmEventServer
{
bool UpdateAlarm( in Alarm alarmData);
};
};
Figure 2.7 CORBA IDL example
At the top of this example we see a declaration of a “Module” named
“Alarm_Event”. This module is delimited with curly braces “{}”. All types
declared inside the module are valid types inside it, like the constructed
“struct” type named “Alarm”.
Then we have declared an “interface” called “IAlarmEventServer” which will be
translated into a class declaration when compiled. The “IAlarmEventServer” is
also delimited with curly braces. An interface can hold many operations but in
this example it only has one, called “UpdateAlarm” with one input parameter of
the constructed type “Alarm” and also a return value of the type Boolean.
The example shows how to define a simple IDL. But an IDL is just for defining
interfaces and is not a programming language so it has to be mapped to a
programming language which is supported. Note that the IDL does not have
any GUID (see 2.8.1) like the COM IDL. CORBA objects are identified with
names instead.
OMG has defined mappings from IDL to several major programming
languages. It supports standard mappings to C, C++, Java, Smalltalk, COBOL,
Ada, Lisp, and Python. There are also implementations available for mapping
to other languages.
The mapping assigns a language variable type to each IDL variable type and
translates the IDL’s operations format to the languages member function or
other operation formats. When mapping to an object orientated programming
language it might also assign names for the base classes and specifies how
22
the classes should derive from IDL generated classes. Mapping also specifies
memory usage for the client and server sides.
Mapping is done by running the IDL interface file through an IDL Compiler that came
with the ORB. Every ORB comes with one or more IDL Compilers, one for each
programming language that is supports. The compiler will produce the language code
[13][17].
2.10.2 The ORB
The ORB (Object Request Broker) is the service that handles the requests to remote
objects. A client contacts the local ORB and demands to execute something and the
ORB will take care of the rest. It locates the remote object on the network,
communicates the request to the object, waits for the results and then sends those
results back to the client.
The ORB is location transparent, which means that the same request mechanism is
used regardless of where the object that is providing the services is located. It could
be located on the same computer as the client or far away, no difference would be
made in the execution steps.
The figure below shows how the communication works within a single process. The
IDL is compiled into client stubs and object skeletons, and the client and object is
implemented in the language that the programmer(s) prefers. The stubs and the
skeletons will act as proxies for clients and servers. The stub on the client side will fit
perfectly with the skeleton on the server side, even if the two applications are
compiled into different programming languages and running on different ORB’s.
Figure 2.8 A request passing from client to object implementation
Every object in CORBA is unique. An identifying electronic token is used as a
reference to the object when the client wants to invoke it.
It might seem as if the client directly invokes the remote object instance, but in reality
it invokes the stub that was created when the IDL was compiled. The invocation then
continues through the local ORB and the skeleton on the server object side, to get to
the object where it is executed. The picture below displays a communication over
network.
23
Figure 2.9 ORB-to-ORB communications
To be able to communicate with remote objects, the ORB´s must agree on a common
protocol. The protocol in use is called IIOP (Internet Inter-ORB Protocol) and it was
defined by OMG as a standard protocol. Other protocols also exist for different
reasons, but virtually all ORB´s speak the standard IIOP.
24
2.11 SIDL – SPIDER IDL
SPIDER IDL (SIDL) is a framework developed by ABB. The SPIDER IDL Framework
follows a true subset of the OMG IDL v2.3 specification according to the CORBA C++
language mapping specification. SIDL is designed to be high performance, have high
availability and easy to use. SIDL does not implement all of the CORBA ORB
specification but it still implements enough to be a highly performable ORB for use in
industrial systems. The main differences are in how objects are created, looked up
and distributed. It does not support CORBA ORB interfaces like BOA, [18] POA and
IR but have similar features (to read more about these interfaces see OMG home
page [12]).
25
3. Alarm and events in WS500
3.1 SPIDER and WS500
The SPIDER system is a supervisor and a control program for power company’s
electrical net. The server side is based on a UNIX platform while the clients program,
the WS500 (Work Station 500), is based on Windows with a graphical user interface.
Figure 3.1 Current communication configurations
3.2 Current solution
In today’s solution every WS 500 client is connected to the SPIDER server (see fig
3.1). The communication between the server and the clients are through ABB’s own
ORB implementation, named SIDL (see 2.10 about SIDL) meaning that there is one
communication channel between all the clients to the server. This one-to-one
communication channel provides a reliable protocol that ensures that the data which
was sent always comes through if there’s still a physical connection between the
server and client.
When the clients want to see some alarm or events they need do step forward or
backward until the desired alarm or event are displayed. The alarm or event lists are
downloaded from the SPIDER server as a sub set with only a few alarms or event in
them. This gives the user the impression of turning pages.
26
3.3 System performance
The system today may have difficulties to handle and distribute peaks of new alarms
and events say for example, rates up to 1000 alarms per second to many clients
(>500). Under normal circumstances it is probably a much less number of clients that
will communicate with the server at the same time but we must look at some extreme
situations to get a feeling of what challenges we might be facing.
The calculation below are simplified and far from exact but it indicates which
configurations and situations that can be troublesome.
If we assume that we have the unlikely situation with 500 clients connected to one
server. This server would receive in worst case, 1000 alarms with a maximum size of
0,5 KB, a total of 0,5 MB per second (4 Megabit/sec) which is an acceptable load in
a LAN.
It is not likely that all 500 clients are watching and is interested in the newest alarms
but assume that 10% of them are. Then the server needs to update 50 of them with
the new alarm information and that gives us a network load of 50 * 0, 5 MB = 25 MB
(200 Mbit/sec) and that is a large problem. This is why a multicast/broadcast solution
would be a better choice.
27
4. Result of thesis
4.1 Problem Description
Today’s solution has its limitation regarding the alarm and event reporting in the
clients WS500 system. There are not any browsing and filtering options because the
information cannot be transferred fast enough from the SPIDER server due to the
network bandwidth and server capacity. Today’s system could also be slowed down
dramatically if there large peaks of new alarms and events (see section 3.3 for an
example).
ABB is now interested in testing a prototype which could handle large peaks of new
alarms/events and also distribute all of the alarm/event information to all connected
clients so it can be browsed and filtered locally on each computer.
4.2 Problem Analysis
The main problems with today’s system can be split into 2 sub problems.
• Data transfer
How could we deliver a large amount of data to many users with minimal cost on
the SPIDER server load and the network load?
• Sort/filter and browsing capability
How can we achieve that the clients can filter/sort and browse the displayed alarm
and/or event information displayed without downloading it again from the SPIDER
server?
4.3 Data transfer
The main problem in the existing system is to distribute large amount of data in an
efficient way so ABB wanted to use broadcast or multicast technology where one
data package is sent to many clients instead of sending one data package to each
client with unicast.
4.3.1 Broadcast vs. Multicast
The both technologies use UDP packages so they are both unreliable and some
extra controls needs to be added to ensure that that all clients have the latest data.
The main difference between the broadcast and multicast is that all connected
computers in the LAN will receive the broadcasted message even if they are not
interested in them and broadcast messages will stop at the routers interface,
meaning it can only be received in the LAN.
Multicast messages can exceed to other networks but only if the routers are
configured to transport them further, but the broadcast messages stops at the router
interface. But the main benefit over the broadcast is that only the clients who are
interested in the specific multicast messages will receive them by register them self’s
as a member to the switch/router to a multicast group.
28
4.3.2 OPC A&E
I discussed OPC Alarm and Events briefly in section 2.6 because it is in the right
category even if I did not use it. The main reason I did not use it was that the main
problem to distribute large amount of alarms and events to many users in an effective
way would not be solved because it uses DCOM which also uses one-to-one
connections (unicast) similar to ABBs system today.
4.3.3 Conclusion
The technology we choose to distribute data to all clients were by sending multicast
packets because it satisfied the ABB’s requirements best even if it there is a need to
some extra control to ensure that all data has arrived to all clients. But the main
problem with the server and network load will be solved.
4.4 Sort/filter and browsing capability
In the current solution there is no sort or filter options regarding the alarm/event lists
because every request is processed by the SPIDER server and it would slow it down
if there are many users and many alarm/events to iterate for each request and send
the result over the network to each client.
To get the response we want while browsing the alarm/event lists which are
displayed we should try to replicate the entire SPIDER servers alarm/event lists to
the local computer memory. This would give very quick response time and also the
option to filter and sort them because all information is stored locally on each client
computer and does not need to transfer the result over the network.
29
4.5 Component architecture
The entire SPIDER system is built from components, the server side which runs on
the UNIX platform are implemented as SIDL components and the client side are the
WS500 (Workstation 500) which is built mainly by COM components on the Windows
platform.
The prototype that will be presented in this report will have component selection that
would best fit their existing system.
UNIX
WINDOWS
WS 500
SPIDER server
SPIDER A&E
server
SIDL
component
Multicast A&E server/client
SIDL
channel
SIDL
component
(callback)
COM
component
Multicast
channel
A&E Viewer
ActiveX
control
Figure 4.1 Overview of the components architecture (the components are in gray)
30
4.5.1 Multicast A&E server/client
To fit the existing system the Multicast A&E server/client will be developed as a COM
component as it will be a part of the WS500. This component can act as a server or a
client (see section 4.9).It will also have a SIDL component which will act as a callback
for the SPIDER server for alarm and event updates. The component will be written in
C++.
4.5.2 A&E Viewer
The A&E viewer in the WS500 client system will be an ActiveX control written in
Visual Basic because the WS500 system has built in support to load them in a
windows frame. The viewer will be able to display alarms and events in a list with a
scrollbar. The operator will then be able to scroll and filter alarms/events and
acknowledge them or make notes.
4.5.3 SPIDER A&E server
A SIDL component written in C++ will be created in the SPIDER server to support the
Multicast A&E server/client communication.
4.6 Data storage
The Multicast A&E component stores all the alarm and event information when it
shutdowns so they do not need to download them all every time they start the system
again. The information contains the latest sequence number of the alarms and
events so the missing ones can be downloaded from the SPIDER server at startup
through a SIDL connection before it starts sending/receiving multicast messages. All
the data is stored locally on the hard drive.
4.7 Prototype overview
The prototype consists of a SPIDER server component, WS500 Multicast A&E
server/client and a WS500 A&E Viewer. The SPIDER A&E server has the alarms and
events in lists. It also keeps a list of Multicast A&E server pairs (primary and
secondary). There will be a pair of them on each LAN.
The SPIDER A&E server will then send all of the alarm and event updates to the
primary Multicast A&E servers through a SIDL connection. The Multicast A&E server
will then send all new alarm and event updates through the multicast socket which
will be received by the Multicast A&E clients on the LAN.
While the primary Multicast A&E server operates normal the secondary server will
operate as a normal Multicast A&E client but if the primary Multicast A&E server fails
to communicate with the SPIDER, the SPIDER will switch to the secondary Multicast
A&E server instead (see figure 4.2).
31
Figure 4.2 The prototype topology overview
32
4.8 SPIDER A&E server role
The SPIDER A&E server is a remote SIDL component running on a UNIX platform
which will contain the most recent alarms and events, up to 100 000 of them each in
different lists. Its job is to distribute alarms and events to all registered Multicast A&E
servers (one on each LAN) and also to let clients download missing ones.
4.8.1 Multicast A&E server registration
The SPIDER server can have a primary and a secondary Multicast A&E server
registered for each local are area network (LAN). They are stored as pairs in a list.
When a server registers it tells the SPIDER server if it wants to be a primary or a
secondary server. The registration is made by letting the SPIDER server create a
duplicate of the Multicast A&E server callback pointer. Through this callback the
SPIDER can communicate to the Multicast servers.
See appendix A for an example of duplicating an object in CORBA.
If the communication to the primary server fails a preset number of times the server
will assume that the remote object is not operational and will switch to the secondary
server and start communicating with it instead.
4.8.2 The alarm/event lists
The server keeps track over the oldest alarm/event and the newest one by having a
first and a last index counter which point out them in the lists. See fig 4.3 below.
Last
First
99 999
.
.
1
0
Alarm 100 000
….
Alarm 3
Alarm 2
Alarm 1
Figure 4.3 Alarm list with 100 000 alarms
When the lists are full the server starts writing over the oldest of them. See fig 4.4
below.
First
Last
99 999
.
.
1
0
Alarm 100 000
….
Alarm 3
Alarm 100 002
Alarm 100 001
Figure 4.4 Alarm list with over 100 000 alarms
33
The server has a separate sequence number counter for the latest alarm and event.
The sequence counter is not only increased when a new alarm or event occurs, it will
be increased if an existing one is updated also, for example an note is added to an
alarm or if it is acknowledged.
4.8.3 Downloading missing alarms/events
To obtain better performance when clients need to download missing alarms/events
the server has two other lists with a capacity for the 100 000 latest indexes for the
updated alarms and events.
These indexes points out which alarms/events the server should send to the client
from the alarm/event lists. This makes it much faster for the server because it does
not need to iterate the whole lists every time to find the alarms/events with greater
sequence number than the clients.
So for an example, say that the clients last alarm sequence number was 12020 and it
asks the SPIDER server for the latest updates and the servers sequence number is
12023, means that the client misses 3 alarm updates. Then the server will start from
the “last pointer” in the Alarm cache list and send that one and the 2 before it. As we
see in figure 4.4 below, that the new alarm on index 3299 and the acknowledged
ones on index 820 and 77 will be sent.
Last
Index
…
7000
6999
6998
.
.
Updated Index
3299
820
77
…
….
Alarm Cache List
Index
..
3299
..
820
…
77
…
….
New alarm
….
Acknowledged
….
Acknowledged
….
Alarm list
Figure 4.5 Alarm cache list points out the latest alarm updates in the Alarm list
If the difference in sequence number are larger than 100 000 the client will download
all alarm or/and events.
34
4.9 WS500 Multicast A&E server/client
The Multicast A&E server/client is a part of the entire WS500 program which runs on
windows platform. It is mainly built up by 2 components, a COM object and a SIDL
object.
The COM object stores all of the alarms and events and handles the multicasting on
the LAN. It communicates with the WS500 A&E Viewer and process all of the WS500
Viewers requests such as filtering and browsing. It can also update the A&E Viewer
through a callback pointer to the ActiveX control so it keeps the A&E Viewer updated.
The SIDL component will be used to communicate with the SPIDER server for
sending and receiving alarms and events updates (see figure 4.1).
The Multicast A&E can have two different roles; it can act as a server or a client
depending how it is configured before startup. The server and client roles are
described in the following sections.
4.10 WS500 Multicast A&E Server Role
When acting as a Multicast A&E server it can either be registered at the SPIDER
server as primary or as secondary server. If it is chosen as a secondary server it
will act as a Multicast A&E client until the primary server is not operating as it should.
If the primary server would fail for some reason to communicate with the SPIDER
server, the SPIDER would then make the secondary to primary and vice versa (see
figure 4.2).
When the Multicast server is started all the stored alarms and events will be loaded
from the local hard drive. It will then connect to the SPIDER server to get all missing
alarms and events under the offline period until it has them all (identical lists with the
server). After synchronizing the server process all newly incoming alarms and events
form the SPIDER server and send them through the multicast channel out to the
Multicast clients.
It will also periodically send ping messages with the latest sequence numbers to tell
all the clients what the latest alarm end events are. By sending periodic ping
messages it also tells the clients that there is a Multicast server up and running and
has connection to the SPIDER server.
The functionality of the primary server can be illustrated with the state-chart below.
35
Figure 4.6 State-chart for the Multicast A&E server
1. Under the startup it will load every alarm and event stored on the hard drive.
2. All the alarms and events are loaded; try getting an instance of the SPIDER server
object and register.
3. Registration failed. Print error message with possible cause.
4. Retry to get an instance of the SPIDER server object and register.
5. Instance created correctly and registration successful.
6. Download alarms and events until their sequence number matches the SPIDER
servers.
7. Alarms and events sequence number OK.
8. Send multicast packets with new alarms and events updates if there are some.
9. Send multicast ping packets with the latest alarm and event sequence number.
10. Shutdown
11. Save all the alarm and event data to hard drive
4.10.1 Sending multicast packages
To be able to send multicast packages the COM component has a multicast socket
created which it can send the packages through.
See appendix B for a socket creation.
A router and a switch will discard any UDP packages if it will receive too many so to
prevent to flood the network if there for some reason are thousands of alarms per
second, the Multicast A&E server will not send all incoming alarm/event updates as
they arrive. It will instead store them and send a configurable number of them in each
package and wait for adjustable time between them. This will give an even flow of
data in the network even with big peeks of alarms and events.
Every alarm and event data has some overhead with some extra information besides
the actual alarm or event. This is for the system to recognize each alarm/event and
its state etc.
See appendix C for the alarm and event structure.
To ensure that the UDP packages have not been modified, an error check has been
added into each package so called CRC value.
Before the server sends any packages it calculates a CRC value of the content in the
package by using an algorithm known as Cyclic Redundancy Check (CRC). The
result will be a 32-bits integer which will be added to the multicast message. If the
contents of a package are changed, its CRC value changes as well. This allows the
CRC number to be used as a "checksum" at the receiving client in order to identify
whether or not the package has changed.
See Appendix D for an example of creating the CRC table and processing a text
string through it to get a CRC value.
36
4.11 WS500 Multicast A&E Client Role
Every other connected WS500 clients on the LAN runs in Multicast client mode even
the one configured as a secondary Multicast server as long as the primary is up and
running correctly. They all have a SIDL connection directly to the SPIDER A&E
server so they can download missing alarms and events if they need to.
Just like the startup of the Multicast A&E server the client also loads all stored alarms
and events to the memory from the local hard drive. It will then ask the SPIDER
server if it is missing any by asking what the latest ones have for sequence numbers
and download all new ones if there are some. After it has synchronized all alarms
and events so they have identical lists the client will start to accept multicast
messages from the Multicast A&E server by joining the multicast group (see section
2.5).
It has also a timeout function, if the Multicast A&E server is not sending any ping or
alarm/event messages a timeout will occur. It will then warn the client operator that
the Multicast A&E server is not operating as it should but still give the option to
download alarms and events manually from the SPIDER A&E server.
The functionality of the multicast client can be illustrated as the state-chart below.
Figure 4.7 State-machine for the Multicast A&E client
1. Under the startup it will load every alarm and event stored on the hard drive.
2. All the alarms and events are loaded; try getting an instance of the SPIDER server
object.
3. Creation failed. Print error message with possible cause.
4. Retry to get an instance of the SPIDER server object.
5. Instance created correctly.
6. Download alarms and events until their sequence number matches the SPIDER
servers.
7. Alarms and events sequence number OK.
8. Start receiving multicast packets with new alarm/event updates or ping.
37
9. Timeout occurred. No ping or no new packages from Multicast A&E server. Ask
the SPIDER server for the last alarm and event sequence numbers. Download if any
are missing.
10. Shutdown
11. Save all the alarm and event data to hard drive
The behavior 1 to 7 is the same as for the Multicast A&E server role (see section
4.10).
4.11.1 Receiving multicast packages
Every multicasted package is first checked for CRC errors. If it fails the test it will be
discarded otherwise if its new alarm or event updates it will update its own list with
them. If it’s a new ping message with the latest alarm and event sequence number it
will match those with its own sequence numbers. If they do not match it will download
the missing ones from the SPIDER A&E server directly through a SIDL connection.
38
4.12 WS500 A&E Viewer role
The WS500 A&E View is an ActiveX control written in Visual Basic. The WS500
system has built in functionality to open them in a window frame. It is based on a list
control (Microsoft’s MSFlexgrid) with a scrollbar which can display the alarms and
events. In the A&E Viewer the client can acknowledge alarms and make notes to
events. Browsing and filtering the alarm/event information are made by no noticeable
delay due to the local connection to the Multicast A&E COM object (see fig 4.1).
4.12.1 Scrolling alarm/event lists
To optimize the performance in the ActiveX control, the list only stores the same
number of alarms/events that are visible because Microsoft’s MSFlexgrid becomes
slow to scroll if there are many items in the list. In the figure below we can see that 20
alarms are visible but the scrollbar to the right indicates that there are many more.
Even so the list only holds 20 in the memory and when the user uses the scrollbar to
browse the alarms it send the scrollbars relative position to the Multicast A&E object
which translate the position into the correct alarm index and returns the next 20 from
there.
Figure 4.8 Alarms displayed in WS500 A&E Viewer
39
4.12.2 Modifying an alarm/event
The user has the option to write notes on different alarm/events and acknowledge
alarm. When writing a note or acknowledging an alarm there can be a small delay
because the information must travel to the SPIDER A&E server and back to the
Multicast A&E server and out on the multicast channel before the A&E Viewer will be
updated see figure 4.9 for an example.
Figure 4.9 The data flow when acknowledge an alarm
1.
2.
3.
4.
5.
6.
The user acknowledges an alarm and sends the parameters to the
Multicast A&E object (client or server, does not matter in this case)
The Multicast A&E object sends the information to the SPIDER A&E server
through the SIDL connection.
The Spider A&E server updates the alarm status and sends the information
to the Multicast A&E server throw the SIDL connection (The callback to the
Multicast A&E server)
The Multicast A&E server updates its own lists with the new information
and sends it out throw the multicast channel.
The Multicast A&E clients receive the updated alarm status and update its
own lists with the new information and then update the WS500 A&E Viewer
through the callback reference.
The WS500 A&E viewer gets the new information and displays the
modification
The example above shows the data flow throw the network when acknowledging an
alarm but the same procedure is done with any modification on a event or alarm. It
40
must be updated and confirmed by the SPIDER A&E server before the WS500 A&E
Viewer can display the change.
41
4.13 Analysis
I ran some test during the development of the prototype and it seemed to work very
well but the test only included one SPIDER A&E server and one Multicast A&E server
and 4 Multicast A&E clients (which one were running as a secondary Multicast A&E
server). I tested the system by simulating 1000 new alarm/events per second under a
couple minutes and it performed perfectly. I also shut down the Multicast A&E server
so the SPIDER server had to switch to the secondary server and it also worked well.
The prototype met our requirements of the system but to really test what it is capable
of it needs to be tested further in a real environment with hundreds of clients and real
live data. But the prototype indicated that the multicasting technology could work.
The advantages and disadvantages below are my assumptions of the system.
4.13.1 Advantages
The biggest advantage with the multicasting approach is that the SPIDER server load
and the network load is minimized when the SPIDER server only needs to send
updates to one computer on each LAN, the Multicast A&E server, which also only
needs to send one multicast package to all other Multicast A&E clients on the LAN
instead of sending the same package to each and one of them.
Another advantage is that the user now can filter and browse the alarms/events
without any problems or delays because the lists are stored locally on each
computer.
4.13.2 Disadvantages
One disadvantage is if a client is started for the first time or has been offline a very
long time it will take a while for it to “catch up” because it will have to download all
missing alarms/events directly from the SPIDER server until it synchronized the lists.
Another disadvantage is the overhead information needed in every package to
ensure a reliable multicasting and the extra processing with it.
42
Future work
The client sides of the prototype were implemented in the WS500 system but on the
server side it was developed as a stand alone application meaning that the alarms
and events were simulated and was not connected to their SPIDER server and
database.
The prototype was tested on ABBs LAN but only 4 of the computers were connected
as Multicast A&E clients. It worked very good even with large peaks of new alarms
and events and all of them reached the clients.
But to really know how the system would perform it should in the future be tested with
many more clients and the server should be connected so real live data can be used
to give a better understanding on how the would work in a real environment.
43
Conclusion
This master thesis has really gained me much knowledge in programming I had to
learn new technologies such as SIDL (CORBA) and COM since ABBs system was
mainly built up with them. It was not easy at first and I did not know what to expect
and it took some time to get familiar with it but it turned out not to be a problem. The
biggest problem was to get Microsoft Visual Studio 6.0 to compile SIDL together with
the rest of my projects. I also had to refresh my knowledge in TCP/IP for the multicast
functionality.
Designing and coding were the most time consuming tasks. The server on UNIX
platform and the client implementation on Windows were written in C++.
But before I started to develop the prototype I created small test applications in SIDL,
COM and a multicast chat application to get a better knowledge of the technologies.
After that I started to put it all together and the application grew and then I really
started to see why it is so important to document everything because it was a lot of
code produced.
It was a lot of testing and debugging along the way and it was really difficult to that
when I needed to debug one computer in UNIX (the SPIDER server), and one
Multicast server and at least one Multicast client at the same time. I had to write to a
log file to really see what happened sometimes.
At the most I run some tests with a SPIDER A&E server, Multicast A&E server and 4
Multicast A&E clients with very good result when simulating a large number of new
alarms and events (up to 1000 per seconds).
44
References
1. Computer Networks
By Andrew S Tanenbaum
Publisher: Prentice Hall; 3rd edition, 1996
ISBN: 0133499456
2. First-Year Companion Guide, 2dd Edition,
By Cisco Systems
Publisher: Cisco Press, 2001
ISBN: 1-58713-025-4
3. TCP/IP Illustrated, Volume 1, The Protocols
By Stevens W Richard
Publisher: Addison-Wesley Professional; 1st edition, 1994
ISBN: 0201633469
4. http://www.cisco.com/warp/public/535/4.html
5. Distributed Systems
By Andrew S Tanenbaum, Maarten Van Steen
Publisher: Prentice Hall
ISBN: 0130888931
6. http://www.tldp.org/HOWTO/Multicast-HOWTO-1.html
7. http://www.savetz.com/mbone/ch3.html
8. A Router Assisting Control Tree Configuration Mechanism for Relaible Multicast
By I.Chong
ICOIN 2002, LNCS 2343, pp. 84-93, 2002.
Springer-Verlag Berlin Heidelberg, 2002
9. Frameworks for Component-Based Client/Server Computing
By: Scott m. Lewndowski
Department of Computer Science, Brown University
ACM Computing Surveys, Vl.30, No.1, March 1998
10. http://www.opcfoundation.org/
11. Beginning Atl Com Programming, Beginning
By Richard Grimes, Alex Stockton, George Reilly, Julian Templeman
Publisher: Wrox Press, 1998
ISBN: 1861000111
12. http://www.omg.com/
13. C++ Programming with CORBA
By Andreas Vogel, Bhaskar Vasudevan, Maira Benjamin, Ted Villalba
Publisher: John Wiley & Sons Ltd, 1999
ISBN: 0-471-28306-1
14. Inside CORBA
By Thomas Mowbray
Publisher Addison Wesley Longman, 1997
ISBN:0-201-89540-4
15. http://www.webopedia.com/TERM/A/ActiveX_control.html
16. http://msdn.microsoft.com/library/default.asp?url=/workshop/components/activex/intro.asp
45
17. Enterprise Application Integration with CORBA Component and Web-Based Solutions
By Ron Zahavi
Publisher: John Wiley & Sons Ltd, 1999
ISBN: 0-471-32720-4
18. SIDL – SPIDER IDL
Kjell Lyxell
ABB Automation Systems Power Utilities
Reversion 2002
19. Programming Distributed Application With COM And Visual Basic 6.0
By Ted PATTISON
Publisher: Microsoft Press, 1998
ISBN: 1-57231-961-5
20. 5. http://www.erg.abdn.ac.uk/users/gorry/course/intro-pages/uni-b-mcast.html
21. Alarms and Events Custom Interface
By OPC Foundation
Version 1.10, Final Release OCTOBER 2, 2002
46
Appendix A
Example of duplicating a remote SIDL object as a primary server:
The client calls the “AddServerObject” method with its own reference (sink) as a
parameter.
The “m_MulticastServerNode” is the list containing a struct of server callbacks for the
secondary and primary servers and the “index” is a counter of pairs in the list.
void AddServerObject(ALARM_EVENT::ICallback_ptr sink)
{
m_MulticastServerNode[index].Primary = ALARM_EVENT::ICallback::_duplicate(sink);
}
47
Appendix B
Creating a multicast socket in C++
BOOL CMulticastSocket::CreateSendingSocket()
{
// m_SendSocket is of type CAsyncSocket
if(!m_SendSocket.Create(0, SOCK_DGRAM, 0)) // Create an unconnected UDP socket
return FALSE;
if(!SetTTL(m_TimeToLive))
// Set Time to Live as specified by user
AfxMessageBox(L"Warning! Error Setting TTL");
SetLoopBack(m_bLoopBack);
// Enable/Disable Loopback
return TRUE;
}
BOOL CMulticastSocket::SetTTL(UINT m_TimeToLive)
{
/* Set Time to Live to parameter TTL */
if(m_SendSocket.SetSockOpt(IP_MULTICAST_TTL, &m_TimeToLive, sizeof(int), IPPROTO_IP) == 0)
return FALSE;
/* Error Setting TTL */
else
return TRUE;
/* else TTL set successfully */
}
void CMulticastSocket::SetLoopBack(BOOL bLoop)
{
if(!bLoop)
/* if required to stop loopback */
{
bForceNoLoopback = TRUE;
/* Internally making a note that loopback has to be disabled
forcefilly */
// Get IP/Port for send socket in order to disable loopback forcefully */
char localHost[255];
gethostname(localHost, 255);
struct hostent *host = gethostbyname(localHost);
/* Get local host IP */
m_strLocalIP = inet_ntoa (*(struct in_addr*)*host->h_addr_list);
CString Dummy; // Dummy string to be passed to the GetSockName function
m_SendSocket.GetSockName(Dummy, m_nLocalPort);
/* Get Port Number for Sending
Port */
}
}
48
Appendix C
Constructed types in SIDL
These structs shows information stored for each alarm/event
struct Alarm
{
short status;
short acknowledged;
short persistant;
long sequenceNr;
long index;
long alarmID;
long versionNr;
wstring msg;
};
struct Event
{
short status;
long sequenceNr;
long index;
long eventID;
long versionNr;
wstring msg;
wstring comment;
};
49
Appendix D
Cyclic Redundancy Check (CRC)
////////////////////////////////////////////////////////////////////////////////
// Name
// ---// InitCRC32Table
//
// Description & Purpose
// --------------------// This method is called to initialize the CRC table.
//
// Input & Output
// -------------//
//////////////////////////////////////////////////////////////////////////////////
VOID SIDLAlarmEventSource::InitCRC32Table()
{
ULONG ulPolynomial = 0x04c11db7;
// This is the official polynomial used by CRC-32
// 256 values representing ASCII character codes.
for(int i = 0; i <= 0xFF; i++)
{
crc32_table[i]=Reflect(i, 8) << 24;
for (int j = 0; j < 8; j++)
crc32_table[i] = (crc32_table[i] << 1) ^ (crc32_table[i] & (1 << 31) ?
ulPolynomial : 0);
crc32_table[i] = Reflect(crc32_table[i], 32);
}
}
////////////////////////////////////////////////////////////////////////////////
// Name
// ---// Reflect
//
// Description & Purpose
// --------------------// This method is a requirement for the official CRC-32 standard.
//
// Input & Output
// -------------//
//////////////////////////////////////////////////////////////////////////////////
ULONG SIDLAlarmEventSource::Reflect(ULONG ref, char ch)
{
ULONG value(0);
// Swap bit 0 for bit 7
// bit 1 for bit 6, etc.
for(int i = 1; i < (ch + 1); i++)
{
if(ref & 1)
value |= 1 << (ch - i);
ref >>= 1;
50
}
return value;
}
////////////////////////////////////////////////////////////////////////////////
// Name
// ---// GetCRC
//
// Description & Purpose
// --------------------// This method is creates CRCs using the lookup table.
//
// Input & Output
// -------------//
// [in] text - text which will be processed for the CRC value
// [in] len - text lenght
//////////////////////////////////////////////////////////////////////////////////
INT SIDLAlarmEventSource::GetCRC(CComBSTR &text, int len)
{
ULONG ulCRC(0xffffffff); // set bit high
unsigned char* buffer;
buffer = (unsigned char*)(LPCTSTR)text;
// Perform the algorithm on each character
// in the string, using the lookup table values.
while(len--)
ulCRC = (ulCRC >> 8) ^ crc32_table[(ulCRC & 0xFF) ^ *buffer++];
return ulCRC ^ 0xffffffff; // OR operation with the beginning value (all bits set to high).
}
51
APPENDIX E
In the figures below we have two local area networks (LANs) connected to a router.
All the connected hosts on each LAN have IP addresses which are class A, B or C
(see section 2.1.2 figure 2.3).
E 1. Unicast transmission example.
A unicast transmission is between two nodes somewhere on the same LAN or
between two different LANs on the Internet. In this example Host 2 on LAN 1 is
communicating with Host 3 on LAN 2. They communicate by targeting each others
unique IP addresses and port number and the router and switches will transfer the
packages to the correct destination.
52
E2. Broadcast transmission example.
Host 1 on LAN 1 is sending a broadcast message in this example. The switch
receives the message and sends it through all its ports. Every host on LAN 1 and the
router will receive it. But the hosts on LAN 2 cannot receive any broadcast message
from LAN 1 because the broadcast domain is limited to the routers interfaces (it stops
at the router).
All broadcast messages are destined with an IP class E (see figure 2.3).
53
E3. Multicast transmission example.
In this example we see that Hosts 2 and 4 on LAN 1 is receiving multicasted
messages and also the Host 3 on LAN 2. The hosts that are willing to accept these
messages need to join a multicast group first (see section 2.5.1).
When Host 1 on LAN 1 sends the multicast message the switch on LAN 1 will then
forward the message to all hosts in the multicast group (LAN1) and the router.
Normally the multicast domain is limited to the router interface as the broadcast
domain (see E2) but the router can be configured to send multicast messages further
to other LANs and expand the multicast domain as in this example.
The configured router will then send the message to LAN2 where the switch will
check if there are any hosts in a multicast group that matches the received multicast
message. In this example Host 3 has joined and will receive it.
54
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising