A Low-cost Embedded Web-Server for an Institutional e-Learning Strategy Richard Opio Ocaya
Steven Rwabona Katashaya
Dept. of Physics Univ. of Free State (Qwaqwa Campus) P. Bag X13 Phuthaditjhaba 9866, South Africa Email:
[email protected]
Dept. of Physics and Electronics North-West University (Mafikeng Campus) P. Bag X2046 Mmabatho 2745, South Africa Email:
[email protected]
Abstract—A TCP/IP based scientific instrument control and data distribution system is presented as part of a low cost e-learning strategy of a learning institution to offer remote collaborative science experimentation. The system uses an IEEE 802.3 full-duplex Medium Access Controller (MAC) and Physical Layer Device connected to transducers and actuators for control, data acquisition, distribution and logging over a TCP/IP network. The hardware comprises of a PIC18f2620 and ENC28j60 server interconnected with PC terminals via a network hub. The software comprises the firmware written in C and Javascript, and a simple client web browser written in the Visual Basic.NET framework. The article addresses some concerns about secure access while emphasizing the figures of performance such as round-trip and inter-sample times. Finally, sample outputs of two networked PCs in a typical application to Newton’s law of cooling experiment are presented.
I. I NTRODUCTION The present article describes a system that was developed to remotely monitor, control and acquire transducer data over a TCP/IP network infrastructure. It is an extension of the hardware and software principles of prior work [1], [2] by considering the efficacy of a low-cost collaborative experiment framework over the network or Internet using the designed system. It is generally accepted that the proliferation of TCP/IP networks and Internet technologies implies advantages for data acquisition, distribution and control [3], [4]. Some advantages are: the ease of building TCP/IP networks of high performance to cost ratios; the de facto cross-platform compatibility and inter-operability; scalability and general ease of development. In addition, advances in low cost high-speed embedded controllers that meet the protocol handling requirements for a networked application means that the frontiers of networked data acquisition and control will continue to be pushed back. sThe main hurdles are the general difficulty of coding for the various protocol layers and at present the speed of network response. R Some manufacturers such as Microchip⃝ offer a solution in the form of an embedded proprietary controller that addresses the protocols and specifies the throughputs as high as megabits or gigabits per second (Mbps or Gbps) under certain device test conditions. In practice throughputs will be considerably less due to various hardware and software overheads. Also of growing concern is the issue of embedded system security for which no authoritative direction is yet defined [5]. For
the PIC processor some cryptographic solutions have been attempted that are generally unpopular because of their prohibitive usage of limited RAM [6]. Certainly, the issue of the security of networked embedded systems is nontrivial and will become more central to networked embedded system design [7]. The aim of this article is therefore to present a detailed description of the hardware and software considerations for such a system when it is applied in a collaborative experiment configuration supporting more than one remote client. The design expectations are low cost, low-power consumption, physically small dimensions, adaptability of sensory inputs and ability to support client machines of different specifications. In addition, the need for a customized browser running on client machines and the issue of authenticated client access are also explored. II. S YSTEM A RCHITECTURE A. The digital hardware Figure 1 shows the architecture of the TCP/IPv4 based control and data acquisition system. It listens and responds to requests on HTTP Port 80. It comprises a digital hardware and a software platform. The digital hardware consists of a high performance RISC processor PIC18f2620 processor [8] and the ENC28j60 Ethernet network interface controller (NIC) [9] and also user interfaces such as the PCD8544 graphical liquid crystal display (LCD, commonly used in Nokia mobile phones) and a keyboard switch matrix for user interfacing. These elements are interconnected using a hardware serial peripheral bus (HSPI) and a simulated serial peripheral bus (SSPI) [10], [11]. The 40 MHz PIC18f2620 clock is derived from a phase-locked loop driven externally at 10 MHz. The proprietary NIC device has high reliability and is claimed to support throughput rates of up to 10 Mbps through direct memory access (DMA). The much slower user interfaces are driven at a maximum rate of 10 KHz on the SSPI bus. B. Cost, power and embeddedness The prototype was constructed on double-sided fibre glass printed circuit board (PCB) and has a completed weight of less than 30 grams. The overall dimension of the system makes it unobtrusive, easy to package and add to existing measurement environments [12]. The peak current drawn by the system
Fig. 1: Block schematic diagram of the embedded web server
during a continuous data acquisition application was 200mA on a supply of 5V. C. The TCP/IPv4 protocol layer The system can handle ARP, ICMP, DHCP, IPv4, TCP, UDP, DNS and HTTP requests. The Internet Control Message Protocol (ICMP) also known as the “ping” request was used to generate some of the performance results in a test of the system. The interactivity of server user interface allows the assignment of its IP address statically or dynamically. The handling of HTTP requests and responses is well treated elsewhere [1], [13], [14]. In normal Internet usage the user consciously interacts with pages designed to display information embedded with HTTP statements using a multi-function browser. In contrast the client browser used in this application
is tailored to use HTTP to specifically request, receive and log data into the file system from the transducer environment. This design philosophy departs from the “one tool for all” mentality of the standard browser. This has the advantage of allowing the optimization of the application specific functionality. Many of the controls found in standard browser implementations e.g. hyperlinks, drop-down menus, etc were omitted in the interest of server speed. On the server side interactivity is simplified through a menu hierarchy that is navigated using five push button switches and a graphical LCD. D. The firmware The firmware based control software was developed and compiled for the PIC18f2620 in the C language using mikroC Pro version 3.2 from mikroElektronika [15]. The general flow
Fig. 2: Principle of operation of the remote collaborative experiment server.
Fig. 3: User interface flowchart showing system configuration and flow.
of the firmware is shown in Figure 3. The firmware initializes the HSPI and SSPI buses for Ethernet services and user interfaces, onboard storage for IP addresses, historical data and served HTTP pages. The block labelled “RUN Ethernet server” in Figure 3 implements the main IEEE 802.3 compliant server [9]. 1) The browser-issued structured request: In addition to supporting the various proprietary datagram formats [16] the firmware also implements application level data packaging in a locally developed format that optimizes response size and speed. The firmware issues a GET request [16] and parses the structured HTTP server responses. 2) The client browser and server responses: The server uses a collection of web page templates embedded in the PIC program memory to respond to requests. Javascript statements in the embedded pages are simply replaced by name references to PIC program variables. The Content-Type header responses are specified as “text/plain” for Unicode-UTF8 text that are understood by most browsers. The test application monitors only one channel of the PIC18f2620’s 10-bit ADC to which a LM35CZ temperature sensor is connected. VB.net statements then convert and display and store centigrade temperature on a PC. E. The client-server interconnection and exception handling All client machines are connected to the server through an EnteraSys V2H124-24 port network switch. In this collaborative experimentation set up an automated structured request is issued to the system from each web browser and processed on a polled basis where each client repeatedly searches for an open “server window”. The flowcharts in Figures 5 illustrate the various client- and server-side processes.
III. S YSTEM PERFORMANCE The performance measures of the designed system, set up as in Figure 2, were gauged in two ways. All the client machines had the Microsoft .NET Framework versions 1 to 3.5 installed. In the first test the round-trip times were collected using the “ping and echo” method of the ICMP protocol. In the second test the browser program was started on four client machines of varied specifications at within an arbitrary time intervals. The various tests and their responses are described below. A. Responses to ICMP requests The round-trip time (RTT) was used to estimate the time to wait before retrying a request from the client browser. The RTT gives an impression of the extent of traffic and congestion on the network and is therefore a desirable measure if obtained correctly [17], [18], [19]. To plot the RTT distribution 1000 “pings” each 32-bytes wide were issued on the command line on all client machines simultaneously. The “ping” histograms were similar to the ones shown in Figure 6 that were obtained from nodes 192.168.20.10 and 192.168.20.18. B. Application in collaborative temperature measurement The experimental setup used to test the real data acquisition of the designed system involves monitoring the cooling of water in a Newton’s law experiment. The number of samples was set in a browser textbox to 1000 for each client. Server recovery from a broken connection was tested at 6 minutes by pulling out the RJ45 plug of the server for 50 minutes. The temperatures extracted from the file were plotted for each client node as shown in Figure 7. The results in Figures 6-7 were readily reproduced on any of the IP nodes that were present on the experiment network.
(a) Custom web-browser on client machine
(b) PCD8544 based LCD screen on server
Fig. 4: Client-side and server-side user interfaces
(a) Client side
(b) Server side
Fig. 5: Client and server flowcharts showing the progression from request to authenticated response.
Fig. 6: RTT histograms from two nodes of using 1000 “pings” of 32-bytes packets.
The size of network was limited by the number of PCs available. This scalability [20], [21] is a desirable feature of the system and means that it can include diverse networked
PCs with a minimal of software reprogramming. Since the PIC18f2620 has a limited number of input-output lines, a slave PIC controller can easily be added to the SSPI bus in such a
(a) Client side
(b) Server side
Fig. 7: Plots of raw temperatures extracted from two nodes.
way that the main PIC controller effectively has as many lines as required. IV. C ONCLUSIONS The design, construction and programming considerations of a TCP/IPv4 based Ethernet control and data acquisition system for use in a remote collaboration set up has been described. The system is shown as a viable method to allow institutions to offer basic experiments to multiple remote clients. The design of the system and its general size and unobtrusiveness of the system makes it useful in adapting existing experiments where real world signals can be represented as well-conditioned or proportional voltages. These voltages can then be input directly into the input channels of the analogue to digital converter and subsequently transmitted through the network. The issues of secure access, synchronization, speed and general performance are also described. Through simple tests the parameters of a typical set up are determined. An application test showed that in the typical collaboration experiment each client can receive a measurement response within an average of 105ms. In many experiments the measured variable is slow-varying, and the simple technique above is sufficient. For rapidly changing variables a different approach using the same hardware may use RAM storage on the server board for temporary storage. A client request would then simply retrieve the contents of the RAM at leisure. The maximum RTT found was 1ms with an average of 1.01ms. In view of the set objectives the system demonstrates that an embedded Ethernet system can be created using readily available component and put to serious collaborative experiment frameworks. As newer NIC devices and more advanced faster PIC controllers continue to be manufactured, it is increasingly likely that more wired laboratories will be designed and applied. However, in spite of the achievements described in this article, the issues of security, speed or response still need leave much scope for future work. R EFERENCES [1] R.O. Ocaya and J. Minny, A TCP/IP framework for ethernet-based measurement, control and experiment data distribution, Journal of Instrumentation, http://dx.doi.org/10.1088/1748-0221/5/11/T11001, 2010. [2] M.J. Callaghan, J. Harkin, E. McColgan, T.M. McGinnity, L.P. Maguire, Client-server architecture for collaborative remote experimentation, Journal of Network and Computer Applications 30, 1295-1308. 2007
[3] A.M. Woodroffe, S.W. Pridie and G. Druce, The NEPTUNE Canada Junction Box - Interfacing science instruments to sub-sea cabled observatories , http://dx.doi.org/10.1109/OCEANSKOBE.2008.4531021 MTS/IEEE Kobe Techno-Ocean pages 1-5 (2008) [4] P. Schreier, Connecting instruments to PCs gets simpler, cheaper with LXI system, http://www.scientific-computing.com/features/feature.php? feature id=173 Scientific Computing World, October/November 2007 [5] H. Davis, Secure untethered, IP-enabled devices, Intel Embedded Community (last accessed August 2010). [6] T. Stapko, Cryptography for embedded systems, http://www.eetimes. com/design/ EE Times (last accessed August 2010). [7] P. Schaumont, System Level Design Methods for Secure Embedded Systems, Center for Embedded Systems in Critical Applications, Virgnia Tech. 2005. R [8] Microchip⃝ Technology, Enhanced Flash Microcontrollers with 10-bit A/D nanoWatt Technology, ww1.microchip.com/downloads/en/ DeviceDoc/39626b.pdf Datasheet DS39626B Jan. 2004 R Technology, Stand-Alone Ethernet Controller with [9] Microchip⃝ SPI interface, ww1.microchip.com/downloads/en/DeviceDoc/39662c. pdf Datasheet DS39662C Jan. 2002 R Technology, Ethernet Theory of Operation, ww1. [10] Microchip⃝ microchip.com/downloads/en/AppNotes/01120a.pdf Application note AN1120A Jan. 2008 [11] Freescale Semiconductor, Using the Serial Peripheral Interface to Communicate Between Multiple Microcomputers, http://e-www.motorola. com/files/microcontrollers/doc/app note/AN991.pdf AN991/D Rev. 1 Jan. 2008 [12] S. Heath, Embedded systems design. EDN series for design engineers, 2nd edition. Newnes. 2003 [13] M. Nottingham and J. Mogul, HTTP Header Field Registrations, http: //tools.ietf.org/html/rfc4229 The Internet Society (last accessed August 2010). [14] K. Johnson, Internet E-mail Protocols: A Developer’s Guide, AddisonWesley Professional, 2000. [15] MikroElektronika, mikroC Pro for PIC Microcontrollers, http://www. mikroe.com/eng/products/view/7/mikroc-pro-for-pic/mikroC Pro v3.2 (last accessed August 2010). [16] R. Fielding, J. Gettys, J.C. Mogul, H. Frystyk, L. Masinter, P. Leach and T. Berners-Lee, Hypertext Transfer Protocol – HTTP/1.1, http:// www.ietf.org/rfc/rfc2616.txt Network Working Group June 1999 (last accessed August 2010). [17] P. Karn and C. Partridge, Improving Round-Trip Time Estimates in Reliable Transport Protocols. ACM SIGCOMM ’87. (11-13 August 1987) [18] V. Jacobson, Congestion avoidance and control, Proceedings of SIGCOMM ’88 (Stanford, CA, Aug. 1988), ACM. [19] T. Lindh, A New Approach to Performance Monitoring in IP Networks combining active and passive methods. Passive & Active Measurement Workshop, Fort Collins, USA, 2002. [20] L. Duboc, D.S. Rosenblum, T. Wicks, Doctoral symposium: presentations: A framework for modelling and analysis of software systems scalability. Proceeding of the 28th International Conference on Software Engineering ICSE ’06. pp 949-952, 2006. [21] M.D. Hill, What is scalability?, ACM SIGARCH Computer Architecture News, December 1990, Volume 18 Issue 4, pages 18-21.
