KR20100078974A - Operating system based osek and its software update system for wireless sensor nodes - Google Patents

Abstract

PURPOSE: An operating system based on OSEK(Open Systems and their Interfaces for the Electronics in Motor Vehicles) and a software update system thereof for wireless sensor nodes are provided to perform a software update function by using wireless communication with a software update manager. CONSTITUTION: An OS(Operating System) for sensor node observes the standard of an intelligent OS defined in an OSEK. A kernel is classified into the processing levels for an interrupt, a scheduler and a task. A service or object within each level has priority and a size and function depending on CC(Conformance Classes). A high speed ISP(In-System-Programming) module is inserted into the kernel, and an update manage of a GUI(Graphic User Interface) environment is operated in a PC.

Description

Operating system based OSEK and its software update system for wireless sensor nodes

The present invention relates to an OSEK-based operating system for sensor nodes, and more particularly, to a layered kernel structure, to size an operating system according to an applied application, to support real-time processing through preemptive priority-based task scheduling, and to perform complex control operations. OSEK not only suitable for various sensor network applications by providing task model classification, stable interrupt handling, efficient event management mechanism, shared resource management policy, timer service for recurring tasks, and remote software update function using Software Update Manager. It is an operating system and software update system for OSEK-based sensor nodes that can be fully utilized for intelligent vehicles using low-cost CPUs because of compliance with the standard.

The wireless sensor network is composed of a small microcontrol unit (MCU) capable of sensing and processing sensed information with various sensors attached to it, and a low-cost compact device, that is, a sensor node composed of a wireless communication chip capable of transmitting and receiving the sensor. Means network.

However, since sensor nodes have limited hardware resources such as limited memory, limited battery capacity, and limited computing power, there is a need for research on operating system for sensor nodes to manage resources efficiently and provide various application environments on sensor networks. It is emphasized.

Open Systems and their Interfaces for the Electronics in Motor Vehicles (OSEK) is a real-time operating system standard for intelligent vehicles that enables intelligent vehicles to perform complex real-time applications while operating efficiently with minimal use of resources.

And the efficient resource management and real-time processing of the OSEK operating system can be applied to the sensor network.

The wireless sensor network can operate on a large scale consisting of 100 to 1000 or more nodes. However, if a program loaded on a distributed node needs to be replaced with new software or a bug has to be fixed, then retrieving a large number of nodes and reprogramming all nodes can be difficult and almost impossible.

To this end, propagating new programs and updating programs through the network have been recognized as essential technologies for sensor networks, and many studies have been conducted to date.

 Recently, the versatility of intelligent automotive parts and the complexity of the applications that control them have increased, and the resource requirements and costs used by each ECU (Electronic Control Unit) have increased. OSEK is an intelligent automotive real-time operating system standard that is jointly defined by leading European carmakers to enable each ECU to operate efficiently while minimizing resource use while performing complex real-time applications.

The OSEK operating system standard defines multitasking, event and resource management, interrupt handling, and alarm functions for real-time processing.

The OSEK operating system provides the ability to manage the execution status of tasks and determine the order in which tasks are performed through the scheduler. The task has four states as shown in FIG. 1 and the meanings of the states are shown in Table 1 below.

Task status of the OSEK operating system   condition                meaning  RUNNING  Task is currently running  READY  Wait state for scheduling  WAITING  Temporarily interrupted work while waiting for a specific event to occur  SUSPENDED  The job's job has ended

The task has a separate memory area and stores information for controlling each task in this area. The scheduler selects the highest priority task among the tasks that exist in the READY state and allows context selection to resume the work previously performed by the selected task. 2 illustrates a task scheduling method of an OSEK operating system.

 An event is used to notify a task that a particular event has occurred. It is generated by a task or kernel and delivered to a specified task. The task can wait for a specific event to occur, in which case it will be in the WAITING state and any work it is doing will be suspended until that event occurs.

The OSEK operating system uses the Priority Ceiling Protocol to prevent priority reversal and deadlock that can occur with common resource sharing protocols.

OSEK The operating system defines two categories of interrupts. Category 1 is an interrupt routine that does not use system services. It does not affect task management and is characterized by low overhead. Category 2 can call a system service from within an interrupt routine. This can affect task scheduling, so you must reschedule after the interrupt routine has finished.

To handle recurring or recurring tasks, the OSEK operating system provides an alarm service. Alarms can operate in three types: task activation, event generation, and callback routine execution. Information about them is statically assigned during system generation.

TinyOS was developed at UC Berkeley and supports various hardware and system functions in the form of modules. The program performs the full function by connecting modular components and sending events between components. All system components and application code are developed in nesC, the TinyOS programming language, and the nesC compiler combines the components together and generates a binary, including the kernel. TinyOS features event-driven and monolithic kernel sensor operating systems.

MANTIS was developed at the University of Colorado and supports multithreading and rapid prototyping. Threads have five levels of priority and can be preempted and scheduled in small increments. At run time, the application thread runs on a separate stack from kernel memory and supports basic synchronization techniques such as semaphores.

SOS] is a module based sensor operating system developed by NESL of UCLA. By dividing the kernel into two areas, static and dynamic modules, and developing and linking dynamic modules independently of the kernel, the modification is relatively free after the system is deployed. SOS uses Position Independent Code to support dynamic modules. Dynamic modules and static kernels use events to communicate with each other and provide priority-based event scheduling techniques, dynamic memory allocation, and memory protection.

Contiki, developed by the Swedish Institute of Computer Science, is a sensor operating system for multitasking support. The kernel can dynamically load an application at runtime in an event-driven kernel and uses Protothreads to provide a multitasking application development environment. It provides process-level preemptive multithreading and message passing through events, Rime communication stack, network simulator, and energy measurement.

The present invention has been made to provide a remote software update function using a software update manager in view of the above situation, and its object is to provide a layered kernel structure, size adjustment of an operating system according to an applied application, and preemptive priority based task scheduling. OSEK-based sensor node suitable for various sensor network applications by providing real-time processing support, task model classification for performing complex control operations, stable interrupt handling, efficient event management mechanism, shared resource management policy, and timer service for recurring tasks To provide an operating system and software update system.

Another object of the present invention is to provide an OSEK-based sensor node operating system and software update system for enabling a software update function using a software update manager and wireless communication.

Yet another object of the present invention is to provide an OSEK-based sensor node operating system and software update system that can be utilized not only for sensor nodes but also for intelligent vehicles using low-cost CPUs.

The OSEK-based operating system and software update system for the present invention for achieving the above object is a stable sensor node operating system (10) suitable for the sensor network application environment while complying with the standard of the intelligent operating system defined in OSEK; A kernel 20 which is divided into an interrupt level, a scheduler, and a processing level of a task, and all services or objects within each level have priorities, and sizes and functions of the objects are determined according to Conformance Classes (CCs); A high speed ISP (In-System-Programming) module 30 inserted into the kernel 20; It is characterized by consisting of the update manager 40 of the GUI environment operating on the host PC.

The present invention provides a layered kernel structure, size adjustment of the operating system according to the applied application, real-time processing support through preemptive priority-based task scheduling, task model classification for performing complex control operations, stable interrupt handling, efficient event management mechanism, By providing shared resource management policy and timer service for recurring tasks, it is suitable for various sensor network applications and enables software update function using software update manager and wireless communication. There is a special advantage that can be used for intelligent cars using low-cost CPUs.

Hereinafter, with reference to the accompanying drawings will be described in detail a preferred embodiment of the operating system and software update system for the OSEK-based sensor node of the present invention.

1 is a cross-sectional view of a nonvolatile memory device manufactured by the method of the present invention, Figures 2a to 2e is a process step of manufacturing a nonvolatile memory device by the method of the present invention, the operating system for the OSEK-based sensor node of the present invention and The software update system includes a stable sensor node operating system 10 suitable for a sensor network application environment while complying with an intelligent operating system standard defined in OSEK; A kernel 20 which is divided into interrupt, scheduler, and processing levels of a task, and all services or objects within each level have a priority, and sizes and functions of the objects are determined according to Conformance Classes (CCs); A high speed ISP (In-System-Programming) module 30 inserted into the kernel 20; It consists of an update manager 40 of a GUI environment operating on a host PC.

The kernel 20 is divided into three levels, as shown in FIG. 4, for processing interrupts, schedulers, and tasks. The services or entities within each level all have priorities. The size and functions of each entity are determined according to the Conformance Classes (CC), and the rules for determining the priority of services or entities follow the OSEK operating system standard.

The kernel 20 stores and manages the state of each task using a task control block (TCB). The TCB includes stack related information, task thread function pointers, priorities, and state of tasks for context exchange between tasks. It stores various information for task management. When all tasks are in the READY state, they are inserted into the Ready Queue for scheduling. As shown in FIG. 5, the wait queue is an array in which each element is a list of one priority, and the index of the array is the priority of tasks forming the list.

A task is placed in the READY state when it first starts its work, when it is preempted by a task with a higher priority than itself, and when it receives an event it has been waiting for from a kernel or other task. Is inserted into If the task is started for the first time and an event is delivered, it is inserted at the end of the priority list. If it is preempted by another task, it is inserted at the front of the list.

There are three types of scheduling policies defined by the OSEK standard: preemptive, non-preemptive, and mixed. The operating system of the present invention uses a hybrid scheduling policy in which scheduling is performed according to a scheduling type of a running task. For this purpose, an operating system adds a field indicating a scheduling type. The hop-scheduled scheduling scheme can reduce the overhead of frequent context switching by defining a task that takes less time than the context switching time or performs a relatively simple task as a non-preemptive task. Suitable for various application environments.

Resources shared on the system cannot be occupied by two tasks at the same time. The OSEK standard extends the upper priority protocol to the interrupt level for shared resource management. However, most low-cost MCUs, such as the ATmega128, used primarily for sensor nodes, use vector interrupt handling. In the case of the vector type interrupt method, the priority level is set in advance for each interrupt and cannot be changed.

In order to solve this problem, the inventor of the present invention defines the interrupt service routine in the structure as shown in FIG. 6 so that the priority setting of the interrupt processing routine, the wait for the generated interrupt, and the waiting interrupt routine can be handled in software. It also implements a kernel API that handles waits for pending interrupts and pending interrupts, ensuring that the upper priority protocols extended to the interrupt level and the two categories of interrupt handling work perfectly on low-cost MCUs.

To handle recurring or recurring tasks, it provides a counter, alarm, and alarm service in a two-tiered hierarchy. The counter is an intermediate concept between the hardware timer and the operating system. It provides a service for alarm and a service for hardware timer management. One counter is linked to one hardware timer and one or more alarms are linked to one counter. Counters are managed internally by the kernel and the counter API is handled only by the alarm API.

Alarms are classified into single or recurring alarms, depending on the number of times they operate as relative or absolute alarms. Alarms can also be of three types: task activation, event forwarding to a task, and simple callback routine execution. An alarm can be associated with only one counter.

The OSEK-based operating system for sensor nodes provides remote software updates. The software update system consists of a high speed ISP (In-System-Programming) module inserted into the kernel and an update manager of a GUI environment running on the host PC.

The high speed ISP module verifies the validity of the code data transmitted to the node through wireless communication and stores it in the external flash memory, and the code stored in the external flash memory when the completion of receiving all the code data and the command to perform the update are received. It provides the ability to program data at high speed into the MCU's internal flash memory.

Figure 7 shows the execution screen of the update manager operating on the host PC implemented in the present invention. The software update manager divides the compiled program image file into capsules of a certain size and delivers them to the base node through serial communication using HDLC (High Data Link Control) protocol. It also provides remote node status check, incoming packet monitoring, and remote node update status check. The update manager implemented by the research team can perform remote node management and software update with a simple button operation.

The implemented operating system was ported to the ATmega128-based SN100 sensor board developed by Gyeongbuk Ubiquitous New Technology Research Center to test the functions of each module and software update system of the operating system, and the results are summarized in Table 2. Compared to operating systems. For the software update test, an environment in which one base node and three remote nodes exist is constructed and the software update time for various code sizes is measured and shown in Table 3.

Memory usage on operating systems with code propagation and updating     platform  ROM (Byte)  RAM (Byte)  SOS  20464  1163  TinyOS (Deluge)  21132   597  Bombilla fever  39746  3196  Invention  17204  2404

Software update time  Hex image size (Byte)  Capule size  Required time (seconds)         1,048      24        7         2,525      57       15         3,418      77       21        20,149     449      218        35,686     790      455

The present invention designs and implements an operating system and software update system for sensor nodes based on the OSEK operating system standard, and tests the functions of each module and software update system of the operating system implemented using the SN100 sensor board. It was. The test results confirmed that all the functions of the operating system are stable and the remote software update is performed smoothly.

The OSEK-based operating system for wireless sensor nodes is not only suitable for various sensor network applications, but also applies to all the functions that satisfy the requirements of OSEK, a real-time operating system standard for intelligent automobiles, so that even for intelligent automobiles using low-cost CPUs. It can be utilized.

While the present invention has been described as a preferred embodiment, the present invention is not limited thereto, and various modifications can be made without departing from the gist of the invention.

1 is a diagram illustrating an OSEK operating system task state model;

2 is a diagram illustrating OSEK operating system task scheduling;

3 is an operating system architecture diagram for an OSEK-based sensor node according to the present invention;

4 is a kernel structure diagram having three processing levels according to the present invention;

5 is a diagram illustrating a waiting queue for task management according to the present invention;

6 is an interrupt service routine structure diagram for a low-cost MCU according to the present invention;

7 is a diagram illustrating a software update manager according to the present invention.

Claims (3)

A stable sensor node operating system 10 suitable for a sensor network application environment while complying with an intelligent operating system standard defined in OSEK; A kernel 20 which is divided into interrupt, scheduler, and processing levels of a task, and all services or objects within each level have a priority, and sizes and functions of the objects are determined according to Conformance Classes (CCs); A high speed ISP (In-System-Programming) module 30 inserted into the kernel 20; Operating system and software update system for OSEK-based sensor nodes, characterized in that consisting of the update manager 40 of the GUI environment running on the host PC. The OSEK-based sensor node operating system and software update system of claim 1, wherein the kernel 20 stores and manages a state of each task using a task control block (TCB). The OSB-based sensor node of claim 2, wherein the TCB stores stack related information for context exchange between tasks, task thread function pointers, priority, task status, and the like. Operating system and software update system.

Images