A TCP/IP framework for ethernet-based measurement ...

Home

Search

Collections

Journals

About

Contact us

My IOPscience

A TCP/IP framework for ethernet-based measurement, control and experiment data distribution

This article has been downloaded from IOPscience. Please scroll down to see the full text article. 2010 JINST 5 T11001 (http://iopscience.iop.org/1748-0221/5/11/T11001) View the table of contents for this issue, or go to the journal homepage for more

Download details: IP Address: 196.21.181.12 The article was downloaded on 07/02/2011 at 10:16

Please note that terms and conditions apply.

P UBLISHED

BY

IOP P UBLISHING

FOR

SISSA

R ECEIVED: August 5, 2010 R EVISED: September 27, 2010 ACCEPTED: October 21, 2010 P UBLISHED: November 17, 2010 TECHNICAL REPORT

R.O. Ocayaa,1 and J. Minnyb a

Department of Physics, University of Free State, P. Bag X13 Phuthaditjhaba 9866, South Africa b Mobile Telephone Networks (MTN), South Africa

E-mail: [email protected] A BSTRACT: A complete modular but scalable TCP/IP based scientific instrument control and data distribution system has been designed and realized. The system features an IEEE 802.3 compliant 10 Mbps Medium Access Controller (MAC) and Physical Layer Device that is suitable for the fullduplex monitoring and control of various physically widespread measurement transducers in the presence of a local network infrastructure. The cumbersomeness of exchanging and synchronizing data between the various transducer units using physical storage media led to the choice of TCP/IP as a logical alternative. The system and methods developed are scalable for broader usage over the Internet. The system comprises a PIC18f2620 and ENC28j60 based hardware and a software component written in C, Java/Javascript and Visual Basic.NET programming languages for eventlevel monitoring and browser user-interfaces respectively. The system exchanges data with the host network through IPv4 packets requested and received on a HTTP page. It also responds to ICMP echo, UDP and ARP requests through a user selectable integrated DHCP and static IPv4 address allocation scheme. The round-trip time, throughput and polling frequency are estimated and reported. A typical application to temperature monitoring and logging is also presented. K EYWORDS : Control and monitor systems online; Trigger concepts and systems (hardware and software); Data acquisition circuits; Digital electronic circuits

1 Corresponding

author.

c 2010 IOP Publishing Ltd and SISSA

doi:10.1088/1748-0221/5/11/T11001

2010 JINST 5 T11001

A TCP/IP framework for ethernet-based measurement, control and experiment data distribution

Contents Introduction

1

2

System architecture 2.1 The digital hardware 2.2 Cost, power and embeddedness 2.3 The IPv4 protocol layer 2.4 The firmware 2.4.1 The browser-issued structured request 2.4.2 The server-issued structured response 2.5 The client-server interconnection 2.6 The server-side and client-side user interfaces

2 2 2 4 5 7 8 8 9

3

System performance 3.1 Responses to ICMP requests 3.1.1 Round-trip time (RTT) 3.1.2 Throughput and command polling rate 3.2 Application in a temperature probe 3.3 Scalability

9 9 9 11 12 13

4

Conclusions

13

1

Introduction

The present article describes a system that was developed from the need to monitor and control various physically distant but related measurement transducers in the presence of a local network infrastructure. The general difficulty of exchanging potentially voluminous command and response data in a multi-transducer environment in the modern wired world makes TCP/IP a potential candidate for development, particularly with respect to scientific data gathering. The methods and system developed are scalable for use even with the Internet. Crucial to any data gathering system is not only the need for speedy and reliable data recomposition for processing or storage, but also the need for accurate synchronization of data sources and targets. Logically, ethernet connectivity is a function of many different but closely related protocols that, implemented correctly, can achieve data throughput rates ranging from a few megabits per second (Mbps) to several gigabits per second (Gbps). In practice throughputs are considerably less due to various hardware and software overheads. The physical media that implement ethernet are just as many and varied and range from coaxial cable, to fiber-optic cables, to various wireless technologies such as Bluetooth and Wi-Fi. This allows many different network configurations to exit, and a vast potential for extensive data acquisition and distribution if used correctly. The advantages of ethernet for

–1–

2010 JINST 5 T11001

1

2 2.1

System architecture The digital hardware

Figure 1 shows the architecture of the control and data acquisition system, tailored to listen and respond to requests on HTTP Port 80. The core of the digital hardware is formed by the PIC18f2620 processor [5] and the ENC28j60 ethernet controller [6]. These devices, together with the PCD8544 graphical liquid crystal display (LCD, commonly used in Nokia mobile phones) for user interface implementation, are interconnected by both a hardware and a simulated serial peripheral interface (HSPI and SSPI) bus [7, 8]. The PIC18f2620 is a high performance RISC processor that supports synthesized clock speeds of up to 40 MHz. The controller was chosen for its large program memory of 64 kilobytes and the high speed phase-locked loop clock speed that guarantees a HSPI bus speed of 10 MHz. This speed is set as the minimum to reliably acknowledge and reply all IPv4 requests. The system attains further high reliability and data throughput rates approaching 50 kbps by implementing Direct Memory Access (DMA). Slower devices such as the user interfaces are driven at a maximum rate of 10 KHz on the SSPI bus. 2.2

Cost, power and embeddedness

The first prototype system was constructed on a 10×13 cm2 strip-board and used as the development board for the ongoing project since it is more adaptable to modifications. All the components,

–2–

2010 JINST 5 T11001

embedded applications are widely acknowledged [1–3]. Established ethernet infrastructure, high performance to cost ratio, cross-platform compatibility and inter-operability, scalability and general ease of development are factors that place ethernet in excellent stead over other communication standards. These are factors that contributed to the rapid growth and proliferation of ethernet-based technologies including the Internet. Ethernet technology has been in use for almost three decades and its relative cost over other interfaces has made it an attractive solution for many measurement and control applications [3, 4]. As the use of extensive world-wide observatories expands, there is increasingly the need to develop a standard interface between a wide variety of scientific instruments to encompass instrument power monitoring, data acquisition and control systems [1]. It is even thought in certain circles that time-tested interfaces such as the General Purpose Interface Board (GPIB) may well be abandoned in favor of the Internet approach [2]. At present, the ready availability of low-cost embedded micro-controllers and network interfaces is stimulating the use of ethernet in low-cost measurement and connectivity in many designs. In this article we present a sufficiently detailed description of such a system that has been constructed, tested and applied in a temperature data acquisition application, with the ability to exert structured control as well. The overarching expectations for the design were low-cost, low-power consumption, physically small dimensions and a highly embedded system. The overall system should be integrable as an add-on module to an existing sensor system to impart network functionality without extensive further programming. In keeping up with the connection terminology of ethernet, the computer issuing the request is henceforth the client, while the designed system that monitors the request and responds in a structured manner is the server. Section 2 describes the hardware and software architecture of the system. Section 3 reports on measurements of round-trip time (RTT), throughput and polling rate. It also describes the sample application.

LM35CZ Centigrade temperature sensor

EEPROM 256 kb SENSOR conditioning arrays

ENC28j60

10 MHz HSPI bus

25 MHz

LCD

PIC18f2620

Ethernet Network Interface Controller (NIC)

Graphical display ( PCD8544 )

Microcontroller 10 kHz SSPI bus

CLOCK Generator

Keyboard

40 MHz PLL

1 4

OK

Hardware PORT control

2

3

Magnetics interface converters & port

SENSOR conditioning arrays

Sound output

10 Mbps ethernet network

Figure 1. A block diagram depicting the principle of operation of the designed client-server scientific instrument interface.

–3–

2010 JINST 5 T11001

Hardware PORT control

ROM memory

with the exception of the PIC and the ENC28j60 were through-hole in the strip-board version. The PIC and NIC on hand were in the Small Outline Integrated Circuit (SOIC) Surface Mounted Devices (SMD) packages and socket adaptation was needed for strip-board mounting. Figure 2 shows the strip-board version. The deployment printed circuit board (PCB) is on an 8×5 cm2 doublesided fibre glass having mostly SMDs but a few through-hole components as well. The main controller circuit board comprised of Small Outline Integrated Circuit (SOIC) Surface Mounted Devices (SMD) packages for the PIC18f2620, the ENC28j60, the 25LC256 E2 PROM and the bus interface devices. The other SMD devices used were resistors, the chip capacitors, the two crystals and the 3.3V regulator. The through-hole components used were the 5V regulator, the 1×1 Tab-UP RJ45 magnetics from Pulse, and two electrolytic capacitors for power supply decoupling. The graphical display and the keyboard switch matrix were mounted together on a 6cm×4cm PCB and joined to the main circuit board using flexible connectors to allow placement on a panel in the completed system. The interface ports to the PIC were brought out to the edge of the board where sensors could readily be connected. The maximum weight of the prototype was about 30 grams. During the temperature data acquisition application the peak power drawn from the supply was found to be about 1 watt (200mA at 5V). This low power requirement makes the use of the system in battery powered applications a possibility. The small physical dimensions of the complete system makes it attractive as an unobtrusive addition to an existing, non-networked acquisition system and increases its potential for embedded designs [9]. 2.3

The IPv4 protocol layer

The ethernet protocol layer was implemented to allow the system to reply to requests originating from five of the eight packet transmission layers collectively called the Transmission Control Protocol and Internet Protocol version (TCP/IP). These layers are (with our implementation shown in braces): the Data Link (ARP), the Network (DHCP, IPv4), Transport (TCP, UDP), Session (DNS),

–4–

2010 JINST 5 T11001

Figure 2. Photograph of the prototype development system on strip-board, prior to construction of PCB. The NIC is mounted underside near the RJ45 connector.

2.4

The firmware

A firmware based control software was developed and compiled for the PIC18f2620 in the C language using mikroC Pro version 3.2 from mikroElektronika [19]. The firmware oversees the initialization of the HSPI and SSPI buses that are used for ethernet services and various user interfaces respectively. Non-volatile onboard storage for user parameters, static IP addresses, historical data and served HTTP pages was implemented using the 25LC256 EEPROM device. The stored pages implemented a library of Javascript functions developed for commonly requested actions such as analog to digital conversion (ADC). The firmware also implements the five TCP/IP layers mentioned above, while providing sufficient support for the user interfaces such as the five push button switches, character mapping for the LCD display, sound for event acknowledgement and analog to digital conversion. The overall design ethos was to create a simple, low-cost and interactive system that is suitable for many scientific interfacing applications. The general flow of the firmware is

–5–

2010 JINST 5 T11001

Application (HTTP), Routing (not used), Tunneling (not used) and Security (not used). The Address Resolution Protocol (ARP) allows the mapping of hardware Link Layer addresses to logical IP addresses. Link Layer addresses are often interchangeably referred to as ethernet addresses and Media Access Control (MAC) addresses. The Internet Control Message Protocol (ICMP), that handles “ping” echo requests, was used here for diagnostic system detection on the network and also to provide an indicator of the response time of the system. The system simply ignores all packets that are not IPv4. Alongside the user specified static IP addressing, the system also has an effective Dynamic Host Configuration Protocol (DHCP) functionality that allows it to lease and renew automatic IP addresses from the host network. Support for the lower level Universal Datagram Protocol (UDP) was included to allow the higher level protocols to interrogate hosts for available services and communicates on any port. The system also complies with the Domain Name Service (DNS) protocol that uses distributed databases to search for available resources on the Internet. Finally, the request/response Hypertext Transfer Protocol (HTTP) was implemented to be the most visible layer. In HTTP the client requests the server using the Uniform Resource Identifier (URI) method in the form of a Universal Resource Locator (URL), the protocol version, followed by a message containing request modifiers, client information, and possible body content. The last message is structured like a Multipurpose Internet Mail Extension (MIME), although HTTP is not a MIME-compliant protocol. This is done to ensure full compliance when exporting HTTP messages to strict MIME environments [11]. The server responds with a status line, including the protocol version of the message and a return code, followed by a MIME-like message containing server information, entity meta-information, and possible entity-body content [11, 17, 18]. The chosen, vastly complex protocols were implemented efficiently at the system firmware level and are, with the exception of HTTP, essentially invisible to the user. Interactivity with the system was then left to web pages running active controls embedded in hypertext, the physical coaxial cables, five push button switches and the graphical LCD. While ethernet technology is already widespread in instrumentation and control applications in industry and science, its usage has tended to be in advanced, high-cost systems, such as networked oscilloscopes. To address the design expectations we thought it necessary to keep TCP/IP protocol visibility to a minimum. This was done in the hope of popularizing such ethernet interfaces for custom scientific and control instrumentation using low-cost embedded devices.

main Menu START

SHOW Menu

NO NO

NO

YES key = 2?

YES

NO key = 3?

YES

NO

key = 1?

YES

SETUP DHCP / Static IP

VIEW system settings on LCD

TEST (TCP, ICMP, Sound, HSPI, SSPI)

key = 4?

RUN ethernet server

ACCEPT default settings

only on INTERRUPT or RESET

Figure 3. Flowchart of the user interface design that involves system configuration, initialization, inspection and server execution.

shown in figure 3. The block labeled “RUN ethernet server” in figure 3 implements the main server that targets the ENC28J60 device that has an industry standard HSPI interface and also full IEEE 802.3 compliance [6]. The version of C used has a custom library of user callable functions called the SPI Ethernet Library (SPIEL) [19]. This library simplifies the development of ethernet applications but demands a PIC with a HSPI bus of least 8 MHz in order to process ethernet requests reliably. The PIC must also have more than 4 kilobytes of program memory. For this reason a PIC18 device must be used rather than a PIC16. The PIC18f2620 is practical as it supports a 40 MHz PLL clock derived from a 10 MHz external crystal clock. However, by circumventing SPIEL the lower level functions [6] of the ENC28j60 are accessible directly and can be used to address

–6–

2010 JINST 5 T11001

YES was key pressed?

2.4.1

The browser-issued structured request

Apart from assuring conformity with the various proprietary datagram formats [11] that are part of TCP/IP, the firmware implements a form of application level data packaging in a local format in such a way that responses to structured requests are made expeditiously. We developed simple methods to efficiently structure both the client browser-issued HTTP request and the serverissued response. This was done in a manner that did not compromise the speed of response or exceed the server response size constraint. The firmware listens to requests and uses the GET method [11] to parse command or data from the client. For example, when the user specifies the root URL: “http://196.168.20.60/”, upon successful connection it is decoded by the firmware to mean: “GET /”, with the underscore denoting a single space. In essence, the firmware establishes the array GetRequest[i], where i=0, 1, . . . , m and m is the maximum count of characters specified in the URL. Thus the above root URL implies the byte array GetRequest[ ] = {G, E, T, , /}. Then for example GetRequest[0]=“G”, or GetRequest[4] = “/”. In this way it is possible to structure a request by specifying additional characters in the URL and then decoding them at firmware level for the desired action. For example, accessing “http://196.168.20.60/s” leads to GetRequest[ ] = {G, E, T, , /, s} where GetRequest[5] = “s”. By interrogating array element 5 the course of action of the processor can be decided. In the designed system the character “s” was used to serve a web page that displays sampled water temperature at 10-second intervals. Additional control was exerted on the system through extra characters. The character “d” is used to synchronize the server time with the client time. For example, if Javascript reads the client time at “13:44:56”, it issues an automated access request at “http://196.168.20.60/d13:44:56”. This is resolved by the server firmware to global

–7–

2010 JINST 5 T11001

certain practical limitations observed when using the SPIEL, although this was not done in the present system. SPIEL is an integral part of the mikroC Pro compiler whose usage is governed by mikroElektronika’s End User License Agreement (EULA). The development of commercial applications is permissable within the terms of the EULA. The main MAC function within SPIEL is the SPI Ethernet doPacket() that is called repeatedly within an infinite loop inside the block labeled “RUN ethernet server”. On the successful reception of packets the order of processing is: ARP, ICMP, TCP and then UDP. The first two are replied automatically. TCP packets invoke a TCP handler function where the exact course of action in response is specified by the user. The arguments of this function are the remote host address, the remote port, the local port and the request length generated using either the GET or the POST method. In this present system the GET method is used, as described in section 2.4.1. Similarly, UDP requests invoke a UDP handler function in which the user also specifies the responses to UDP packets. It has the same arguments as the TCP handler. The main MAC function implements error trapping through return values for the developer. For example, its return values cover the following scenarios: packet processing succeeded; corruption of the ENC28j60 receive buffer occurred; packet was not destined for the system; packet was not IPv4; packet type is unknown to SPIEL.

variables of time: “Hours=13”, “Mins=44” and “Sec=56”. This time basis allows time critical processes on the server to be monitored or time-stamped. The character “e’, followed by 4-four digit numbers were structured to determine whether to toggle a given output line, or to read a specified line, or simply to issue out a specified number of controlled pulses on a given output line. 2.4.2

The server-issued structured response

2.5

The client-server interconnection

All client machines are connected to the server through an EnteraSys V2H124-24 port network switch. Once an HTTP access request is issued to the system from a web browser it is decoded and the precise responsive action is decided by the control software. For example, a simple site access request merely solicits the return of an ActiveX control or a page with Javascript statements and may in addition return data to the browser. A typical data that may be returned could be the 10-bit result of ADC conversion on a specified channel as “var DegreesC = 0x307”. The Java/Javascript statements then convert it to an actual temperature based on the known properties of the ADC

–8–

2010 JINST 5 T11001

To respond to client requests the server uses a collection of web page templates embedded in PIC program code space. Any javascript statements on the stored page are simply replaced by name references to PIC program variables. The Content-Type header returned to the client are either “text/plain” or “text/html” depending on the exact structured request made by the client. For example, upon parsing the GET request with character “s” the PIC firmware puts into the ENC28j60’s transmission buffer the Content-Type header that informs the client to expect a plain text response. The firmware then starts the conversion of the channel specified in the request. Upon completion the 10-bit numeric “Value” is converted into a conforming plain text string representation of “Value” preceded by the javascript variable name reference before being appended to the transmission buffer. On the other hand, if the parsed GET request contains no additional character then the Content-Type header specifies “text/html”. In that case the client would expect to receive copies of the stored web pages populated with variables at their most recent values. In this way the client machine would simply display the state of the variable within the client’s browser. We considered the alternative possibility to structure server response that would embed references to an external computer-based server on the network wherefrom javascript updates may be deployed. This approach is attractive because it avoids reinvoking the software development cycle every time the javascript code must change. This is because PIC-based javascript would necessitate a complete rebuild and reprogramming of the firmware. However, considering the programming and performance speed implications it is left in the scope of future work. In the test application water temperature was measured using a LM35CZ temperature sensor connected to one channel of the ADC on the PIC18f2620. A typical response is “var temperatureADC; 0x307;”. To minimize communication overheads, the conversion of the 10-bit ADC result into an actual centigrade temperature was done at the browser level using a single Javascript statement. This is convenient since variables are passed by reference between the firmware and Javascript. The number of characters returned in the response must not collectively violate the known 1.5 kilobyte size constraint, discussed in section 2.5. A response typically involves the declaration by name of a variable and also its measured value. To optimize this response, redundant spaces were removed and variable names kept to a minimum.

2.6

The server-side and client-side user interfaces

Figures 4 and 5 show the appearance of the client-side and server-side user display interfaces respectively during different client request and server response processes. Figure 4 shows access using Microsoft Internet Explorer but similar results were observed using Mozilla Firefox and Google Chrome. No other browsers were tried. The client machines variously had the .NET Framework versions 1 to 3.5. For the sake simplicity the firmware parses only the Content-Type in the client “Accept” header field [11]. All other requests are ignored at present and subsequent development is intended to address these aspects.

3

System performance

The performance of the designed system was gauged in three ways. In the first test the direct visibility and connectivity was tested using the “ping-echo” method of the ICMP protocol. The second test was more subjective, and gauged the ease with which the user interfaces were operated. It was found that potential users found it friendly and stable, and offered valuable suggestions for improvement that were then incorporated. The third test proved to be the real acid test, namely a practical data acquisition run. The various tests and their responses are described below. 3.1 3.1.1

Responses to ICMP requests Round-trip time (RTT)

RTT is central to reliable transport protocols and is defined as the time interval between sending a packet and receiving its acknowledgement. It is used to determine when the retransmission of unacknowledged, presumably lost, packets will occur. The interest in the accurate quantification of

–9–

2010 JINST 5 T11001

converter. Accessing controls such as buttons, drop-down menus, text boxes sends structured HTTP requests to the hardware, which are then decoded into actions such as “Read channel m, reset Device k”, etc. While the exchange of data between the browser and the hardware is efficient, some limitations have been observed in the current approach. For example, the maximum HTTP served page is limited to 1.5 kilobytes. This limitation was minimized by writing a more storage efficient code. A second limitation arises from the contemporary issue of secure file system storage access. For example, Javascript by default does not have methods that grant a server/client direct or output stream access for a served page on the client/server machine. Any attempts by the designed system to save data on the remote filesystem will therefore fail. The solution was to write a toneddown TCP/IP browser client program in Java or Visual Basic.NET with specialized file stream access methods. This transfers the onus of assuring secure file access onto the developer. Clearly, for environments such as the PIC server in question no lasting solution to the problem of firmware based secure access is yet known. Placing the system behind a firewall may be the best option yet. This leaves the solution of the challenges with much scope for future work as well. For the PIC processor a few cryptographic solutions have been attempted but are generally unpopular because of prohibiting use of limited PIC random access memory (RAM) [12]. It is acknowledged therefore that the issues of assuring the security of networked embedded systems is nontrivial but are increasingly likely to become increasingly center-stage [16].

(a) HTTP access.

(b) Output line pulsing with 5 pulses.

(c) Output toggling.

Figure 5. Pictures of the LCD during various server processes.

RTT is directly linked to factors of traffic and congestion that have arisen from the explosive growth in the size and complexity of TCP/IP networks. It has been shown that the standard approaches to estimating round-trip times for TCP are inaccurate where packets are lost or RTTs have high variance [13–15]. To plot the RTT distribution for the system the Windows “ping” command was used with console output redirected to a text file. For example, 1000 pings each consisting of 32-byte packets were sent using the command ping -n 1000 -l 32 192.168.20.60 >> text1000.txt The RTT times were extracted from the file and their bin-centered frequencies plotted as shown in figure 6. In an earlier version of the firmware the average RTT was found to be high at 1.3s and was initially thought to originate in the ENC28j60 controller. Stopping the PIC’s delay-based software clock gave a marked improvement in RTT to 1.01ms with a variance (RMS) of 0.14ms. This makes the point that overall code optimization will improve system response times.

– 10 –

2010 JINST 5 T11001

Figure 4. Appearance of a served page showing a hyperlink, a drop-down menu, a button and text-box active controls implemented in Javascript. Note the current sensor temperature displayed.

Figure 7. Screen shot of the browser for inter-sample time and throughput estimation.

3.1.2

Throughput and command polling rate

In this present context throughput is defined as the average rate of successful data delivery over the physical link between the PIC server and the requesting client machine. Estimates of the minimum inter-sample time interval and throughput were done using a simplified Visual Basic.NET web browser where the number of samples and inter-sample time were specified arbitrarily. The simplified browser approach has a number of advantages. Firstly, it simplifies experiment datalogging by overcoming the direct filesystem access restriction of standard browsers mentioned above. Secondly, because of the absence of many of the extra features of standard browsers such as multi-scenario exception error handling and security it was more streamlined in its time responses. Thirdly, its polled basis provides a method to estimate the maximum rate at which control com-

– 11 –

2010 JINST 5 T11001

Figure 6. Plot of the responses from 1000-ping requests using 32-byte packets.

mands may be issued as well. In application, the browser issues an HTTP data request, receives the data, and then logs it into a RAM array. It repeats the process while counting down the number of specified samples to zero, whereupon the RAM array is written into a text file. This method minimizes the contribution of disk-access time overheads to the response time. Figure 7 is a screen shot of the program for 100-samples. In the application, text-file logs have current date and time and temperature fields. The system time contains an additional field for millisecond time. Two typical contiguous text file entries are: 9/22/2010 4:12:44 PM 303 21.96C 9/22/2010 4:12:44 PM 573 21.96C In the experiment data was repeatedly requested from the interface at “http://192.168.20.60”. The time interval between two samples (ts ) is the sum of the request time (22 bytes sent) and the response times (1500 bytes). The greater part of this time is therefore due to the response. Figure 8 shows the inter-sample time distribution using 1000 samples. The average ts was 296ms with 55ms variance, giving a throughput of about 45 kbps. The command polling rate is the maximum rate at which a command is issued from a client machine and successfully acted upon by the server. This could be the rate at which a switch is remotely opened and closed. The PIC firmware was modified to toggle a port line when “GET /a” request is received from the client. Direct measurement of the toggling rate using a MajorTech MT24 frequency meter on the port line gave a maximum frequency of 15 Hz, or a minimum repetition time of 67ms. The throughput and frequency figures have been obtained on the system “as is” and without attempts to strictly optimize both the firmware and the browser program. Optimization would further reduce communication overheads and improve the measured responses. 3.2

Application in a temperature probe

The experimental setup used to test the real data acquisition of the designed system involves heating up 500 milliliters of water to boiling point and then monitoring its temperature as it cooled towards room temperature. The ambient temperature was 23◦ C and the initial temperature was 91.6◦ C. The experiment was stopped after 2 hours, or about 7000 individual HTTP requests. It would

– 12 –

2010 JINST 5 T11001

Figure 8. Histogram of time intervals between samples in a repeatedly polled ADC application.

have taken several hours to reach equilibrium with room temperature. The raw result data of the experiment is shown graphically in figure 9. The breaks at 100s and 1000s in figure 9 are due to a physical disconnection of the ethernet cable for a few seconds to evaluate system recovery from a broken connection. 3.3

Scalability

Scalability, though generally difficult to define [20, 21], is here meant in the context of measured and/or controlled variables to be the ability to add more measurement/control lines 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 way that the main PIC controller effectively has as many lines as required. Although this was not done in the present article, it would involve no modifications at the communications protocol layers. Therefore in the sense of Internet connectivity the system is scalable.

4

Conclusions

A TCP/IP based ethernet control and data acquisition system has been designed and constructed. We present the system as a way of interfacing scientific and control instruments to a host computer through an existing network infrastructure. The possibility of adapting existing non-networked data acquisition systems is also indicated. While such interfaces have been in use for over a decade they have tended to be confined to expensive and highly specialized instruments. The article argues that the availability of new and abundant low cost devices for network control and communication makes the embedded ethernet interface an attractive possibility for any data acquisition and distribution system. During the mock deployment of the system amongst colleagues an endearing feature of the system was reportedly the level of interactivity of the client and server user interfaces. In their view this helped to clarify the use of the system for serious control, measurement and data distribution over a TCP/IP network. The temperature monitoring application was used as

– 13 –

2010 JINST 5 T11001

Figure 9. Typical results of the system when applied to temperature measurement in a Newton’s cooling law experiment. The cooling rate constant k for water was found to be 0.0145/min.

Acknowledgments We would like to thank Frederick Mudhavanhu from the Computer Science Department at the University of Free State for his review and suggestions on the manuscript.

References [1] A.M. Woodroffe, S.W. Pridie and G. Druce, The NEPTUNE Canada Junction Box — Interfacing science instruments to sub-sea cabled observatories, MTS/IEEE Kobe Techno-Ocean (2008), pg. 1–5. [2] P. Schreier, Connecting instruments to PCs gets simpler, cheaper with LXI system,Scientific Computing World, October/November (2007). [3] D. Potter, Using Ethernet for Industrial I/O and Data Acquisition, National Instruments Corporation. [4] D. Potter, Update and Overview of IEEE 1451.4 Interfaces and Applications, National Instruments Corporation, Sensors Expo 2005, June 7 2005. [5] Microchip Technology, Enhanced Flash Microcontrollers with 10-bit A/D nanoWatt Technology, Datasheet DS39626B January (2004). [6] Microchip Technology, Stand-Alone Ethernet Controller with SPI interface, Datasheet DS39662C January (2002). [7] Microchip Technology, Ethernet Theory of Operation, Application note AN1120A January (2008). [8] Freescale Semiconductor, Using the Serial Peripheral Interface to Communicate Between Multiple Microcomputers, AN991/D Rev. 1 January (2008). [9] S. Heath, Embedded systems design. EDN series for design engineers, second edition, Newnes, (2003). [10] N. Bezroukov, TCP Protocol Layers, Open Source Software Educational Society (last accessed August 2010).

– 14 –

2010 JINST 5 T11001

the acid test for the system that eventually showed that it exceeds its design expectations, namely low-cost, low-power, size and embeddedness. Using the simple “ping” test the RTT was measured at 1.01ms with low variance, the throughput at 45 kbps and the maximum output switch polling rate at 15 Hz. The initial results obtained from these tests highlight the need for a code optimization strategy for both the PIC firmware and browser program. For example, the use of time intensive operations such as screen updates, user displays and file storage can be kept to a minimum. Other identified limitations of the system are the size constraint of the served page and the far reaching issue of security assurance. While the SPIEL library is extremely useful and versatile, it is necessarily heuristic due to its commercial nature. Library related problems such as the 1.5kb response limit tend to be more difficult to resolve since the EULA protects the code from dissection. The low-level approach to accessing features of the NIC appears daunting on the outset, but can lead to a source code that is more open to scrutiny and therefore having fewer bugs. However, in view of the set objectives, the system demonstrates that an embedded ethernet system can be created using readily available low-cost embedded devices and put to serious control, measurement and data distribution applications.

[11] R. Fielding et al., Hypertext Transfer Protocol – HTTP/1.1, Network Working Group June (1999) (last accessed August 2010). [12] T. Stapko, Cryptography for embedded systems, EE Times (last accessed August 2010) [13] P. Karn and C. Partridge, Improving round-trip time estimates in reliable transport protocols, in Proceedings of the ACM workshop on Frontiers in computer communications technology (SIGCOMM ’87), J.J. Garcia-Luna-Aceves ed., ACM, New York U.S.A. (1987) [DOI]. [14] V. Jacobson, Congestion avoidance and control, in Symposium proceedings on Communications architectures and protocols (SIGCOMM ’88), Vinton Cerf ed., ACM, New York U.S.A., pg. 314–329 [DOI].

[16] P. Schaumont, System Level Design Methods for Secure Embedded Systems, Center for Embedded Systems in Critical Applications, Virgnia Tech. (2005). [17] M. Nottingham and J. Mogul, HTTP Header Field Registrations, The Internet Society (last accessed August 2010). [18] K. Johnson, Internet E-mail Protocols: A Developer’s Guide, Addison-Wesley Professional, (2000). [19] MikroElektronika, mikroC Pro for PIC Microcontrollers, mikroC Pro v3.2 (last accessed August 2010). [20] L. Duboc, D.S. Rosenblum and Tony Wicks, A framework for modelling and analysis of software systems scalability, in Proceedings of the 28th international conference on Software engineering (ICSE ’06), ACM, New York U.S.A. (2006), pg. 949–952. [21] M.D. Hill, What is scalability?, ACM Comp. Ar. 18 (1990) 18.

– 15 –

2010 JINST 5 T11001

[15] T. Lindh, A New Approach to Performance Monitoring in IP Networks — combining active and passive methods, Passive & Active Measurement Workshop, Fort Collins U.S.A., 2002.