embedded system for a wireless automatic meter ...

IADIS International Conference Applied Computing 2007

EMBEDDED SYSTEM FOR A WIRELESS AUTOMATIC METER READING MANAGEMENT Gonzalo Álvarez, Hodei Cepeda, Igor Laniella, Nagore Benítez, Carlos Amuchástegui Computer Architecture and Technology Department University of the Basque Country P.M. Lardizabal 1, E-20018 Donostia-Spain

Nestor Ayuso R&D Department Kifer Computer Science Services Antxota Kalea 1, E-20160 Lasarte-Spain

ABSTRACT This article presents a remote Automatic Meter Reading (AMR) system as a result of the Mirakonta project, in which are involved several university investigation groups and a private company. The AMR system is composed by reader devices and a group of elements which allow a wireless connection to a central server. The system is based on taking a picture with a Reader of the fluid meter digit display, preprocessing and transmitting it using a Radio Frequency ad-hoc protocol to a remote element named Master directly connected to a Concentrator. The Concentrator is implemented on a board running uClinux and manages all the fluid meter readers it is in charge of from a certain geographical zone. Reader parameters and firmware, Concentrator data and OS can be configured or updated remotely. All the requirements of the system have been covered, offering a hardware-software product that covers most of the needs of the end users. KEYWORDS Linux Embedded System, Wireless communication

1. INTRODUCTION The Mirakonta project is born from the need to have at our disposal a low-cost automatic system to allow remote meter reading from digit display meters. From the work developed by a group of investigation of three universities and a company, several products and a spin off company are born. One of the developed products consists of the meter reader reading system based on digital processing of the image and radio frequency transmission. This system fulfils the premises of low cost, low consumption and the necessity of a universal solution. The mentioned system is in patent process [1] and further information about the product can be found in the article “Low power AMR system based on FPGA”[2]. The initial system structure was formed by Readers and Masters. Each Reader device is located on a fluid meter. Their function is to take pictures of the fluid meters, pre-process and transmit it to a remote Master module via wireless RF ad-hoc communication system. The function of the Master module is to serve like a mobile element that allows communication between the Readers and any device capable of RS-232 or SPI communication such as a laptop or a PDA. To the initial system, an embedded computer was added. This embedded system, named Concentrator, centralizes the readings of a certain geographical zone. The function of this module is to take the captured data from the Readers in its operational range and to transmit the data to a central server. It is possible to connect the Concentrator directly to a Master module with the ad-hoc wireless connection.

777

ISBN: 978-972-8924-30-0 © 2007 IADIS

Master Reader

Repeater Concentrator

Server

Ad-hoc link Standart link

Figure 1. System Structure

Also, Repeater modules can be used to provide the system with a greater operational range of the wireless communication. A complete view of the system is showed in the figure 1. The Concentrator can communicate with the Readers through a RF module named Master, the retrieved information is saved in a non volatile memory. The communication with the data server is made through Ethernet, GPRS, Wi-fi , Bluetooth, etc. giving high flexibility to the system.

2. THE CONCENTRATOR As mentioned, the main function of this module is to centralize the readings from the surrounding reading devices; this is, to take the captured data from the readers in its operational range via wireless ad-hoc communication and to transmit the data to a central server. The Concentrator also offers a wide range of operations to manage the readers and the Concentrator itself. In addition, an alarm can be set up with the desired date and period so that all the reading is done automatically. This alarm, once activated, is responsible for reading any of the associated fluid meters. The main functionality of the system is: • To listen for operations from the server directed either to the Readers or to the Concentrator itself. • To manage an alarm for updating the readings from all the Reader devices. The model is based on the use of tasks for the manager modules. Following, an explanation of each module is shown: System Monitor: Responsible for the application startup and correct operation of both the operative system and the application. This module makes periodic checks on the different tasks to verify their state. If they don’t seem to respond for a stated period of time the watchdog reboots the system. It also checks that the interface with the Internet is up. Operation Manager: Incoming operations from the server are attended through communication channels by this manager. It remains idle waiting for a server petition. Once an operation is detected, another task is created for the process of such using both APIs: Concentrator and Reader APIs. Automated Reading Manager: The system alarm to download all the readings from the Readers is managed in this module. The periodicity of the alarm can be set via server petition. When the desired date is reached all the Readers the Concentrator is in charge of are requested for image download. Master Communication Manager: The module in charge of the management of the application protocol with the Readers using the Master device through a RS-232 bus. It implements an ad-hoc communication protocol according with the retransmission policy of “Stop and Wait” and following a Master-Slave model. Reader API: This library contains the procedures for processing the different types of operations applicable to the Readers or concerning them such as: request a reading, the Reader version, the date, set the configuration, etc.

778

IADIS International Conference Applied Computing 2007

Concentrator API: This one indeed, holds the functions for the management of the Concentrator. Some possible operations can be: set/read the alarm, set/read the date, set/read the Reader list, download all the readings, etc. The development for embedded environments concerns several facts to be taken into account: • Programming jeopardizes with the memory use due to a lack of RAM memory and a small stack size. • No use of dynamic memory has been made. This is due to the inefficient management of the heap memory in some non-MMU architectures, causing internal fragmentation. Other facts having to do with the design of the application are: • Periodic checks to the main tasks of the Concentrator. This is done by setting some flags to a certain value and resetting the system (via watchdog) if they don’t change for a stated period of time. • Race conditions need to be taken care of due to concurrent execution of tasks. This is solved by using locks and mutexes. • There is a need to have at our disposal a library or system interface that provides multitask management and synchronization. The development of the application has been done in C/C++ for Linux embedded OS.

3. PROTOTYPING PLATFORM The Concentrator has been designed to run in an embedded platform. So an operating system capable of running a wide range of embedded devices such as ARM, ColdFire, x86 microcontrollers should be selected. At this point the results of the process of selection of the operating system for development and test purposes are shown. To cover all the functionality explained in chapter 2, we need an embedded system that offers the next different features: - Multitasking support: It is necessary a concurrent system to control several concurrent task. - System communication with the Central Server through a network (wireless or wired). - To be able of saving critical data in a Non Volatile Memory (NVM). - Possibility to access hardware resources: such as ad-hoc devices, built-in components like watchdog. - Possibility to upgrade remotely the operating system and the main application. We selected Linux for embedded systems to fulfill those requirements. Linux for embedded systems is an open source OS that offers thread support (Posix Native Thread Library), access to network through TCP/IP Stack, PPP protocol support to connect via GPRS among others. It also offers file system support for non volatile memory and includes several server/client applications. A wide variety of microcontrollers can be used as long as they are supported by the operative system. The minimum estimated speed of the microcontroller to run the system (OS, servers, Concentrator application, etc.) has been settled down in 50 MIPS. The minimum RAM memory size needed for the Concentrator application code and data files, leaving the OS one side, is 2MB. Non-volatile data (OS Image and the Concentrator database) needs to be stored. The minimum size considered for just the application and its database is 3 MB. Main communication devices need serial RS-232 port: Master device, GPRS, system console. For network access other link types are required such as Ethernet or Wi-Fi. Other type of hardware required for the system to work properly and to prevent hung ups is the watchdog. The watchdog is essential to detect any kind of anomaly that can occur during the execution of the OS and mainly of the application. GPIO pins are also needed so that devices such as Master device, communication modules and others can be switched off in order to save power. To test the system two Freescale Coldfire boards were employed, the M5282EVB and M5208EVB; Figure 2. The system was tested with an ad-hoc Master, a Wavecom GPRS module and a SparkLan Wi-Fi Ethernet bridge. Low power techniques are used to reduce the initial power consumption down to 650 mW. These are mainly based on switching off resources that are not being used and switching devices to standby states. We estimate that implementing Standby and Sleep power modes the consumption can be decreased down to 250 and 100 mW respectively.

779

ISBN: 978-972-8924-30-0 © 2007 IADIS

Figure 2. Test platform

4. CONCLUSION The introduced system allows reducing costs on fluid meter reading and can be used to easily centralize the managing of any system of meters, or sensors along a wide range even in a place without communication infrastructures. The employment of an embedded system based on Linux operative system has facilitated the tasks of designing and implementation of the whole application. The inclusion of external network access provides the ability to remote management and upgrade of the main application and the operative system. Also, the use of this type of open platforms allowed the development and inclusion of ad-hoc drivers into the system and the employment of low power techniques.

ACKNOWLEDGEMENT We wish to express our gratitude to everyone who contributes to the development of this project. We must single out the support of the Spanish government (Ministerio de Industria, Turismo y Comercio) with the projects (FIT-70000-2003-968, FIT-330100-2005-181, FIT-330100-2006-64). We also want to thank the collaboration of Dr. Jordi Carrabina of the Universidad Autónoma de Barcelona and Dr. Lluis Terés of the Centro Nacional de Microelectrónica.

REFERENCES A. Guerendiain, G. Alvarez, C. Amuchastegui, 2005. Método y sistema universal y reconfigurable de lectura remota de contadores o equipos provistos de indicadores visuales. ES. Patent P200500991, PCT/ES Patent 2006/000201, April 2005. Nagore Benitez, Gonzalo Bellanco, Carlos Amuchastegui, Gonzalo Alvarez, Igor Laniella, Hodei Cepeda, Nestor Ayuso, Alfonso Guerendiain, 2007. Low power AMR system based on FPGA. Sent to Southern Conference on Programable Logic 2007. Embedded Linux/Microcontroller Project http://www.uclinux.org/ Srivatsa Vaddagiri, 2004. Power Management in Lnux-Based Systems. Linux Journal.

780