Alarms and events in WS500. Author Peter Adleff

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 - Class identifier IID - Interface Identifier AppID - 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 100- nanoseconds 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 ; [ object, uuid(f0059062-c99b-4bcc-b616-058cce7afbac) ] Interface IHello : IUnknown { HRESULT SayHello (); }; Figure 2.6 COM IDL file The IUnknown interface that all components must implement The IID 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 SPIDER server WS 500 SPIDER A&E server SIDL component SIDL channel Multicast A&E server/client 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 Alarm 100 000... Alarm 3 1 Alarm 2 0 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 Alarm 100 000... Alarm 3 1 Alarm 100 002 0 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 Updated Index 7000 3299 6999 820 6998 77... Index... 3299 New alarm... 820 Acknowledged. 77 Acknowledged. Alarm Cache List 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. The user acknowledges an alarm and sends the parameters to the Multicast A&E object (client or server, does not matter in this case) 2. The Multicast A&E object sends the information to the SPIDER A&E server through the SIDL connection. 3. 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) 4. The Multicast A&E server updates its own lists with the new information and sends it out throw the multicast channel. 5. 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. 6. 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; 3 rd 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; 1 st 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 */ Port */ } } // 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 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