WAP Access to SCADA-Typed Database System WAI-LEUNG CHEUNG, YONG YU, YU-FAI FUNG Department of Electrical Engineering, The Hong Kong Polytechnic University HONG KONG Abstract: - This paper discusses the use of the Wireless Application Protocol (WAP) architecture to provide a wireless channel to access the SCADA database operating in the power process plant via Internet network protocol The WAP architecture enables mini-browser operating in a wireless mobile phone such that information sessions between two ends can be established and displayed in a small display window With the WAP protocol stack, advanced features such as data encryption, authentication, synchronization, are supported throughput the wireless sessions Hence, under the wireless environments, the supported WAP service would provide a secure and reliable access to a sophisticated database This interactive mode provides an instant channel to retrieve important data from transactions as well as conducting computational processing on some time-critical events Key-Words: - Wireless Application Protocol, SCADA system, WML, XML 1 Introduction The Wireless Application Protocol (WAP) architecture was developed by the WAP forum [1,2], which was formed in 1997 for the defining of an industry-wide specification for developing applications over wireless communications networks The WAP architecture defines the infrastructure for communication between a mobile client (usually from a cell-phone) and the service provider (the telephone company) The service provider is acting as a gateway, through which the WAP client connects to the content providers, as shown in Fig 1 Due to the limitation of the size of the WAP phone display, contents delivered to a WAP phone are text based and most of the graphics are being stripped away Recently, with the emergence of 25G and 3G devices, we can now show colourful graphics in the display of a mobile phone This can certainly improve the user interface for WAP based applications and therefore, expanding the scope of WAP applications In this paper, we discuss how data from a SCADA database can be collected by a mobile phone based on the WAP protocol The system architecture is first described in the next section and this is followed by the implementation details of the system In Section 4, we discuss how to prioritize data under the SCADA system and the conclusion is given in the Section 5 2 System Structure The WAP Programming Model, see Fig 2, is closely aligned with the Web Programming Model, which uses the Pull Model, (which is where the client requests content from the server) However, WAP also extends the Web architecture by adding telephony support with Wireless Telephone Application (WTA) and enabling a Push Model, where a server can proactively send content to the client, as shown in Fig 2 In WAP protocol of versions 11, a WAP proxy, which is often referred to as a WAP gateway, as
shown in Fig 1, is required to handle the protocol internetworking between the client and the origin server [3-6] The WAP proxy communicates with the client using the WAP protocols that are based largely on Internet communication protocols Hypertext Transfer Protocol (HTTP), and it communicates with the origin server using the standard Internet protocols Our system is developed using the gateway concept and the system architecture is depicted in Fig 3 This programming model is applied to access an SCADA system, the data flow does not stop at the HTTP server, but it continues to flow to the SCADA database or the SCADA program behind the HTTP server Hence, the system structure is much alike a traditional n-tier WAP application 3 System Operations In the HTTP server, referring to Fig 4, a Java Servlet program to handle the HTTP request is provided [7] In the SCADA system, a C++ program is written and it serves as the middle tier between Java Servlet and original SCADA system Communication between the Java Servlet and the middle tier C++ program is through a socket connection, and the middle tier C++ program is encoded into the SCADA system, so that they can communicate through internal program context [8,9] In the SCADA system, data will basically include digital data such as switchgear on/off, alarm on/off, etc, and there are also analogue data including feeder current in amperes, as well as transformer/switchgear output in volts So data transfer between the WAP client and the SCADA system can be divided into 2 major types: integer and double If the compatibility factor is considered, the string data type can also be included for the transfer of arbitrary data types such as error messages An integer ID number has been assigned to each relevant data point in this system These data are represented by the term Figure ID in the program so the data will also be referred to by the Figure ID in the following text The WAP client sends the Figure ID in the URL to the HTTP server, in the following format: http://somesitecom/path/to/scadaservlet?get=figu reid The above input informs the server that the value of this data point is required An URL: http://somesitecom/path/to/scadaservlet?get=43527 means that the client wants to retrieve the data whose ID number is 43527 When the HTTP server receives this URL request, it will invoke a Servlet, and pass the parameter get=43527 to it The Servlet parses the request and sends the command get and the ID number 43527 to the SCADA system through a socket connection between them When the inserted middle tier in the SCADA system receives this get command, it will interpret the ID parameter, and find the corresponding value of the referenced data Thus, it will return the value to the Servlet through the socket connection using command reply with parameter ID=43527 and value=xxxx Once the Servlet gets the replied data value from the SCADA system, it will compile a WML page that contains the value of the data and other relevant information It thus sends this WML page back to the WAP client and the client will see the requested information [10] in the phone display 31 System Initialization Initially, the WAP client knows nothing about the ID numbers and the defined Figure ID But the Servlet and middle tier in SCADA system know which ID number corresponds to which data so that they can address to individual data upon request They also have a mechanism to represent each data in the SCADA system For example, Figure ID 43521 means the output voltage of a transformer in voltage, Figure ID 43522 means the switch status of the above transformer, and so on Thus, defining Figure ID representation in the SCADA database should be achieved during system initialization When the system is brought up, the Servlet establishes a socket connection to the middle tier embedded in the SCADA system as shown in Fig 4
Once connected, the Servlet will first send the command init to initialize the system The middle tier program in the SCADA system should respond with a whole set of WML pages that are similar to what will be displayed in the WAP client This includes menus for data display templates In the display templates, there are texts or tables consist of WML elements representing data s information, and where the data value should be displayed, as referred by a <scada_figure> XML (Extended Markup Language) element The <scada_figure> XML element includes at least an attribute of id that represents the ID of the data The XML element definition is shown in Table 1 The initialization WML may look like the following: <?xml version="10"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 11//EN" "http://wwwwapforumorg/dtd/wml_11xml"> <wml> <card id="card1" title="simple Test" newcontext="true"> <p align="center"> <big><b>select Station</b></big> <br/> <a href="#card21">station I</a><br/> <a href="#card22">station II</a><br/> <a href="#card23">station III</a><br/> <a href="#card24">station IV</a><br/> </p> </card> <card id="card21" title="transformer" newcontext="true"> <p align="center"> The transformer s output current value is <scada_figure id="1"/> Ampere </p> </card> </wml> This WML includes two cards to be displayed [11] In the URL, the selection of Station I will cause the simulator to display card21, as shown in Fig 5a It is noted that the scada_figure element actually can t be recognized and displayed by the mini-browser, as shown in Fig 5b Attributes Id=number The id attribute is a unique integer number that identify a scada_figure element, WAP servlet send this id to SCADA system to request the specific figure Because the init WML is compiled and sent from the SCADA system, so it knows which figure corresponding to a figure id No default value Type = (integer double string) Define the type of the figure An integer consists of 4 bytes, a double consists of 8 bytes, and a string is of arbitrary length The default value is integer Attribute = (readonly writable) This specifies whether this figure can be changed from the client The default value is readonly Value_update = (geteachtime poll noticeonchange) This attribute defines how the client handles a request to this figure The default value is geteachtime Table 1 Attribute definitions for the scada_figure When the Servlet receives this WML page, it will first search for the card that contains scada_figure element(s), then: 1 Find all elements with URL referring to this card, and change those URLs to http://somesitecom/path/to/scadaservlet?get= [ID of the scada_figure] The line: <a href="#card21">station I</a> in the above WML page will be changed to <a href="/scadaservlet?get=[id of the scada_figure]">station I</a> 2 Construct an object according to the scada_figure element and store it in the scada_figure list, the card with id card21 will be removed from the original WML page, and its content will be stored in the scada_figure element s object It will be used to display in the template later After Initialization, if the WAP client tries to accesses the Servlet and requests for the main menu, the Servlet will respond with the changed WML page, the first card: card1 will be displayed on the mobile
phone When the client clicks on the on URL: Station I, the URL /scadaservlet?get=[id of the scada_figure] will be sent to the HTTP server, the Servlet in the HTTP server is invoked and the parameter get=[id of the scada_figure] is requested When the Servlet received the get command, it will pass this command and its parameter: ID of the scada_figure to the SCADA system It then waits for the response (value of the figure) from the SCADA system When the scada_figure element in WML content of card21 is substituted with this response in appropriate format, this WML page is returned to the client Fig 5c depicts the final results as seen by the client In this model, the SCADA system has almost full control from the menus structure to the value s display format The SCADA system can implement auto value update for a specific data solely by editing its display template 4 Prioritized Data Structure Since the data produced by the SCADA system is updated on a regular basis, therefore, the values received by the client must be updated automatically In order to achieve the auto-update mechanism, data is being classified into different priority levels, which will determine the data s update frequency The priority level is encoded into the data ID given in Table 1 The data ID is divided into 3 fields, to carry priority information as well as a data sequence number The data ID is 32-bit long, the first 2 bits represent the Priority field, the following 6 bits is the Refresh Time field, and the remaining 24 bits stand for the data Sequence Number The possible values of Priority are 0, 1, 2, and 3, with 0 stands for the highest priority, 1 stands for normal priority, 2 stands for the lowest priority, and 3 is reserved for later use Priority 0 also implies the notice_on_change value update type as included in Table 1, thus the Java Servlet always be notified when a data of highest priority is changed in the SCADA system, so that it maintains the most up-to-date SCADA data with priority 0 in the memory, if the WAP client request a priority 0 data, the Java Servlet can respond to it promptly with the latest value from the memory cache, the client does not need to wait for the request and response to go through all the way to and from the SCADA system, which is time consuming as well as adding significant overhead to refresh rate Priority 1 implies the get_each_time value update type, the Java Servlet does not maintain copy in the memory cache of data of this type, each time there is a client request for data of this type, the Java Servlet forwards the request to the SCADA system, and waits for the response from the SCADA system The data is then forwarded to client The client has to wait for the request and response to go through all the way to and from the SCADA system, which is time consuming Priority 2 also implies the poll update type, the Java Servlet queries and keeps a copy all the data s value in this priority from the SCADA system after every designated time interval, thus the Java Servlet maintains a memory cache of priority 2 data of some time ago, when the client enquires data of this type, it gets a very fast response, but the value is not up-todate The Refresh Time field sets the time interval requested by the client for refreshing data s value The Sequence Number field is unique for each of the data supported in the system, implying that our system can support up to 2 24 different data, which can cater for future applications, as well as different kinds of database system 5 Conclusion The application of the WAP service is introduced and a system for accessing remote data is discussed in details A sophisticated database (the SCADA system) system is accessed through the WAP architecture via wireless channels The mobile browser developed by Nokia, was designed to operate in mobile telephone It supports the WAP protocol stack and embeds with loader layer This makes the WAP services highly
portable All software components running in the mobile browser are effectively customizable The issues on authorization, airlink operating speed, database size limitation, maximum number of socket session establishment are closely evaluated The access to a database system through WAP service has been successfully implemented and tested The response time of a two-way interrogation is satisfactory and requested data can be correctly retrieved The operation of the WAP architecture on the inter-networking of computing systems can be further extended with the enhancement of mobile IP capability incorporated into the Wireless Transaction Protocol in the WAP protocol stack and it will be our future research direction [2] WAP Server Specification, WAP Forum 1999 [3] Wireless Markup Language Specification, WAP Forum 1999 [4] WMLScript Standard Libraries Specification, WAP Forum 1999 [5] Wireless Application Environment Specification, WAP Forum 1999 [6] WAP Caching Model Specification WAP Forum 1999 [7] Nokia Developer s suite for the JAVA 2 platform, micro edition, user s guide, 2001 [8] Steve Mann and Scott Sbihli, The Wireless Application Protocol, Wiley Computer Publishing, 2000 [9] Marcel van der Heijden, Marcus Taylor, Understanding WAP, Artech House, 2000 [10] WAP Push Architectural Overview, 2001, Wireless Application Protocol Forum, Ltd [11] WAP service developer s guide for Nokia Series 20, version 14, 2002 References: [1] Wireless Application Protocol Forum Specification, WAP Forum 1999 Acknowledgement: This project is supported by the Hong Kong Polytechnic University under the Grant A-PB92 Fig 1 The WAP Gateway Programming Model Fig 2 The WAP Programming Model
Fig 3 The System Architecture Fig 4 Protocols applied in the WAP Operation Fig 5a Display of a Sample Menu Fig 5b Display of information for device Fig 5c Display of data retrieved from the SCADA System