A Web Connected Smart Sensor M. Popa1, A. S. Popa2 and C. Patitoiu3

1,3Faculty of Automation and Computers, “Politehnica” University of Timisoara, Romania 2Faculty of Mechanical Engineering, “Politehnica” University of Timisoara, Romania

Abstract— A smart sensor is the convergence of the sensing features of a sensor with the intelligence and decision features of a microcontroller or DSP based microsystem. The communication feature of a smart sensor is compulsory. It must communicate vertically and horizontally too. The vertically communication is down with the process it senses and up with a processing and decision system. The horizontally communication is with other smart sensors. There are several ways for communicating: with direct physical connections, wireless, by Internet or combined.

This paper describes an Internet connected smart sensor. The sensed parameter is the temperature but it can be applied to other parameters too. The Web connected smart sensor is made by a TINI platform, a LM75A temperature sensor and the appropriate software. The sensor is connected to the TINI platform through a I2C interface.

I. INTRODUCTION

Smart sensors are rapidly developing and spreading. Many application based on them are introduced in medicine, textile industry, automotive industry, military domain, surveillance and monitoring domains, security and so on.

Smart sensors are the main support for ubiquitous and pervasive computing which constitute the new wave in the large computing area. If the first wave was based on mainframes, the second wave was based on personal computers, the third one is based on many small intelligent systems spread all around us, communicating between them, sensing us and interacting with us.

The smart sensor is the convergence of the sensing features of a sensor with the intelligence and decision features of a microsystem.

A good smart sensor definition can be found in [1]: “sensors are instrument packages that are microprocessor driven and include features such as communication capability and on-board diagnostics that provide information to a monitoring system and/or operator to increase operational efficiency and reduce maintenance costs”. The term “microprocessor” is generically used in this definition, in our days smart sensors are based on microcontrollers or/and DSPs.

The communication feature of a smart sensor is compulsory. It must communicate vertically and horizontally too. The vertically communication is down with the process it senses and up with a processing and decision system. The horizontally communication is with other smart sensors. There are several ways for communicating: with direct physical connections, wireless or by Internet. Also mixed solution can be implemented according to the application requirements. Due to the existence and worldwide of the Internet, this solution is largely used.

This paper describes an Internet connected smart sensor. The sensed parameter is the temperature but it can be applied to other parameters too. The next section presents related works, the third section delimitates the smart sensor notion, the fourth section details the created smart sensor and the last section outlines the conclusions.

II. RELATED WORK Smart sensors and applications based on them are present in

many papers. In references [1] and [2] definitions for smart sensors, their

features and an overview on the used technologies are introduced.

Reference [3] presents the standard for interfacing smart sensors to networks, namely IEEE 1451. A set of specifications consisting in a unifying set of functions, communication protocols, a common set of commands and electronic data sheet formats was developed. The paper describes also how to use the features mentioned in standard in applications.

Reference [4] describes Intel Mote, Imote, which is a sensor network platform targeted for research and commercial applications. It is desired to develop a platform for building a small, modular unit that can be easily customized for various applications. The Imote has also wireless resources, a Bluetooth compatible module.

Other classical achievements, MICA2DOT and MICAz motes are described in references [5] and [6].

In reference [7] a methodology for monitoring industrial processes and plant that can be implemented cost-effectively within small-to-medium enterprises is described. The methodology is implemented on a network of 8-bit microcontrollers communicating with each other on a controller area network (CAN) bus. The microcontrollers can be remotely accessed through Internet. The software models developed for data acquisition nodes and the design of remote user interfaces and supervisory nodes are also explained. The system is aimed at providing specific maintenance guidance and fault identification, rather than gathering data for off-line analysis. The methodology emphasizes the use of process controller signals for fault detection and sensor signals for fault isolation.

A larger perspective is presented in reference [8]. The use of motes and TinyOS for a mobile sensor platform is evaluated. An IEEE 802.15.4 full functional device MAC layer with beacon support was implemented and it was we discovered that running this MAC layer was too much for the motes. Starvation and too slow data transfer between layers in TinyOS was obtained. It was tried to overcome the starvation problems by introducing means to limit the high number of timer interrupts required by the MAC layer. It was concluded that motes and TinyOS are insufficient for the 802.15.4 full functional device MAC layer and that the platform is having problems running applications with a high frequency of interrupts, and still execute useful code in between.

The paper from [9] presents an overview of IRISNET, a sensor network architecture that enables the creation of a planetary-scale infrastructure of multimedia sensors that can be shared by a large number of applications. IRISNET enables the storage of sensor readings close to their source by providing a

1-4244-1234-X/07/$25.00 ©2007 IEEE. 105

convenient and extensible distributed XML database infrastructure. It also provides a number of multimedia processing primitives that enable the effective processing of sensor feed in-network and at-sensor.

In reference [10] four types of sensors: MICA2DOT, MICA2, MICAz and TelosB were investigated in order to estimate the influence of a cryptography application to their life time.

In the present paper the implementation of an Internet connected smart sensor is presented. It is used for measuring temperatures but it can be easily adapted for other types of measurements too.

III. THE SMART SENSOR NOTION A smart sensor is the convergence between the sensing

capabilities of a sensor and the intelligence of a microsystem, based on microcontrollers or DSPs. Fig. 1 presents the block diagram of a smart sensor.

Fig. 1. Block diagram of a smart sensor

The measurements are made by the Sensing module, than the information is processed (amplified, filtered, liniarized etc.) by the Signal processing module, after that the information is converted from analog to digital and passed to the μS. The microsystem is based on microcontroller or DSP, it can contain also external memory (if the internal memory of the mentioned circuits is insufficient). It can memorize the information, change the data format, take decisions and communicates with other smart sensors or with a higher leveled system.

The main features of a smart sensor are: - communication capabilities; - processing of the gathered signal (amplification, filtering, linearization) for increasing the measurements accuracy; - analog – digital conversion: the conversion methods affect the speed and the accuracy; - possibility to sense more parameters; - possibility to memorize the collected data: thus a history of the measurements can be obtained: evolution in time, average value, maximum or minimum value etc. - keeping of the current time: it permits to correlate the measurements to time thus certain tasks can be implemented at predefined moments; - possibility to calibrate the sensor by program and self-calibrating capabilities: the parameters can be programmed locally or remotely, with higher resolution than in the conventional calibration; - self-identification;- self-validation: it increases the reliability of the sensor; a smart sensor can report special events, a

dangerous level of the power supply (especially in wireless applications), recalibration etc. - self-adaptation: a smart sensor must be capable of affecting the speed – accuracy relationship, to decrease the energy consume (when possible), to modify the clock frequency (for lowering the consume); - compatibility with standard communication and control protocols; - plug-and-play connectivity; - network connectivity: there two ways: direct connection or through a gateway.

In present a lot of protocols are implemented on smart sensors: IEEE 1451, Ethernet, RS 232, I2C, SPI, CAN, 1 Wire, Micro Wire and so on. Also protocols for wireless communications are implemented on sensors: ZigBee, Bluetooth and so on.

IV. THE WEB CONNECTED SMART SENSOR

A. The hardware implementation The Web connected smart sensor is made by a TINI platform

and a LM75A temperature sensor. The TINI (Tini Inter Net Interface) is a microcontroller based

system with Ethernet interface and a Java programming environment, [1]. The facilities offered by the hardware are accessible for the software developer through a set of APIs Java. It permits also the use of the assembler and C languages but it will not be possible to use the implemented TCP/IP stack an alternative TCP/IP stack being necessary.

The TINI platform can be used in applications such as: industrial control, remotely monitoring and control of different equipments, protocol conversions, environment monitoring etc.

The hardware composition of the TINI platform consists in, fig. 2: the DSC80C390 or DSC80C400 microcontroller, 512 KB or 1 MB Flash memory, 512 KB or 1 MB SRAM memory, the Ethernet controller and the real time clock. An external power supply is needed but an internal battery exists too for the real time clock and for keeping the SRAM powered when the external power drops.

The DSC80C400 microcontroller has high performance 8051 architecture. It has internal 64 KB boot ROM, 9 KB SRAM and can access an external 16 MB flat memory space. Its internal peripheral is various: four 16 bit timer/ counters, watchdog timer, oscillator fail detector, CAN 2.0 controller, I2C and SPI interfaces, one 1-Wire interface, two UART serial ports and one synchronous serial port, 64 input/ output digital pins, interrupt system with 16 sources, six of them being external and an advanced power management block.

The LM75A temperature sensor offers the information in digital form through an I2C interface. It can measure the temperature from – 550C to + 1250C. The analog – digital conversion is done on 11 bits offering a 0.1250C resolution. Programmable inferior and superior temperature limits exist which are memorized in special registers.

The sensor has two working modes: normal and shut-down which can be set by one bit in its configuration register. In the normal mode a conversion is done every 100 ms. In the shut-down mode the consume dramatically drops (to 3.5 μA), conversions are not done and the temperature register contains

SACI 2007 – 4th International Symposium on Applied Computational Intelligence and Informatics

106

the result of the last conversion before installing the shut-down mode. The sensor can generate interrupt request if the temperature increases over the superior limit or drops under the inferior limit.

The LM75A sensor is connected to the microcontroller through the I2C interface. The I2C bus permits to connect several sensors to the same microcontroller creating a smart multiple sensor.

Fig. 2. Block diagram of the TINI platform

B. The software implementation The software of the TINI module is made by: APIs, native

cod directly executed by the microcontroller and the TINIOS. The application code is written in Java and uses APIs for exploiting the facilities of the native code and the hardware resources. It is also possible to develop libraries in native code which can be loaded from an application for covering hard real time requirements. The API part combines classes from libraries defined in the Sun JDK development kit with own TINI classes which use the facilities of the system. The TINIOS is responsible with the management of all the system resources including the memory access, the tasks execution schedule and with the interaction with the hardware components. It consists in three subsystems: the scheduler for the processes and the tasks, the memory management and the I/O operations management.

The application is executed as follows: first the web server implemented on TINI is started. Than the user introduces in the web browser the IP address of the TINI server and generates a GET type HTTP request. The server sends to the browser the index.html file and the .jar archive which contains the applet classes. The browser runs the applet and this one sends a request for initialization data. The server sends the initialization data to the applet and starts executing temperature reads. The server sends the data to the applet, at certain time intervals, and the applet displays them graphically.

If alarm events occur the server will inform the applet for displaying them. The alarm feature will permit to intervene over the environment for correcting these situations (for instance for stopping the heat generators, for starting the fans etc.).

The applet has graphical elements through which commands can be sent to the sensor such as: temperature conversions starting or stopping, application ending, sample rate, setting of the alarm levels, display of the temperature in Celsius or Fahrenheit degrees and so on.

The Java classes which compose the application software are divided in two groups: - classes running on the TINI platform and - classes from the applet, running in the web browser.

The classes running on the TINI platform are: - TempServer.class – implements a web server based on the class com.dalsemi.tininet.http.HTTPServer; - TempSensor.class – communicates, at hardware level, through the I2C bus with the LM75A sensor; - AlarmMonitor.class – continuously monitors if the current temperature is situated between the low and high alarm levels and announces ApplelUpdater if at least one of the levels is outrun; - SampleRecorder.class – it manages the temperature samples gathered by the TempServer object; - AppletListener.class – waits for connection requests from the client applet; - AppletUpdater.class – sends data to the applet, sucs as: initializations, current temperature and alarm levels; - CommandExecuter.class – it executes the requests of the client applet.

The classes which constitute the client applet are: - TempApplet.class – it defines the graphical interface of the applet and coordinates the other classes; - TempGraph.class – achieves the display of the temperature in a 2D graphical form; - ServerUpdate.class – it communicates with the AppletListener for asking initialization data or for asking the modification of the sensor’s functioning parameters; - ServerListener.class – receives the data sent by the AppletUpdate; - Sample.class – class which encapsulates a temperature sample.

Next, the diagrams showing how the application proceeds are presented.

The first step is to initialize the applet, fig. 3. The notations have the following significations: - START: the AppletListener, TempSensor and AlarmMonitor threads are started; - STS: TempServer is started; - WAIT: the applet waits connection request from the browser; - SEND: the applet sends the index.html page and the .JAR archive to the browser.

The next step consists in sending the initialization data for the 2D graphic to the applet from the browser, fig. 4.

The significations of the notations are: - SAL: AppletListener is started;

M. Popa, A. S. Popa. C. Patitoiu • A Web Connected Smart Sensor

107

- WAIT: waits a socket connection from the browser; - SEND: sends the data requested by the applet; - INITREQ: the applet sends a data initialization request to the TINI server; - INITREC: the applet receives the data initialization for the 2D graphic.

Fig. 3. The initialization of the applet

Fig. 4. The sending of the initialization data for the 2D graphic

A cyclical task of the TINI is to send a temperature sample to the applet, fig. 5.

Fig. 5. The sending of a temperature sample to the applet

The notations mean as follows:

- STSEN: TempSensor is started; - TEMP: the LM75A sensor detects the current temperature; - SENDTT: the sample (temperature + time) is sent to the applet; - RECS: the applet receives the sample and displays it in the 2D form.

When alarm events occur the applet is announced, fig. 6.

Fig. 6. The sending of an alarm message to the applet

The notations mean as follows: - SAM: AlarmMonitor is started; - VERIFY: verifies if alarm events occurred; - SENDAL: sends alarm message to the applet; - RECAL: the applet receives the alarm message and generates the corresponding graphical signals.

The last diagram shows how are actualized the functioning parameters of the sensor, fig. 7.

Fig. 7. The actualization of the functioning parameters of the sensor

The notations mean as follows: - TINIREC: TINI receives the functioning parameters and is configuring itself as a consequence; - SUS: ServerUpdate is started; - READP: reads the functioning parameters specified by the user; - SENDP: sends the functioning parameters to TINI.

Next, a detailed description of the classes running on the TINI platform follows.

SACI 2007 – 4th International Symposium on Applied Computational Intelligence and Informatics

108

TempServer.class Its main function is to implement a web server on the TINI

platform. This functionality is based on the class com.dalsemi.tininet.http.HTTPServer which offers the necessary software support for implementing a web server on the TINI platform. This class ensures: the configuration of the HTTP class, the configuration of the HTTP directory which contains the index.html page and the .jar archive which will be sent to the client applet, the configuration of the implicit HTML page (index.html) and the service of the HTTP requests through the function serviceRequest().

TempSensor.class This class implements the communication from the hardware

level with the LM75A sensor through the I2C bus. An object belonging to the class com.dalsemi.system.I2CPort is created and used for configuring the slave address of the temperature sensor and the clock delay from the I2C bus.

This class starts the AlarmMonitor thread and configures, at hardware level, the alarm registers of the LM75A.

In the run() method of this class temperature samples are taken at specified moments through the visual interface of the applet. Each temperature sample is sent, together with the corresponding time moment, to the SampleRecorder object for being memorized.

The method used for getting a sample and sending it to the sample recorder object is:

/** *A sample consist of the measured temperature + the time *(in ms) the sample was taken */ public void takeSample() { System.out.println(“TempSensor takeSample()”); //Get the temperature double temperature; synchronized (lock) { temperature = getTemperature(); } System.out.println(temperature); //Get the time Long time = System.currentTimeMillis(); /**

*Change temperature to integer, keeping one decimal *accuracy by multiplying by 10 *Strip decimal information by converting double to *integer */ temperature *= 10; //Add the sample to the recorder sampleRecorder.recordSample((int)temperature, time);

}AlarmMonitor.class This class is implemented as a thread which permanently

monitors if the current temperature outruns the superior or inferior alarm levels. If so, the AppletUpdater object is announced which, at its turn, will announce the applet for displaying this critical situation. Two types of alarms are

generated: up alarm and low alarm. AlarmMonitor also announces AppletUpdater the normal situation in order to actualize the graphical interface (stopping the alarm signals).

This thread is created, started and stopped by the TempSensor object. It collaborates with SampleRecorder, for reading the current temperature and with the AppletUpdater (as it was mentioned).

SampleRecorder.class Its main function is to manage the temperature samples taken

by the TempServer object and the sampling parameters which can be modified through the graphical interface of the applet.

A sample memorized by the SampleRecorder object is composed by two elements: the temperature read from the LM75A sensor and the time moment corresponding to this reading. Examples of the sampling parameters are: the on/off state of the sampling, the sampling rate, the superior and inferior alarm level and the type of degrees used: Celsius or Fahrenheit.

The samples are memorized in a nonvolatile SRAM memory. SampleRecorder receives samples from TempSensor for memorizing them. After that the sample is sent to AppletUpdater which will send it to the applet for displaying it. When the user decides to end the session, through the graphical used interface, SampleRecorder has to save the parameters and to close the file in normal conditions.

AppletListener.class This class permanently “listens” for accepting connection

requests from the applet. This is done by using an object, SeverSocket, which will monitor a specified port for detecting connection requests from the applet. If such a request occurs a Socket object will service this connection. It will read the data sent by the applet through the InputStream associated with this connection. First, the data will be verified and than will be sent to the CommandExecuter for being processed and executed.

AppletUpdater.class It sends data from the server to the applet. These data can be:

initialization data, current temperature and alarm temperatures. The initialization data are sent on the following way: applet – AppletListener – CommandExecuter – AppletUpdater. When AppletUpdater receives this command it will ask data from SampleRecorder. After receiving them, it will send them to the applet.

The current temperature and the corresponding time moment will be sent on the following way: TempSensor – SampleRecorder – AppletUpdater.

AppletUpdater receives temperature alarms from AlarmMonitor and sends them to the applet.

CommandExecuter.class It receives messages from AppletListener, interprets and

verifies them and asks the other components of the system to execute the commands from the messages. Examples of commands are: - the modification of the sampling parameters (sampling rates, alarm levels, sampling start/stop etc.); these commands are executed by the SampleRecorder and TempSensor objects; - stop of the application: this command is sent to TempSensor, SampleRecorder and AppletListener.

The description of the classes which make up the applet follows.

M. Popa, A. S. Popa. C. Patitoiu • A Web Connected Smart Sensor

109

TempApplet.class It is the main class of the applet and has two essential

responsibilities: the achievement of the graphical interface of the applet and the coordination of the other classes. It defines the graphical elements which compose the interface and implements the servicing routines for the events associated with the user. It coordinates the ServerListener and ServerUpdater classes for communicating with the TINI server.

TempGraph.class It achieves the 2D graphical presentation. The 0Y axes show

the temperature and the 0X axes shows the associated time moment.

ServerUpdater.class It sends data to the server from the TINI platform. More

exactly it directly communicates with AppletListener. The communication with TINI is done by initialization data

requests and requests for modifying the functioning parameters of the temperature sensor.

After entering in the init() method TempApplet will ask from ServerUpdater to ask, at its turn, the initialization data from the TINI server. These data will be received by ServerListener.

As it was mentioned SeverUpdater is a thread and its run() method consists in a loop used for reading the functioning parameters from TempGraph and for sending these parameters to TINI. The leaving from this loop, and from the run() method too, is done when the user asks it through the graphical interface.

ServerListener.class It continuously listens for detecting connection requests

arrived from TINI. For that, the classes ServerSocket and Socket from the java.net library and the class InputStream from the java.io library are used.

When the data arrives from the TINI server, SeverListener will verify the correctness of the message and if the operation is successful it will interpret the message. The message can be made by: initialization data, the current sample used by TempGraph for displaying the last temperature read by the sensor or temperature alarm. For each of these types SeverListener will call appropriate methods from TempGraph. The ending of this thread is done at the ending of the whole application, this moment being decided by the user by pressing a button from the graphical interface.

Sample.class It encapsulates a sample composed by the temperature and

the associated time moment. It is used by TempGraph for displaying the 2D graphic.

The code of this class is presented below: /**

* Class used to represent a sample (temperature + time) */ public class Sample { public double temp; public long time; }

V. CONCLUSIONS The implementation of an Internet connected smart sensor

was described in this paper. It was based on the TINI platform and was targeted to measure temperatures. The main offered features are: - the data obtained from the sensor are displayed in a 2D graphic form allowing to analyze the evolution in time of the temperature; - the temperatures read are memorized in a nonvolatile SRAM memory keeping them for later analyzes; - a real time clock was used for associating time parameter to each temperature; - the control of the parameters of the sensor: alarm levels, sample rates and their temporary save between work sessions.

Future development directions are: - multithreading support; - securization of the access to the data from the sensor; - deeper control for the parameters of the sensor; - add of other sensor types.

REFERENCES

[1] http://resource.controleng.com/article/CA6296119.html[2] S. Yurish and M. Gomez (eds.), “Proceedings of the NATO Advanced

Study Insititute on Smart Sensors and MEMS”, NATO Science Series II: Mathematics, Physics and Chemistry, vol. 181, 2004

[3] J. Wiczer and K.B. Lee, “A Unifying Standard for Interfacing Transducers to Networks – IEEE-1451.0”, in Proc. of the IEEE International Workshop on Intelligent Data Acquisition and Advanced Computing Systems: Technology & Applications, Lviv, Ukraine, September 2005

[4] R.M. Kling, “Intel Mote: An Enhanced Sensor network Node”, in Proc. of the International Workshop on Advanced Sensors, Structural Health Monitoring and Smart Structures, Keio University, Japan, 2003

[5] Crossbow Technology Inc. “MICA2DOT Wireless Microsensor Mote”, 2005 – http://xbov.com/Products/Product_pdf_files/Wireless_pdf/MICA2DOT_Datasheet.pdf

[6] Crossbow Technology Inc. “MICAz Wireless Measurement System”, 2005 –http://xbov.com/Products/Product_pdf_files/Wireless_pdf/MICAz_Datasheet.pdf

[7] Q. Ashan, R.I. Grosvenor and P.W. Preickett, “Distributed On-Line System for Process Plant Monitoring”, in Proc. of Mechanical Engineers, Part E: Journal of Process Mechanical Engineering, Volume 220, Number 2/ 2006

[8] L. Thomsen and D. Husemann, “Evaluating the Use of Motes and TINYOS for a Mobile Sensor Platform”, in Proc. of the 24th IASTED Multi-Conference PARALLEL AND DISTRIBUTED COMPUTING AND NETWORKS, Innsbruck, Austria, February 2006

[9] J. Campbell, P.G. Gibbons, S. Nath, P. Pillai, S. Seshan, R. Sukthankar, “IrisNet: An InternetScale Architecture for Multimedia Sensors”, in Proc. of The 13th Annual ACM International Conference on Multimedia (MM 2005), Singapore, November 2005

[10] K. Piotriwski, P. Langendoerfer and S. Peter, “How public key cryptography influences wireless sensor node lifetime”, in Proc. of the Fourth ACM workshop onsSecurity of ad hoc and sensor networks, Alexandria,Virginia, USA, 2006

[11] http://www.maxim-ic.com/products/microcontrollers/tini/

SACI 2007 – 4th International Symposium on Applied Computational Intelligence and Informatics

110