Alarms and events in WS500. Author Peter Adleff

Transcription

1 Alarms and events in WS500 Author Peter Adleff Master thesis in computer science, 20p June 9, 2005

2 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

3 Contents Preface Introduction Technologies overview TCP/IP Reference Model The Layers Internet addresses Port number TCP UDP Routers/Switches Routers Routing protocols Multicast routers Switches Hubs Unicast Broadcast Multicast Multicast groups Multicast Backbone (MBone) Reliable multicasting OPC (OLE for Process Control) OPC Alarm & Events Specification Component technologies Microsoft ATL/COM Identifiers IUnknown MIDL Microsoft Interface Definition Language ActiveX CORBA IDL Interface Definition Language The ORB SIDL SPIDER IDL Alarm and events in WS SPIDER and WS Current solution System performance Result of thesis Problem description Problem Analysis Data transfer Broadcast vs. Multicast OPC A&E Conclusion Sort/filter and browsing capability Component architecture

4 4.5.1 Multicast A&E server/client A&E viewer SPIDER A&E server Data storage Prototype overview SPIDER A&E server role Multicast A&E server registration The alarm/event lists Downloading missing alarms/events WS500 Multicast A&E server/client WS500 Multicast A&E Server Role Sending multicast packages WS500 Multicast A&E Client Role Receiving multicast packages WS500 A&E Viewer Scrolling alarm/event lists Modifying an alarm/event Analysis Advantages Disadvantages Future development Conclusion...44 A. Duplicating a remote SIDL object...47 B. Creating a multicast socket in C 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

5 List of figures 2.1 TCP/IP model layers Two hosts on a LAN communicating with FTP The five classes of the Internet addresses The three-way handshake Interaction between several OPC Alarm and Event Servers and Clients COM IDL file CORBA IDL example CORBA communications within a single process ORB-to-ORB communications Current communication configurations Overview of the components architecture The prototype topology overview Alarm list with alarms Alarm list with over alarms Alarm cache list points out the latest alarm updates in the Alarm list State-chart for the Multicast A&E server State- chart for the Multicast A&E client Alarms displayed in WS500 A&E Viewer The data flow when acknowledge an alarm

6 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

7 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

8 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 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

9 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

10 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 and the highest is 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 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 For example a File Transfer Protocol (FTP) server application should use the port

11 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 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

12 2.2 Routers/switches 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] 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] 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 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

13 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 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 to 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

14 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 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] 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

15 2.6 OPC (OLE for Process Control) OPC is a series of standard specifications developed by OPC Foundation in 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] 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

16 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

17 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

18 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 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 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

19 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(f c99b-4bcc-b cce7afbac) ] 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

20 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

21 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 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

22 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

23 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] 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

24 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

25 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

26 3. Alarm and events in WS 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

27 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

28 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 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

29 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 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

30 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

31 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 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 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

32 Figure 4.2 The prototype topology overview 32

33 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 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 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 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 Alarm Alarm 3 1 Alarm 2 0 Alarm 1 Figure 4.3 Alarm list with alarms When the lists are full the server starts writing over the oldest of them. See fig 4.4 below. First Last Alarm Alarm 3 1 Alarm Alarm Figure 4.4 Alarm list with over alarms 33

34 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 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 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 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 Index New alarm 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 the client will download all alarm or/and events. 34