Aqua-OS: An Operating System for Underwater Acoustic Networks Haining Mo, Son Le, Zheng Peng, Zhijie Shi, and Jun-Hong Cui Department of Computer Science and Engineering, University of Connecticut, Storrs, CT, USA, 06269 {haining.mo,sonle,zhengpeng,zshi,jcui}@engr.uconn.edu Abstract. Underwater acoustic networks have recently emerged as a promising approach for oceanic applications such as exploration and surveillance. This new type of networks differs from terrestrial wireless sensor networks in that the network nodes are powerful and well equipped with many resources for diverse applications in challenging environments. Existing operating systems for terrestrial wireless sensor networks may not be able to fully utilize the resources available in underwater networks or work efficiently in the underwater environment with diverse application requirements. This calls for a new operating system design for underwater acoustic networks. Motivated by this, we propose a plan to implement an operating system for underwater acoustic networks: Aqua- OS. Aqua-OS is going to be robust, highly customizable and energy efficient to tackle the harsh underwater environment, fully utilize the hardware resources and meet the diverse application requirements. Keywords: Underwater networks, Operating systems. 1 Introduction As a water planet, the vast yet unexplored water resources on the earth have fascinated human being for thousands of years. In recent years, there has been a rapidly growing interest in monitoring and exploring the aqueous environments. Underwater acoustic networks (UANs), as an emerging technology, have attracted more and more researchers and become a promising solution for a large amount of applications in the underwater environment. UANs can be employed to monitor the underwater environment, which is crucial for preventing pollution and detecting climate change. It provides a method to allow network nodes, gateways and surface buoys to communicate with each other and therefore makes the data transmission more efficient and effective. Other applications of UANs include undersea exploration and tactical surveillance like detecting and classifying submarine, underwater vehicles and divers. Compared with the traditional technologies, UANs are more flexible, real-time, low cost and accurate. UAN is a completely new type of network with unique characteristics. First, the harsh underwater environment makes communications in UANs very challenging. Since acoustic channel instead of radio is employed as the medium for signal transmission in the water, the data propagation delay is extremely long for UANs due X. Wang et al. (Eds.): WASA 2012, LNCS 7405, pp. 561 573, 2012. Springer-Verlag Berlin Heidelberg 2012
562 H. Mo et al. to the low propagation speed of the acoustic signals (1500m/s). The absorption, multipath and fading of the acoustic channels lead to a very limited bandwidth in UANs. Also the UAN nodes are highly dynamic due to the current and fish movement leading to unstable communication links and intermittent connectivity. All these factors make UAN communications very difficult. Second, different from terrestrial wireless sensor network nodes, UAN nodes are much more powerful in terms of processing and computation capability and equipped with more resources and devices. But meanwhile, UAN nodes still have limited power supply and therefore low power design is always a concern for UANs. Third, UAN applications are highly diverse and may involve a lot of advanced algorithms imposing intensive computation and high energy consumption. As a result, fundamental changes have to be made and significant efforts need to be put into every layer of the UANs, including the hardware, the operating system, the protocols and the application software. Among these layers, the operating system is indispensable and of critical importance for UANs. It serves as the interface between the hardware and the software and bridges the specific underwater applications with the physical system of the UAN nodes. It is also responsible for the management of shared resources including processor time and memory as well as for the coordination and scheduling of multiple tasks. Despite its importance, there has been little work on the operating systems for UANs. In fact, the aforementioned characteristics call for a shift in the design philosophy for the operating systems of UANs. An OS for UANs needs to work reliably to survive the challenging underwater environments. It also has to fully utilize the resources in UAN nodes and meanwhile achieve energy efficiency to save the limited power. Moreover, a UAN OS needs to fit the computation intensive nature and the diverse requirements of the UAN applications. In this paper, we are going to investigate the operating systems for UANs and propose a plan to design and implement a dedicated operating system for UANs: Aqua-OS. Aqua-OS is different from other operating systems in three aspects. It is going to take robustness as the top priority given the harsh underwater environment which makes both the hardware and software prone to failures. Aqua-OS is also going to be highly customizable to meet the diverse requirements in UAN applications. An OS Components Toolbox and an optimizer are going to be provided to tailor Aqua- OS in a way optimally fitting the specific application requirements and user preferences. Further, Aqua-OS will take energy efficiency into account since power consumption is always a big issue in UANs where all the devices are usually equipped with limited power supplies. The rest of the paper is organized as follows. In Section II, we study some related works. In Section III, we discuss the motivation and goal of Aqua-OS. A detailed description on the features Aqua-OS is going to provide is presented in Section IV and we conclude the paper in Section V. 2 Related Works Operating System has always been a subject attracting tremendous attention from researchers. For OSes running on servers, desktops and laptops, Windows and Linux have been in the dominant position for a long time. With the development of the microcontrollers and micro-processors, OSes for embedded systems including Embedded
Aqua-OS: An Operating System for Underwater Acoustic Networks 563 Linux, Windows CE and µc/os-ii have emerged as a big success over the last several decades. For Terrestrial Wireless Sensor Networks (TWSNs), it has become a hot research topic and a couple of OSes have been implemented to serve the TWSN nodes. MANTIS OS is an embedded multithread operating system for wireless sensor platforms. MANTIS achieves a very small RAM footprint, which is less than 500 bytes. It also allows users to reprogram the entire operating system, a single thread or a set of variants within a thread on the fly. Besides, it reduces the power consumption of the system by switching to sleep mode when all the active threads have called the sleep function. MANTIS is designed for the TWSNs. It does not take into consideration the special characteristics of the underwater environment and the diverse requirements of the underwater applications and therefore cannot be directly applied to UANs. TinyOS is specifically designed for TWSNs, which is characterized by limited resources, low power supply and event-centric applications. It employs an eventdriven scheduling mechanism. TinyOS also allows users to build applications from a large number of very fine-grained components. It takes into account the low power design by allowing a subsystem to go to an idle state. However, TinyOS is designed for sensor nodes with quite limited processing capability and resources and therefore does not fit the UAN nodes. In addition, the event-driven scheduling method of TinyOS is not suitable for underwater applications. ecos, which is an embedded operating system, provides a configuration system for application software to allow more customizability and configurability. This configuration system provides application programmers with a way to impose their functionality and implementation requirements on the run-time components of ecos. In another word, ecos allows the application programmers to tailor the operating system to fit their specific requirements and preferences. This configuration system also allows developers to extend the functionality of ecos by adding new run-time components. Considering the very diverse application requirements in UANs, the configuration system in ecos could be adopted by the UAN OSes to enhance their flexibility and configurability. There exist other embedded operating systems. Contiki is an OS for networked embedded systems or wireless sensor networks. It supports IP communication, both IPV4 and IPV6, by providing its own uip stack. It also provides a software-based power profiling scheme to track the power consumption of each sensor node. µc/os- II is an embedded OS which provides a preemptive real-time multitask kernel for micro-processors. It achieves a very small memory footprint and supports all types of micro-processors from 8 bit to 64 bit. However, none of these OSes is designed for applications in UANs. To better serve the applications in UANs, a dedicated operating system which takes into consideration the special characteristics of the UAN applications is highly desired. 3 Motivation and Goal 3.1 Examining Existing Operating Systems There have been a lot of researches on operating systems for servers, desktop computers, laptops and embedded systems. Since a UAN node is typically considered as an embedded system, we focus on investigating the embedded operating systems.
564 H. Mo et al. Generally speaking, there are two types of embedded operating systems. Some operating systems are tailored for low-end micro-controllers or micro-processors. They usually have limited capability for multi-task scheduling and coordination. Instead of providing dynamic memory allocation, these operating systems usually only support static memory management. One example falling into this category is TinyOS. TinyOS is dedicated for TWSN nodes which are equipped with microcontrollers with quite limited processing power. To fit the limited processing capability and power supply of the sensor network nodes, TinyOS employs a nonpreemptive event-driven scheduling method as well as a static memory management scheme. Other operating systems like embedded Linux are targeted for powerful micro-processors. These operating systems can support some advanced features including multi-task scheduling and virtual memory management. An example is the Autonomous Underwater Vehicles (AUVs) which are usually equipped with very powerful multi-task processors. Therefore embedded Linux or even Windows can be installed on AUVs to fulfill multiple tasks. Due to the special characteristics of the UANs, both of these two types of operating systems are not suitable for underwater applications, as will be discussed in details below. 3.2 Why Not TinyOS The operating systems for low-end processors are not suitable for UANs which provide much more powerful hardware resources. Also different from TWSNs, applications in UANs are more diverse and complicated ranging from data acquisition to data processing and compression. Some applications may even involve complex algorithms which are both time and energy consuming. In this context, low-end hardware platforms and OSes like TinyOS are not good fits for UANs due to the lack of strong computation capability and the energy inefficiency. To validate this conclusion, we tested the performance of UAN applications running on low-end hardware platforms and OSes as well as on more powerful hardware platforms and the corresponding OSes. Given the computation intensive nature of the UAN applications, we employ Fast Fourier Transform (FFT) as the representative for UAN applications due to its computation complexity. T-Mote and TinyOS are employed to represent the low-end hardware platforms and OSes due to their popularity in TWSNs. Gumstix, which is a powerful embedded processor and a promising candidate to work as the controller for UAN nodes, as well as the embedded Linux are selected as the representative for more powerful hardware platforms and OSes. Both the execution time and the energy consumption of FFT running on these two platforms are compared with varying numbers of points in FFT. The result of the execution time is shown in Fig. 1 and that of the energy consumption is shown in Fig. 2. We can see that the combination of Gumstix and embedded Linux achieves a much smaller execution time and energy consumption than that of T-Mote and TinyOS. Also as the number of points in FFT increases, the execution time and energy consumption of T-Mote and TinyOS grow much faster. This preliminary investigation proves that OSes for low-end hardware platforms like TinyOS are not good candidates for UAN applications.
Aqua-OS: An Operating System for Underwater Acoustic Networks 565 Fig. 1. Execution Time of FFT on T-Mote and Gumstix Fig. 2. Energy Consumption of FFT on T-Mote and Gumstix 3.3 Why Not Embedded Linux In the above section, we prove that embedded Linux outperforms TinyOS in terms of both execution time and energy consumption when running computation intensive UAN applications. In this section, we study whether embedded Linux can be directly applied to UANs. Embedded Linux is a multi-task operating system usually employing time-sharing schemes to schedule multiple tasks. There are also some variants of embedded Linux like RTLinux which uses preemptive scheduling mechanism to guarantee the real-time performance of embedded systems. Embedded
566 H. Mo et al. Linux also provides dynamic memory allocation and virtual memory management. Besides, embedded Linux supports POSIX interface and implements drivers for a wide range of peripheral devices. All these features make embedded Linux an ideal choice for embedded systems. However, embedded Linux may not be directly applied to the UAN nodes due to the following reasons. First, embedded Linux is not tailored for UANs. A UAN node is usually equipped with an acoustic modem for underwater communication, a set of sensors for monitoring and data collection as well as other dedicated devices for specific tasks. To reliably and effectively manage these hardware components imposes great challenges for embedded Linux. Both the drivers and the Hardware Abstraction Layer may need to be modified. On the other hand, a UAN node is required to complete a set of tasks including sensing as well se data collection, processing, storage, sending and receiving. An effective scheduling and coordination mechanism needs to be in place to make sure these tasks can be completed efficiently. Second, embedded Linux is not robust enough for UAN nodes. Due to the harsh underwater environment, the hardware and software of a UAN node are both prone to failures. Embedded Linux is not capable of handling these failures. Besides, embedded Linux can be easily undermined by skills such as fork bomb, which means a malicious user can create tons of threads to paralyze the operating system. So far there is no system level fix for this kind of attacks in embedded Linux. Third, embedded Linux is not totally customizable. UAN applications impose very diverse requirements. Some simple underwater applications only require event-driven task scheduling and static memory management while some complicated ones call for a preemptive task scheduler and a dynamic memory management scheme. Currently, embedded Linux is not customizable or configurable to satisfy these different application requirements and user preferences. How to pick up the optimal combination of OS components to fit the diverse needs is a question that embedded Linux cannot answer right now. Finally, embedded Linux does not have a dynamic power management to save the limited energy of the UAN nodes, which are usually deployed underwater for a long period without energy harvesting. Therefore a systematic way to improve energy efficiency should be provided. 3.4 Goal of Aqua-OS Motivated by the disadvantages of the current existing operating systems when being applied to UANs, we propose a plan to design and implement a new operating system dedicated for UANs: Aqua-OS. Aqua-OS is going to realize the following features to fit the applications in the UANs. First, Aqua-OS is going to provide robustness to underwater applications. Based on the aforementioned underwater environment characteristics, we take the robustness as the highest priority. To handle the hardware and software failures as well as the malicious user attacks, Aqua-OS will provide a system status updating component that runs periodically and an emergency handling component that can be activated regardless of current system status, e.g. CPU usage, disk space or task property. This
Aqua-OS: An Operating System for Underwater Acoustic Networks 567 emergency handling component will handle the exceptions caused by either failures or attacks and reset the affected hardware or software components if needed. Second, Aqua-OS is going to be customizable and reconfigurable. Applications in UANs pose very diverse demands. In order to meet these demands, Aqua-OS is going to be highly customizable before deployment and highly reconfigurable after deployment. In another word, a system designer can pick different components e.g. a specific scheduling method, a memory management scheme, a set of drivers and a tailored protocol stack from a component warehouse of Aqua-OS to generate a dedicated operating system specifically fitting his or her application requirements. Even after the deployment of the network node, the system designer can still dynamically load and unload components in Aqua-OS on the fly. To achieve this goal, Aqua-OS provides an OS Components Toolbox which serves as the component warehouse. An OS optimizer is in place to take the application requirements and user preferences as inputs and pick up the optimal combination of components from the OS Components Toolbox. In addition, Aqua-OS will take into consideration the energy efficiency of the UANs, which means it will provide a dynamic power management system to save energy. Aqua-OS will also smartly balance the performance and energy consumption of the system to maximize the usability of the system under various constrains. Finally, Aqua-OS is going to provide some features users usually desire from an embedded OS. These include a fast boot-up time and a small memory footprint. Aqua-OS will also try to reduce the OS overhead including the task context switch time and the memory usage. 4 Aqua-OS In this section, we propose the plan to design and implement Aqua-OS and describe the two key features in Aqua-OS: the OS Components Toolbox and the optimizer. 4.1 Aqua-OS Overview Aqua-OS is composed of two major modules: the OS Components Toolbox (OCT) and the optimizer. The OCT consists of a set of essential system components for the OS from which the OS users can select their needed components based on the application requirements and their preferences. For instance, OCT provides both event-driven based scheduler and preemptive scheduler and users can choose either one based on the specific application scenario. The preemptive scheduler provides better processor utilization while the event-based scheduler generally uses less energy. Another example is the scheme for failure detection and recovery. There can be many options for this purpose from the OCT, and they are different in their performances: a more sophisticated method enhances the reliability of the UAN system but will most probably use more resources and energy while a simple scheme only provides limited reliability but consumes less resources and energy. Therefore, an appropriate failure detection and recovery scheme needs to be chosen based on a
568 H. Mo et al. specific UAN application. Sometimes, even the choice of the file systems determines the system performance. For example, the FAT16/32 is simple and suitable for application operating on a small set of data while NTFS or ext2/3 allows application with larger data. The best combination of the components is picked from the OCT by the Aqua-OS optimizer. This module takes application requirements and user preferences as the inputs and then selects the set of components from the OCT that best matches the inputs to generate the customized Aqua-OS. 4.2 OS Components Toolbox OCT provides a set of components for task scheduling, memory management, power management as well as failure detection and recovery. Therefore the optimizer of Aqua-OS can choose the optimal combination of the system components from OCT based on the application requirements and user preferences. 4.3 Task Management and Process Scheduling Depending on how tasks are managed, OSes can be classified into two categories: event-based and thread-based. In event-based operating systems, non-preemptive scheduling is usually adopted: a task runs to completion and is not preempted by other tasks; therefore, there is no context-switching between tasks. In this regard, eventbased OSes introduce less overhead than thread-based ones. A typical example of an event-based OS is TinyOS which is popularly used TWSNs. In such networks, each node is usually equipped with limited hardware capability, powered by batteries. Due to this hardware limitation, the design of TinyOS aims at simplicity to improve energy efficiency. In contrast to event-based OSes, thread-based OSes usually employ preemptive task scheduling. In this scheme, a task can be preempted by others. This scheme generally improves system performance in terms of processor utilization and system responsiveness, especially when tasks in sensor networks are I/O intensive. Nevertheless, this task scheduler is more complex and involves context-switching overhead, which can shorten battery lifetime. Most modern generic operating systems such as Windows or Linux are preemptive. In the context of UANs, the networks are usually sparser than TWSNs, but have more powerful network nodes. Some of them are powered by solar panels or fuel cells; therefore, energy efficiency is not as critical as in TWSNs, although still important. A more powerful processor can allow a node to preprocess the acquired data before sending it to reduce network traffic, which means tasks in UANs will include more computation than TWSNs. With these remarks in mind, we plan to implement a hybrid approach for Aqua-OS. Specifically, the OS is event-based to maintain its responsiveness to events and a task can be preempted by another using customizable policies. We are also going to provide users with pure event-based or preemptive scheduling methods and therefore the Aqua-OS optimizer can choose the best scheduling method for the specific applications.
Aqua-OS: An Operating System for Underwater Acoustic Networks 569 4.4 Memory and Storage Management Memory management is an important issue for every OS. It has great influence on the performance of the OS and applications running on it. The choice of memory management techniques depends on application requirements and hardware capability. Many OSes used in TWSNs have very simple memory management methods because typical terrestrial nodes have a small amount of memory. TinyOS, for example, does not support dynamic memory management; the size of memory allocated to each component is determined at the compilation phase. In underwater networks, the assumption of small memory no longer holds because the systems (e.g. underwater sensor nodes or AUVs) often consist of more advanced hardware. Additionally, because underwater applications are complicated and diverse, they have quite different requirements on memory size and memory access patterns from terrestrial ones. In order to facilitate more complicated applications, Aqua-OS will provide dynamic memory allocation. Along with this feature, Aqua-OS will also support virtual memory (VM) management, which brings about better main memory utilization from preventing memory fragmentation. Another advantage of VM is the robustness of the OS since each process has its own address space separated from the others. Moreover, VM offers applications more memory than actually available main memory. Also static memory management is provided by OCT to fit applications requiring a very simple memory management scheme. Besides memory management, file systems are needed in underwater systems to store large amount of data or applications. File systems will allow for a flexible and convenient way to manage large storage space. For example, since communications over the acoustic link are error-prone and energy consuming, a data set is usually held for some period of time, after which it will be processed (e.g. compressed) and then transmitted. If that data set is large, it should be stored in external memory rather than the main memory. Without a file system, an application will have to handle the storage device by itself, which is error prone and may corrupt data of other applications. Aqua-OS will support multiple file systems to facilitate different requirements or preferences. The Aqua-OS optimizer is responsible for picking up the file system that optimally balances the file system performance and the resource consumption. As the cost of flash memory keeps falling, a large flash memory module can be included into the hardware platform in which it plays the role of storage for the file system and/or swap space for the VM. Without a swap space, we can save some energy, but the number of programs that can be loaded simultaneously will be limited by the capacity of the main memory. 4.5 Adaptive Power Management Some underwater systems can be powered by solar panels or fuel cells, and as such, their batteries can be recharged. However, efficient usage of the batteries is still an important issue because the alternative power sources will not work during a particular time frame, e.g. daytime for solar panels. Most existing OSes for TWSNs take design simplicity as a factor in reducing power consumption. A few of them
570 H. Mo et al. consider dynamic power adjustment. TinyOS allows for hardware power management, but it is up to applications to decide when to put a device into a sleep state. MANTIS simply shuts down the scheduler when no task is to be scheduled. Contiki has a software-based online energy estimation mechanism for sensor nodes. A limitation of existing OSes for TWSNs is that they mainly focus on power saving at the processor or controller. In UANs, other devices, for example acoustic modems or sensors usually consume more energy than the processor; therefore, in order to optimize energy efficiency, it is necessary to consider other components. Aqua-OS will implement some adaptive dynamic power management (DPM) algorithms which utilize run-time information to reduce power consumption when systems are serving light workload or idle. Aqua-OS manages the power at three different levels: the component level, the node system level, and the network system level. At each level, Aqua-OS provides a particular sub-dpm algorithm to supervise and control the state of the components, and together, the three algorithms can reduce energy consumption of the system. At the component level, there are three candidate mechanisms: clock gating, supply shutdown and multiple and variable power supplies. The sub-dpm algorithm controls these mechanisms and makes decision on when and which mechanism to be selected for which device. At the node system level, power management can be considered as a constrained optimization problem when components and requests are modeled as stochastic processes and it provides the flexibility to tradeoff between power and performance. At the network system level, the customized DPM algorithm can be in cooperation with some energyconscious communication protocols, and by increasing the predictability of communication patterns (predict the arrival time of messages/packets), idle times can be exploited to force communication devices into a low-power inactive state. The Aqua-OS optimizer is going to select one or a combination of power management schemes based on different application requirements and user preferences. 4.6 Failure Detection and Recovery For the hardware failure detection and recovery, Aqua-OS maintains a hardware dependency structure to keep track of the threads that depend on specific hardware components. This structure is updated by a Hardware Monitoring Thread (HMT) running in the kernel space. If an application thread detects a hardware component failure, via an incorrect return value following a system call, for example, it reports this event to HMT. After confirmation of the failure occurrence, HMT notifies all threads using the hardware component of the failure. After these threads have handled this failure, HMT blocks all of them and starts the Hardware Exception Handler to recover the hardware failure. Finally, HMT resumes these threads. HMT requires little resource usage because of its limited functions; therefore, it can reside in the main memory all the time to survive hardware failures. This hardware failure detection and recovery mechanism strengthens both energy efficiency by blocking relevant threads and system robustness by handling hardware component failures. For the software failure detection and recovery, Aqua-OS separates kernel address space and user address space to prevent malfunctioning application threads from tampering with kernel code or data. Also for critical threads e.g. AUV flight control
Aqua-OS: An Operating System for Underwater Acoustic Networks 571 thread, they can register their important memory ranges to the kernel. In this way, instead of direct access, other threads trying to access these memory ranges need to perform a system call to request the kernel to access for them, which can avert malicious threads from modifying critical thread data. On processors supporting the hierarchical protection domain scheme e.g. IA32 architecture, Aqua-OS can also utilize this feature to implement different privilege modes which are assigned different permissions. To further enhance protection against malicious software, Aqua-OS maintains a lightweight security rule database which defines the illegal or dangerous software behaviors including accessing kernel or protected memory addresses, fork bomb and attempts to deplete system resources. Also different illegal software behavior has different damage weight. Once the total weight of illegal behaviors performed by a thread exceeds a threshold, kernel can terminate this specific thread. By the aforementioned software failure detection measures, Aqua-OS effectively protects the OS kernel as well as the critical threads and meanwhile prevents the malicious threads from undermining system reliability and security. Based on the application requirements and user preferences, the Aqua-OS optimizer will choose a couple of failure detection and recovery schemes to balance the system reliability and resource consumption. 4.7 Aqua-OS Optimizer The Aqua-OS optimizer is illustrated in Fig. 3. The optimizer is composed of three components: OS Component Combination, objectives and metric evaluation. Aqua- OS will pick a couple of hardware drivers from the hardware abstraction based on the specific hardware platform of a UAN node. In addition, a component will be chosen from each of the four categories of the OCT as listed in Section 4.2. For instance, preemptive scheduler is chosen as the scheduling method and component level and node system level power management schemes are selected as the power management strategy. The selected hardware drivers and components from OCT form an OS Component Combination. Aqua-OS defines a uniform set of metrics to evaluate the performance of an individual OS Component Combination. Currently we have four metrics: OS overhead, (the additional processing time incurred by the OS itself), OS footprint, (the memory usage by the OS), real-time performance, and OS energy consumption,. For each specific OS Component Combination, we obtain a performance metric vector,,,. The application requirements and user preferences form the Objectives and create an objective vector,,,, where is the weight for, is the weight for and so on. Different application requirements and user preferences lead to different. For instance, a real-time application has a larger while a long-term non time sensitive application has a larger to emphasize on energy efficiency. For each OS Component Combination, Aqua-OS calculates its performance score. The OS Component Combination that achieves the highest performance score is selected to generate an Aqua-OS version which is optimal for the given application requirements and user preferences.
572 H. Mo et al. Fig. 3. Aqua-OS Optimizer 5 Conclusions and Ongoing Work The significant difference in hardware configuration between TWSNs and UANs suggests that existing operating systems for TWSNs will not fully utilize the more powerful hardware if used in the underwater settings. In conjunction with more powerful hardware, underwater software is more complicated and diverse which needs to be supported by a more advanced operating system. Aqua-OS is designed to meet this requirement by offering applications robustness, customizability and energy efficiency. Aqua-OS is very much a work in progress. We will not try to develop a completely new operating system from scratch. Instead, we will construct the Aqua-OS based on the popular embedded Linux, which already provides preemptive multitask scheduler, dynamic and virtual memory management, a variety of file systems and drivers for a wide range of devices. For the first step, we are going to integrate all these components into the Aqua-OS Components Toolbox. In addition, we will add more components including event-driven task scheduler, static memory management, dynamic power management as well as failure detection and recovery mechanisms into the OS Components Toolbox. For the second step, we will implement the Aqua- OS Optimizer, which can pick up the optimal component combination based on application requirements and user preferences. In this way, we can reduce the workload of the development of Aqua-OS and make sure the applications running on embedded Linux can be ported to Aqua-OS without changes.
Aqua-OS: An Operating System for Underwater Acoustic Networks 573 References [1] Cui, J.-H., Kong, J., Gerla, M., Zhou, S.: Challenges: Building Scalable Mobile Underwater Wireless Sensor Networks for Aquatic Applications. IEEE Network 20(3), 12 18 (2006) [2] Heidemann, J., Ye, W., Wills, J., Syed, A., Li, Y.: Research Challenges and Applications for Underwater Sensor Networking. In: WCNC, Las Vegas, NV (2006) [3] Bhatti, S., Carlson, J., Dai, H., Deng, J., Rose, J., Sheth, A., Shucker, B., Gruenwald, C., Torgerson, A., Han, R.: MANTIS OS: An Embedded Multithreaded Operating System for Wireless Micro Sensor Platforms. Mobile Networks and Applications 10(4), 563 579 (2005) [4] Levis, P., Madden, S., Polastre, J., Szewczyk, R., Woo, A., Gay, D., Hill, J., Welsh, M., Brewer, E., Culler, D.: TinyOS: An Operating System for Sensor Networks. In: Ambient Intelligence, pp. 115 148. Springer, Heidelberg (2005) [5] http://ecos.sourceware.org/ [6] http://www.contiki-os.org/p/about-contiki.html [7] Levis, P., Gay, D.: TinyOS Programming. Cambridge University Press, New York (2009) [8] Cao, Q., Abdelzaher, T., Stankovic, J., He, T.: The LiteOS Operating System: Towards Unix-Like Abstractions for Wireless Sensor Networks. In: IPSN (2008) [9] http://www.tinyos.net/tinyos-2.x/doc/html/tep115.html [10] Dunkels, A., Gronvall, B., Voigt, T.: Contiki - A Lightweight and Flexible Operating System for Tiny Networked Sensors. In: LCN (2004) [11] Benini, L., Bogliolo, A., De Micheli, G.: A Survey of Design Techniques for Systemlevel Dynamic Power Management. IEEE Transactions on VLSI Systems 8(3), 299 316 (2000) [12] Sinha, A., Chandrakasan, A.: Dynamic Power Management in Wireless Sensor Networks. IEEE Design and Test of Computers 18(2), 62 74 (2001) [13] Paleologo, G., Benini, L., Bogliolo, A., De Micheli, G.: Policy Optimization for Dynamic Power Management. IEEE Transactions of Computer Aided Design 18(6), 813 833 (1999) [14] Lu, Y.-H., De Micheli, G.: Comparing System-level Power Management Policies. IEEE Design and Test of Computers 18(2), 10 19 (2001)