KR20050092231A - Operating system for low power sensor module in sensor network and method thereof - Google Patents

Abstract

The present invention relates to an operating system and method for a low power sensor module in a sensor network.

An operating system and method for a low power sensor module in a sensor network of the present invention comprises a memory organization module consisting of flash and RAM and serving as an abstraction of memory; A register abstraction module interworking with the memory organization module to abstract a register by accessing with a single address; A register access method providing an interface to access the register; A memory management module for allocating and deallocating memory abstracted by the memory organization module; Low-level I / O peripheral drivers that provide methods through inputs and outputs to and from peripherals; A power management module for managing a power state of the system; An event handler which updates the state of a thread by handling an interrupt as a trigger of an operation; Technical features include a task loader that puts a thread context into a scheduling queue that is executable by scheduling codes of a task area from a memory through a path of an operating system and an application program, and a scheduler triggered by the event handler to execute a thread of a task. .

Accordingly, the operating system and method for the low power sensor module in the sensor network of the present invention classifies all the tasks performed on the operating system into periodic tasks and aperiodic tasks so that the sensor node is optimized for power management. This has the effect of providing a simple programming structure for the application, performing efficient tasks, and providing a computing environment suitable for sensor networks.

Description

Operating system and low power sensor module in sensor network in sensor network

The present invention relates to an operating system and method for low power sensor modules in a sensor network, and more particularly, to an embedded operating system using low power, small code size, and minimal hardware resources.

Sensor networks have several characteristics that differ from conventional networks: they must be self reconfigurable, support data-centric addresses, and have limited resources. Integrated software for the sensor network must be able to support these characteristics.

The sensor network needs to be autonomously reconfigured because its shape changes dynamically due to power depletion, node mobility, node failure, and environmental disturbances. The communication protocol of the sensor network forms an ad-hoc network when there is such a dynamic shape change. -hoc Configure the network.

Integrated software for sensor networks must support sensor applications to continuously reconfigure and perform their tasks transparently, regardless of the shape of the network. Group management and fault tolerance techniques are essential to support this effectively. Group management should provide a programming interface that keeps the sensor applications needed to successfully perform the targeted task in a group, and can easily implement the functions of propagating a given task to the appropriate sensor node and integrating the collected data.

Sensor networks are more prone to errors than typical networks, and must provide transparent error handling for sensor applications. In addition, if the shape of the network changes, the failed node should be removed from the group, and a new available node should be added to the group to support a given task in succession.

Sensor networks use data-centric addresses rather than node-centric addresses because of the myriad of sensor nodes locally and the nature of their applications. In other words, it uses attribute-based addresses rather than global addresses such as the Internet. In the attribute-based address system, queries on attributes of a phenomenon are used rather than sending queries to specific nodes.

Application software installed in the sensor node should be able to be downloaded and executed dynamically, not statically, but due to changes in the environment, expansion of the application area, and the addition of a function for detecting a phenomenon. These application changes can vary from simple recalibration of parameters to rewriting the entire program.

Integrated software for the sensor network must support the ease of reconfiguration, flexibility and efficiency of these programs. Research into virtual machines for small devices such as Java 2 Micro Edition (J2ME) and Kilobyte Virtual Machine (KVM) has been actively conducted. However, these virtual machines require a large amount of memory that sensor nodes cannot provide yet, and low power considerations are weak.

Developed by Berkeley University, TinyOS supports the use of threads to ensure small code size and concurrency. It also uses a new programming language called nesC to facilitate software development. With nesC, TinyOS provides an environment for developing small reusable application software. TinyOS is an operating system specially designed for network embedded systems. It is an ultra-small OS whose core code is less than 4000 bytes and data memory is less than 256 bytes as well as event-based applications.

TinyOS chose an event driven model that could support multitasking with very little memory, instead of the stack-based multithreading approach of reserving stack memory areas. The event-driven multitasking approach enables low power consumption, an important feature of ultra-small Motes. In this way, the CPU is put into sleep mode during the time when no event occurs, thereby enabling low power through efficient use of the CPU.

The structure of the SenOS kernel developed by SNU is based on a finite state machine model. SenOS consists of the core kernel section, runtime monitors, replaceable state transition tables, and callback libraries. Programmers can easily design SenOS applications, automatically convert them to executable code using the SenOS design tool, and dynamically load the application's executable code at runtime using a monitor.

SenOS offers a number of advantages, first of all based on the state machine model, which makes the implementation simple and efficient. It also has the advantage of supporting highly efficient dynamic node reconfiguration by using interchangeable state transition tables and callback libraries.

In addition, Bertha OS is a small operating system designed for the Pushpin platform, centered at MIT University. Its main goal is to provide a programming model that runs on distributed sensor networks.

The concept of Pushpin computing itself is Paintable computing, which implements the concept of algorithmic self-assembly among pushpins installed arbitrarily without any location information in advance, and manages resources including network through Pushpin software Provides a programming model for

The prior art as described above is a power management method that operates by a simple event or interrupt in a sensor node oriented to low-power system software and the rest operates in a sleep mode. In the application of a ubiquitous environment through various sensors If you have a more complex application program, it is not efficient for power management. In addition, other operating systems except TinyOS had a difficult problem in reflecting the requirements of efficient power management.

In addition, even though all the resources are limited operating systems of sensor nodes, a programming model with compatibility and portability is important for ubiquitous environments. TinyOS's nesC component-based operating system, SenOS's finite state machine-based programming model, has low development and compatibility with other operating systems and portability. Most operating systems for sensor nodes are compiled with applications and downloaded to the sensor node as an image. Because of this, the administrative overhead of small modifications to the application is very high.

The sensor network needs real-time processing and distributed processing to reflect the requirements in the ubiquitous environment. Until now, there has been a problem that the sensor node operating system does not support the real-time processing as described above.

Accordingly, the present invention is to solve all the disadvantages and problems of the prior art as described above, the basic function is to transfer the sensing data through the autonomous sensing and the network configuration of the Ad-hoc network. Accordingly, an object of the present invention is to provide an operating system and method for a low power sensor module in a sensor network using low power, small code size, and minimal hardware resources.

The object of the present invention comprises a memory organization module consisting of flash and RAM and serves as an abstraction of the memory; A register abstraction module interworking with the memory organization module to abstract a register by accessing with a single address; A register access method providing an interface to access the register; A memory management module for allocating and deallocating memory abstracted by the memory organization module; Low-level I / O peripheral drivers that provide methods through inputs and outputs to and from peripherals; A power management module for managing a power state of the system; An event handler which updates the state of a thread by handling an interrupt as a trigger of an operation; In the sensor network comprising a scheduler for executing a thread of tasks triggered by the event handler and a task loader to put a thread context executable in the scheduling queue through the scheduling of the code of the task area from the memory through the operating system and the application path Achieved by the operating system for low power sensor module.

Another object of the invention is to (a) split a thread into a periodic thread queue and an aperiodic thread queue around a scheduler; (b) the task loader operating by a network or system reset event; (c) placing each thread in a periodic thread queue and an aperiodic thread queue based on a type defined from flash memory by the task loader; (d) the task loader estimating the period of the periodic thread queue and (e) inserting a power management system thread into the periodic thread queue to periodically manage power of the system. Achieved by an operating system method for the sensor module.

Details of the above object and technical configuration of the present invention and the effects thereof according to the present invention will be more clearly understood by the following detailed description with reference to the drawings showing preferred embodiments of the present invention.

The operating system designed for S-Engine, a sensor node constituting the sensor network, is an operating system for objective sensor network (OSFOS). Issues reflected in OSFOS design are optimal power management, a simple programming structure for sensor applications, efficient operation, and a computing environment suitable for sensor networks.

For this purpose, all tasks performed on the operating system are first classified into two categories, periodic tasks and aperiodic tasks, which are tasks that are repeatedly performed with a time period. Typical tasks are those performed when a condition is met by an event.

The reason for separating the work into two as described above is because it is advantageous in terms of power management of the sensor node. Performing a given task on an event in a network is the most representative aperiodic task. Due to the nature of the sensor network, it is very likely to be in the IDLE state most of the time. Thus, no special power management is required for aperiodic tasks.

On the other hand, considering the application running on the sensor node, this is the most typical application is to collect the data of the sensor and transmit it periodically over the network. Most implementations of this task occur periodically. If the scheduler of the operating system can easily see the performance of these periodic tasks and determine the IDLE interval and power consumption level, power management will be more efficient.

Another purpose of separation is to achieve simplicity of programming and efficiency of execution. The memory capacity of the sensor node is very limited. Therefore, at a programming level, it should be limited to using a predetermined module of a predetermined size through a predefined system interface. Given this aspect, it is a great advantage in terms of programming and system implementation and management that implements the interface to the two tasks and combines them to form an application program. Therefore, both programming and system operation are designed to be handled in units of periodic and non-periodic tasks.

The application program for S-Engine, a sensor node, is much simpler than a general-purpose computing environment for memory, power, and I / O devices. This feature can be a difficult constraint from a programmatic point of view. In other words, possible applications should be written within the scope of resources provided by S-Engine. Similarly, a simple and clear programming model is needed.

1 is an application programming model according to the present invention. In FIG. 1, a periodic thread (PT) is executed by a time triggered event, and a non-periodic thread (NPT) is a message triggered event. Is executed.

An application consists of one or more threads per task. A thread is a specification of a single task required by an application and is registered as one of periodic tasks and aperiodic tasks, that is, tasks that can be performed when certain conditions are met by an event.

As shown in Figure 1, each thread of the application is implemented as a single task that can no longer be divided, registered in the operating system by Register_Periodic_Thread (Period, Thread's Pointer), Register_NonPeriodic_Thread (Event Type, Condition, Thread's Pointer) It is the basic unit performed by The work of a thread can be such as accessing resources or processing data using services provided by the operating system.

For example, if the task of getting sensing data from the sensor every 10 seconds is implemented as a thread, it may correspond to a periodic task. When data needs to be transmitted in response to a request for data from the network, this is an event driven task.

Threads are written in C and use the system calls and data structures provided by the Static Library for the S-Engine. The implemented thread is registered and executed in the form of the thread context of FIG. 2 in the operating system through a loader.

The thread context becomes a basic unit of scheduling internally of the operating system, and a target application (task) can be executed through execution of each thread. Thread contexts are divided into two types, periodic and aperiodic, to match the overall system operation.

The periodic thread context includes IDs and priorities for identifying threads and periodic values in units of time to perform periodic tasks by timer events, and there is a counter for management. It also contains the address of the code region to be executed when scheduled by the timer. Aperiodic Thread Context Contains the thread ID, priority, and address of the code area to execute, and consists of the type and condition of the event.

The task context is shown in FIG. 3 for managing a threaded task. The task context is implemented for management of threads in a task unit, and no task unit scheduling is performed.

4 is a structural diagram showing an OSFOS according to the present invention. First, as shown in FIG. 4, system hardware resources are located below, and a network interface part for a sensor network is located on the right side.

The memory organization module 100 serves as an abstraction of memory. It acts as a map (MAP) that converts a memory hardware structure consisting of flash and RAM into a linear addressing system in small pieces for management. The memory structure based on the 8051-core, which is a micro-controller of S-Engine, is shown in FIG.

The 8051 microcontroller has 128Kbytes of internal registers and 8KBytes of RAM. And with 128K of flash memory, operating system code can be loaded. Similarly, the created tasks are located with a given sector and size, and the data inside the OS and the data used by each thread of the task are mapped to the RAM area. The message service between the task and the OS is implemented in the form of a stack or a first in first out (FIFO) through a shared pool, and data for thread operation and scheduling is also located in the RAM area.

The register abstraction module 110 abstracts the registers at the macro level for access of the registers of the microcontroller at the programming level. Each register may be accessed with one address in association with the memory organization module 100. At the programming level, access of registers is necessary for debugging purposes of the system and for implementing services such as switching the system's power state.

The register access method 120 provides an interface for accessing the registers of the microcontroller. Implemented as a method, implemented as a read and a write. The access of the register is mainly limited to special function registers of the S-Engine and can be mainly used for the power management module 130 and the I / O interface.

The memory management module 140 allocates and releases the memory abstracted by the memory organization module 100. Consideration should be given to the management policy based on characteristics such as sector size provided by flash type. When a task is loaded into memory, the task's code is allocated to the flash area and dumped, and the data area is allocated to the RAM area and dumped. The operation is performed through the division of the code and the data area determined at compile time and is performed through the system call of the task loader 150.

The power management module 130 basically provides a system interface for managing the power state of the system to match the power level provided by the microcontroller. The power management module may be inserted into the Periodic Thread Queue (PTQ) 160 when a task is loaded by the task loader 150 as a system thread. The power management thread determines the cycle to be executed by determining the cycle of the PTs and periodically controls the power through the system interface for power management, the operation of which is illustrated in FIG. 6.

FIG. 6 is a diagram illustrating a Power Management System Thread (PM-ST) according to the present invention, in which portions indicated by bold lines are periodically executed by threads 1, 2, and 3, which are implementations of periodic tasks. It is a section. At this time, a cycle of power management that is periodically repeated according to execution of threads 1, 2, and 3 is repeated as High Power-> IDLE-> Low Power-> IDLE-> High Power. Following this repetitive power level, the PM-ST wakes up periodically to perform overall power management of the system. The system thread for the system to wake up from sleep mode may reside in the event triggered job queue to wake up and restore the system when a predetermined event occurs.

The low level I / O peripheral driver 170 is an I / O interface considered by the hardware of the S-Engine. The low level I / O peripheral driver 170 may be divided into three parts. There are JTAG and UARTs for the host interface, and the sensor or implementer can be connected to the GPIO, ADC, or I2C interface. Devices such as timers and RTCs for the CPU and the network are connected. The low level I / O peripheral driver 170 provides basic methods for I / O with them.

The System Util Access Method 180 provides a system interface for accessing the RTC and Watch-dog Timers through methods provided by the low level I / O peripheral driver 170. to provide. The system timer interrupt plays an important role in operating the system through the event handler 220.

The sensor device driver 190 provides a basic interface for reading data from a mounted sensor or controlling an executor through a method provided by the low level I / O peripheral driver 170. Each device can retrieve the data through interrupt or protocol through the corresponding interface and process the data when activated by the event handler.

The host interface 200 is used for debugging purposes and for downloading OS and application programs in system development. In the case of the S-Engine connected to the host, it can directly communicate with and control the host through the interface.

The hardware abstraction interface 210 provides a consistent system interface of various devices and interfaces, and obtains compatibility of an operating system when hardware is changed.

The event handler 220 operates the system in an event driven manner. Accordingly, the event handler 220 updates the state of the corresponding thread by processing interrupts from a network, a sensor, a timer, and the like as triggers of all operations of the system. The event handler 220 performs the basic function of the existing interrupt handler. That is, when an interrupt occurs, the existing register value is stored in the stack area, the interrupt is processed, and the registers of the stack are restored to perform the work that was being performed from the corresponding program counter.

The task loader 150 serves as a path between an operating system and an application program, and a basic function is to put a thread context that can be executed by scheduling codes of a task area from a memory into a scheduling queue. At this time, it is determined whether the context is a periodic task or an aperiodic task and put it in the corresponding queue. The task loader 150 may separate the tightly coupled build of the OS and the application from the compile time. That is, the build of the OS and the build of the application can be taken separately, and through this, the application of the unit of thread can be downloaded to the memory and executed from the network. Therefore, it can have a great advantage in terms of the efficiency of management of the S-Engine and in terms of collecting and processing the distributed data.

The scheduler 230 operates as a non-preemption, and the input / output is a blocking I / O. The PT (Periodic Thread) queue of the time trigger and the Non-Periodic Thread (NPT) of the event trigger (240) ) Consists of two queues. The operation itself of the scheduler 230 is triggered and performed by the event handler 220. An overview of the operation is performed by round-robining each thread queue to select a thread for that event. If the event is an event caused by a timer, the PTQ 160 executes the corresponding thread. If the event is not an event by a timer, the NPTQ 240 executes the corresponding thread. C-style pseudo code for scheduler operation is shown in Table 1 below.

7 is a conceptual diagram for the operation of the OSFOS. There is a PTQ 160 and an NPTQ 240 around the scheduler 230. Initially, task loader 150 is operated by a network or system reset event. Task 1 250 is a thread that is located in the PTQ 160, NPTQ 240 based on the type defined by the flash loader 260 by the task loader 150. At this time, the task loader 150 estimates the period of the PTQ 160 and inserts the PM-ST 270 into the PTQ 160 so that the PM-ST 270 periodically wakes up to manage power of the system.

The scheduler 230 is operated by the event handler 220, mainly a timer event and a network event. In the case of a network event, the event handler 220 generates an event in response to an interrupt occurring at the network interface to operate the scheduler 230. When receiving the event, the scheduler 230 executes a thread of a task waiting for a network event or a network protocol system thread (Net-ST) 280, which is an implementation of a network protocol.

Although the present invention has been shown and described with reference to the preferred embodiments as described above, it is not limited to the above embodiments and those skilled in the art without departing from the spirit of the present invention. Various changes and modifications will be possible.

Accordingly, the operating system and method for the low power sensor module in the sensor network of the present invention classify all the tasks performed on the operating system into periodic tasks and non-periodic tasks so that the sensor node is optimized for power management and the sensor application program. This has the effect of providing a simple programming structure, efficient operation, and a computing environment suitable for sensor networks.

1 is an application programming model according to the present invention.

2 is a thread context in accordance with the present invention.

3 is a task context in accordance with the present invention.

4 is a structural diagram showing an OSFOS according to the present invention.

5 is a block diagram illustrating OSFOS memory extraction according to the present invention.

6 is a diagram illustrating a power management system thread according to the present invention.

7 is a flowchart illustrating the OSFOS operation according to the present invention.

<Description of the symbols for the main parts of the drawings>

100: memory organization module 130: power management module

140: memory management module 150: task loader

160: PTQ 170: Low Level I / O Peripheral Driver

230: scheduler 240: NPTQ

Claims (12)

A memory organization module composed of flash and RAM and serving as an abstraction of memory; A register abstraction module interworking with the memory organization module to abstract a register by accessing with a single address; A register access method providing an interface to access the register; A memory management module for allocating and deallocating memory abstracted by the memory organization module; Low-level I / O peripheral drivers that provide methods through inputs and outputs to and from peripherals; A power management module for managing a power state of the system; An event handler which updates the state of a thread by handling an interrupt as a trigger of an operation; A task loader that puts a thread context into a scheduling queue that executes code of a task area from a memory through a path of an operating system and an application program; And A scheduler triggered by the event handler to execute a thread of a task Operating system for a low power sensor module in the sensor network, characterized in that configured to include. The method of claim 1, Low power sensor in the sensor network further comprises a system utility access method for providing a system interface for accessing the RTC, timer and watch-dog timer through the methods provided by the low-level I / O peripheral driver Operating system for the module. The method of claim 1, Low power sensor module in the sensor network, characterized in that further comprises a sensor device driver for providing an interface for reading data from the mounted sensor or control the runner through a method provided by the low-level I / O peripheral driver OS for. The method of claim 1, Operating system for a low power sensor module in the sensor network, characterized in that further comprises a host interface capable of direct communication and control with the host. The method of claim 1, An operating system for a low power sensor module in a sensor network, characterized in that it further comprises a hardware abstraction interface compatible with the operating system when changing hardware. The method of claim 1, The scheduler is an operating system for a low power sensor module in the sensor network, characterized in that for processing separated into a timer event and a network event operating by the event drive method. The method of claim 1, The power management module is an operating system for a low power sensor module in the sensor network, characterized in that for managing the power level of the system in a predetermined cycle unit generated by estimating the processing cycle for the periodic threads. The method of claim 1, The scheduler is an operating system for a low-power sensor module in the sensor network, characterized in that for processing all of the processing unit on the sensor node is divided periodically and aperiodic. (a) separating a thread into a periodic thread queue and an aperiodic thread queue around a scheduler; (b) the task loader operating by a network or system reset event; (c) placing each thread in a periodic thread queue and an aperiodic thread queue based on a type defined from flash memory by the task loader; (d) the task loader estimating a period of a periodic thread queue; And (e) inserting a power management system thread into the periodic thread queue to periodically manage power of the system Operating system method for a low power sensor module in the sensor network, characterized in that comprises a. The method of claim 9, The step (a) is characterized in that the scheduler operates by the event handler and generates an event. The method of claim 10, And wherein the event is a timer event or a network event. The method of claim 11, The network event is an operating system method for a low power sensor module in the sensor network, characterized in that the event handler generates an event in response to the interrupt occurring in the network interface to operate the scheduler.