Introduction Network sensors are resource-constrained embedded devices that integrate sensor technology, embedded computing technology, modern network and communication technology, and distributed information processing technology. They represent an important application model of "ubiquitous computing" in the field of micro-embedded systems. Research on network sensors has historically been limited by hardware platforms, hindering its development. However, with continuous advancements in semiconductor, communication, microelectronics, and micromechanical technologies, low-power, low-cost, and multifunctional sensor network systems have rapidly developed, making the fabrication of tiny, flexible, and low-power sensor nodes a reality. Background Application Characteristics Network sensor applications have their own unique characteristics, primarily including: small size and low power consumption, high-concurrency operation, limited physical parallelism and control hierarchy, and diverse design and usage. On the one hand, sensor resources are extremely limited, significantly restricting the design of underlying embedded programs; on the other hand, the application programs running on the sensor and the system kernel are usually tightly integrated, and the number of tasks required, execution time, execution results, and memory consumption are relatively predictable. Furthermore, there are many types of sensors, and different types are required for different applications. In specific applications such as military applications and space exploration, a large number of different types of sensors are needed to work together to complete specific application events. Therefore, if the software system running on the sensor can have relatively good flexibility, configurability, and reusability, it will be better able to meet application requirements. Comparison of Existing Embedded OSes Currently, there are many embedded operating systems, among which representative ones include VxWorks, Windows CE, pSOS, and Neculeus. Their advantages are: powerful functionality; rich APIs and embedded application software; good real-time performance, especially VxWorks; and good stability. Disadvantages are: high cost; closed source code, leading to a series of problems such as device support and application software porting; in addition, for sensor devices, these embedded OSes are too "large". uC/OS and embedded Linux are currently gaining increasingly widespread use. Their advantages are: high execution efficiency, small footprint, good scalability, and they are free and open source. uC/OS has good real-time performance, while the real-time performance of embedded Linux needs further improvement. The drawbacks are that these are all relatively general-purpose embedded operating systems and cannot fully adapt to the needs of sensor applications. For example, embedded Linux still requires at least hundreds of kilobytes of ROM and RAM space to function, while the uc/os kernel, although shrinkable to a few kilobytes, is still not sufficiently streamlined for some sensor applications. UC Berkeley designed and developed TinyOS, an embedded operating system for wireless sensor network applications, and the system programming language nesC. Based on our analysis of existing embedded OSes, especially TinyOS, we designed and implemented γOS, a miniature embedded operating system supporting network sensors, and developed the system programming language AntC. γOS Design: γOS is a miniature embedded operating system designed for network sensor applications. Considering the aforementioned application characteristics of network sensors, γOS is designed with several features: support for sufficiently small hardware systems to facilitate the arbitrary deployment of sensor devices in the detection environment; support for sufficiently low system power consumption to ensure a sufficiently long lifespan for sensor devices; support for integrating sensing devices that can interact with the physical world to achieve data acquisition and transmission; and a balance of moderate flexibility, reusability, and configurability. γOS also needs to address two prominent issues in sensor networks: 1) Due to the concurrent and intensive nature of sensor operations, it is essential to ensure the concurrent and real-time transmission of numerous different data streams; 2) The system must provide an efficient modular management strategy, tightly integrating specific hardware devices and application components to reduce processing and storage overhead. To this end, the design focus of γOS is primarily on the following aspects: a low-power microkernel; a microthreaded system architecture; component-based functional design; and interfaces supporting sensor communication. Supporting a Low-Power Microkernel To reduce power consumption, γOS employs a relatively simple kernel mechanism consisting of two parts: system initialization code and a small core scheduling component. The system initialization code is platform-dependent; the core scheduling component implements a priority-based two-level scheduling mechanism, consisting of two scheduling queues: an event queue and a task queue. The event queue has a higher priority than the task queue, and each queue uses a FIFO scheduling mechanism. [align=center][IMG=Schematic diagram of γOS kernel scheduling]/uploadpic/THESIS/2007/12/2007121810032093462F.jpg[/IMG] Figure 1 Schematic diagram of γOS kernel scheduling[/align] In addition, in order to reduce energy consumption, based on the energy management algorithm of TinyOS, energy control components were designed and implemented: Dynamic Power Management (DPM) component and Dynamic Voltage Regulation (DVS) component. Micro-thread system architecture [align=center][IMG=System architecture of micro-threads]/uploadpic/THESIS/2007/12/2007121810032850582G.jpg[/IMG] Figure 2 System architecture of micro-threads[/align] As shown in Figure 2, γOS implements a micro-thread system architecture based on an event-driven model through components, using event triggering to wake up the corresponding functional components to work. Each functional component can consist of the following parts: Event handling functions are used to handle underlying hardware interrupts, such as MCU external interrupts and timer interrupts. They can submit tasks to the core scheduling component but do not wait for task execution. Events have high priority, can preempt task execution, and can be passed. It provides a concise way to abstract the boundary between hardware and software, making hardware interrupt support very simple. Commands are used to execute operations on underlying components; they are non-blocking and must return the result (success or failure) to the caller. Tasks represent a relatively concentrated set of operations within a component. Tasks are not preemptive; tasks are atomic and executed in a first-in, first-out manner, meaning one task must complete before the next can begin. However, tasks can be preempted by event handling functions. Component states represent the current working state of the component and can be referenced by its own functional functions or other components. Utilizing a microthreaded system architecture, γOS can effectively reduce the cost of context switching; simultaneously, by introducing atomic statements to handle tasks and events, and even concurrent operations between events, it implements a microthreaded asynchronous communication mechanism, effectively avoiding blocking, polling, and data resource contention. Component-Based Functional Design In specific applications, a large number of different types of sensors need to work together to complete specific application events. Therefore, the software system running on the sensors needs relatively good flexibility and configurability. To this end, γOS provides support for a component-based functional design approach. γOS can be decomposed into a core scheduling component and several functional components. Existing functional components mainly include: power consumption control components such as Dynamic Power Management (DPM) and Dynamic Voltage Regulation (DVS), AntIP protocol (supporting micro-embedded TCP/IP protocol), USB driver components, network card driver components, and XML parser components, etc. Different functional components are configured according to different applications to achieve specific goals. γOS supports both static configuration and dynamic loading. Static configuration components can include at least one core scheduling component, while other functional components can be pre-configured statically or dynamically loaded according to the corresponding application requirements. [align=center]Figure 3 Schematic diagram of γOS component[/align] Interface supporting sensor communication γOS provides interface support for sensor communication through the AntIP component. This mainly includes support for peer-to-peer and multicast communication modes between sensor nodes, peer-to-peer communication mode between sensor nodes and PCs, and event-based asynchronous communication processing mode. AntIP is a miniature embedded TCP/IP protocol stack suitable for 8/16-bit machines. Although it removes many less commonly used functions from full-featured protocol stacks, it still retains the necessary protocol mechanisms for network communication, supporting protocols such as ARP, IP, ICMP, TCP, and UDP, and providing simple application layer and device driver layer interfaces. AntIP's design draws inspiration from the design philosophy of uIP. Typical Applications [align=center]Figure 4 Schematic diagram of hardware platform[/align] γOS is designed for network sensor applications and can run on various target sensors. We adopted the γOS mechanism to design a typical network image sensor system for image data acquisition applications. The system mainly consists of a main control module, a storage module, a USB host module, an Ethernet module, a camera module, and a serial port module (reserved interface). The chips used are Philips P89C60X2 (80C51 chip), USB control chip SL811HS, RAM chip 62256, and NIC chip RTL8019AS. The platform initialization code (AntC language) is as follows: `useSL811HS useCamera useRTL8019 classPlatform { public static int Init() { RTL8019.Init(); if (SL811HS.UsbInit() == FALSE) return -1; if (Camera.CameraInit() == FALSE) return -1; if (Camera.CameraStart() == FALSE) return -1; AntIP.Init(); return 1; } public static void Start() { postAntIP.Run; } public static void main() { Init(); Start(); } }` This code initializes the network card module, USB module, and camera module. Conclusion The code size and required data space for each module of the γOS network image sensor are shown in Table 1. As can be seen from the table, the core code size of γOS is roughly the same as that of TinyOS. [align=center]Table 1 Module Code Size and Required Data Space[/align] In this article, we briefly describe the application characteristics of network sensors in ubiquitous computing environments, introduce the design and several features of γOS, an embedded operating system targeting network sensors, and establish a typical application platform. Finally, we briefly present the performance of γOS on this platform.