Small Operating System Research Articles

M2OS for Arduino Uno

This paper presents the current status of the porting of M2OS to the Arduino Uno board. M2OS is a small realtime operating system targeted to microcontrollers with very tight memory constraints. M2OS provides support for a simple Ada tasking model based on nonpreemptive one-shot tasks. The paper puts special emphasis on the adaptation of the standard Arduino core library to be used by Ada applications running on M2OS.

An interactive and dynamic scratchpad memory management strategy for multi-core processors

An interactive and dynamic Scratchpad memory (Scratchpad) management approach is proposed in this research manuscript to target multi-core processors. By using MMU an integrated (memory management unit), it can be useful for an existing embedded system that maps into a virtual space the physically addressed Scratchpad memory. A hardware Unit MRSU (Memory Reference Sampling Unit) is introduced depend on mass-count disparity, with a very low probability that models the memory reference data stream. One of the memory addresses is considered as a captured address that is present in a repeatedly referenced memory segment. MRSU generated a hardware interference and the captured / identified repeatedly accessed memory block is placed, through the software, into the Scratchpad space. The page table is also modified by the software so that the Scratchpad memory data block will be forwarded by the follow-up memory accesses. In multi-core processor for Scratchpad management, this proposed strategy is specifically adequate without depending on profiling information and compiler. By profiling or static analysis, the memory accesses behaviour cannot be guessed and a RTOS (Real-Time Operating System) is mostly presented in such an environment. By executing numerous operations on a small Real-Time Operating System the proposed Scratchpad allocation strategy is evaluated with preemptive scheduling. In contrast with a referenced cache-only system with just 1% performance degradation at runtime, in terms of energy consumption on average, this proposed method can achieve an 11% reduction which can be observed in experimental results.

Vision, Challenges and Future Perspectives of Low Constrained Devices IOT Operating Systems: A Systematic Mapping Review

Now the far-fetched reality has become true with the prominence of IOT (Internet of Things) technology. Various individual devices get connected with each other to establish communication. These devices are built on a microcontroller which is responsible to receive and send information. These devices are very small and appropriate Operating Systems are required on the basis of particular device architecture, scheduling methods, network technologies and programming models. IOT Operating Systems are enormously facilitating low constrained devices to deliver their throughput efficiently in a timely manner. This concept helped a lot in emergence of IOT, which has translated our physical world into a digital cyber world. IOT devices consumes less power, less memory and less energy, therefore they need appropriate Operating Systems to act as interfaces. Low constrained Operating Systems are especially designed to provide support to these low constrained devices. Many researches have been conducted to discuss Operating Systems for these low constrained devices. In this study, capsulization of Internet of Things and its building blocks, architecture of IOT Operating System and network stack architecture of state-of -the art IOT Operating Systems such as Contiki, Tiny OS, Free RTOS, RIOT, Zephyr and Mbed OS is investigated. Moreover this, detailed overview of related work is presented with the comparative analysis of this study with the existing surveys. In addition, open research areas are discussed with recommendations.

Vision, Challenges and Future Perspectives of Low Constrained Devices IOT Operating Systems: A Systematic Mapping Review

Now the far-fetched reality has become true with the prominence of IOT (Internet of Things) technology. Various individual devices get connected with each other to establish communication. These devices are built on a microcontroller which is responsible to receive and send information. These devices are very small and appropriate Operating Systems are required on the basis of particular device architecture, scheduling methods, network technologies and programming models. IOT Operating Systems are enormously facilitating low constrained devices to deliver their throughput efficiently in a timely manner. This concept helped a lot in emergence of IOT, which has translated our physical world into a digital cyber world. IOT devices consumes less power, less memory and less energy, therefore they need appropriate Operating Systems to act as interfaces. Low constrained Operating Systems are especially designed to provide support to these low constrained devices. Many researches have been conducted to discuss Operating Systems for these low constrained devices. In this study, capsulization of Internet of Things and its building blocks, architecture of IOT Operating System and network stack architecture of state-of -the art IOT Operating Systems such as Contiki, Tiny OS, Free RTOS, RIOT, Zephyr and Mbed OS is investigated. Moreover this, detailed overview of related work is presented with the comparative analysis of this study with the existing surveys. In addition, open research areas are discussed with recommendations.

Priority Inheritance Protocol Proved Correct

In real-time systems with threads, resource locking and priority scheduling, one faces the problem of Priority Inversion. This problem can make the behaviour of threads unpredictable and the resulting bugs can be hard to find. The Priority Inheritance Protocol is one solution implemented in many systems for solving this problem, but the correctness of this solution has never been formally verified in a theorem prover. As already pointed out in the literature, the original informal investigation of the Property Inheritance Protocol presents a correctness “proof” for an incorrect algorithm. In this paper we fix the problem of this proof by making all notions precise and implementing a variant of a solution proposed earlier. We also generalise the scheduling problem to the practically relevant case where critical sections can overlap. Our formalisation in Isabelle/HOL is based on Paulson’s inductive approach to protocol verification. The formalisation not only uncovers facts overlooked in the literature, but also helps with an efficient implementation of this protocol. Earlier implementations were criticised as too inefficient. Our implementation builds on top of the small PINTOS operating system used for teaching.

DiVM: Model checking with [formula omitted] and graph memory

In this paper, we introduce the concept of a virtual machine with graph-organised memory as a versatile backend for both explicit-state and abstraction-driven verification of software. Our virtual machine uses the LLVM IR as its instruction set, enriched with a small set of hypercalls. We show that the provided hypercalls are sufficient to implement a small operating system, which can then be linked with applications to provide a POSIX-compatible verification environment. Finally, we demonstrate the viability of the approach through a comparison with a more traditionally-designed LLVM model checker.

A Survey on Resource Management in IoT Operating Systems

Recently, the Internet of Things (IoT) concept has attracted a lot of attention due to its capability to translate our physical world into a digital cyber world with meaningful information. The IoT devices are smaller in size, sheer in number, contain less memory, use less energy, and have more computational capabilities. These scarce resources for IoT devices are powered by small operating systems (OSs) that are specially designed to support the IoT devices’ diverse applications and operational requirements. These IoT OSs are responsible for managing the constrained resources of IoT devices efficiently and in a timely manner. In this paper, discussions on IoT devices and OS resource management are provided. In detail, the resource management mechanisms of the state-of-the-art IoT OSs, such as Contiki, TinyOS, and FreeRTOS, are investigated. The different dimensions of their resource management approaches (including process management, memory management, energy management, communication management, and file management) are studied, and their advantages and limitations are highlighted.

The nesC language

We present nesC, a programming language for networked embedded systems that represent a new design space for application developers. An example of a networked embedded system is a sensor network, which consists of (potentially) thousands of tiny, lowpower "motes," each of which execute concurrent, reactive programs that must operate with severe memory and power constraints. nesC's contribution is to support the special needs of this domain by exposing a programming model that incorporates event-driven execution, a flexible concurrency model, and component-oriented application design. Restrictions on the programming model allow the nesC compiler to perform whole-program analyses, including data-race detection (which improves reliability) and aggressive function inlining (which reduces resource consumption). nesC has been used to implement TinyOS, a small operating system for sensor networks, as well as several significant sensor applications. nesC and TinyOS have been adopted by a large number of sensor network research groups, and our experience and evaluation of the language shows that it is effective at supporting the complex, concurrent programming style demanded by this new class of deeply networked systems.

Safe and automatic live update for operating systems

Increasingly many systems have to run all the time with no downtime allowed. Consider, for example, systems controlling electric power plants and e-banking servers. Nevertheless, security patches and a constant stream of new operating system versions need to be deployed without stopping running programs. These factors naturally lead to a pressing demand for live update---upgrading all or parts of the operating system without rebooting. Unfortunately, existing solutions require significant manual intervention and thus work reliably only for small operating system patches. In this paper, we describe an automated system for live update that can safely and automatically handle major upgrades without rebooting. We have implemented our ideas in Proteos, a new research OS designed with live update in mind. Proteos relies on system support and nonintrusive instrumentation to handle even very complex updates with minimal manual effort. The key novelty is the idea of state quiescence , which allows updates to happen only in safe and predictable system states. A second novelty is the ability to automatically perform transactional live updates at the process level , ensuring a safe and stable update process. Unlike prior solutions, Proteos supports automated state transfer, state checking, and hot rollback . We have evaluated Proteos on 50 real updates and on novel live update scenarios. The results show that our techniques can effectively support both simple and complex updates, while outperforming prior solutions in terms of flexibility, security, reliability, and stability of the update process.

Safe and automatic live update for operating systems

Increasingly many systems have to run all the time with no downtime allowed. Consider, for example, systems controlling electric power plants and e-banking servers. Nevertheless, security patches and a constant stream of new operating system versions need to be deployed without stopping running programs. These factors naturally lead to a pressing demand for live update---upgrading all or parts of the operating system without rebooting. Unfortunately, existing solutions require significant manual intervention and thus work reliably only for small operating system patches. In this paper, we describe an automated system for live update that can safely and automatically handle major upgrades without rebooting. We have implemented our ideas in Proteos, a new research OS designed with live update in mind. Proteos relies on system support and nonintrusive instrumentation to handle even very complex updates with minimal manual effort. The key novelty is the idea of state quiescence , which allows updates to happen only in safe and predictable system states. A second novelty is the ability to automatically perform transactional live updates at the process level , ensuring a safe and stable update process. Unlike prior solutions, Proteos supports automated state transfer, state checking, and hot rollback . We have evaluated Proteos on 50 real updates and on novel live update scenarios. The results show that our techniques can effectively support both simple and complex updates, while outperforming prior solutions in terms of flexibility, security, reliability, and stability of the update process.

TinyOS에서의 선점적 EDF 스케줄링 알고리즘 설계 및 구현

A sensor network is a special network that makes physical data sensed by sensor nodes and manages the data. The sensor network is a technology that can apply to many parts of field. It is very important to transmit the data to a user at real-time. The core of the sensor network is a sensor node and small operating system that works in the node. TinyOS developed by UC Berkeley is a sensor network operating system that used many parts of field. It is event-driven and component-based operating system. Basically, it uses non-preemptive scheduler. If an urgent task needs to be executed right away while another task is running, the urgent one must wait until another one is finished. Because of that property, it is hard to guarantee real-time requirement in TinyOS. According to recent study, Priority Level Scheduler, which can let one task preempt another task, was proposed in order to have fast response in TinyOS. It has restrictively 5 priorities, so a higher priority task can preempt a lower priority task. Therefore, this paper suggests Preemptive EDF(Earliest Deadline First) Scheduler that guarantees a real-time requirement and reduces average respond time of user tasks in TinyOS.

The nesC language

We present nesC , a programming language for networked embedded systems that represent a new design space for application developers. An example of a networked embedded system is a sensor network, which consists of (potentially) thousands of tiny, low-power "motes," each of which execute concurrent, reactive programs that must operate with severe memory and power constraints.nesC's contribution is to support the special needs of this domain by exposing a programming model that incorporates event-driven execution, a flexible concurrency model, and component-oriented application design. Restrictions on the programming model allow the nesC compiler to perform whole-program analyses, including data-race detection (which improves reliability) and aggressive function inlining (which reduces resource consumption).nesC has been used to implement TinyOS, a small operating system for sensor networks, as well as several significant sensor applications. nesC and TinyOS have been adopted by a large number of sensor network research groups, and our experience and evaluation of the language shows that it is effective at supporting the complex, concurrent programming style demanded by this new class of deeply networked systems.

Architecture and design of NX-2700: a programmable single-chip HDTV all-format-decode-and-display processor

This paper describes the architecture, functionality, and design of NX-2700, a digital television and media processor chip from Philips Semiconductors. The NX-2700 is the second generation of an architectural family of programmable multimedia processors targeted at the digital television (DTV) markets, including the United States Advanced Television Systems Committee (ATSC) DTV-standard-based applications. The chip not only supports all of the 18 ATSC formats from standard-definition to wide-angle, high-definition video, but has also the power to handle high-definition television (HDTV) video and audio source decoding (high-level MPEG-5 AC-3 and ProLogic audio, closed captioning, etc.) as well as the flexibility to process advanced interactive services. NX-2700 is a programmable processor with a very powerful, general-purpose very long instruction word (VLIW) central processing unit (CPU) core that implements many nontrivial multimedia algorithms, coordinates all on-chip activities, and runs a small real-time operating system. The CPU core, aided by an array of peripheral devices (multimedia coprocessors and input-output units) and high-performance buses, facilitates concurrent processing of audio, video, graphics, and communication-data.

O.S. bridge between academia and reality

This paper presents a different approach to solving the dilemma of balancing the theory and the practice in an undergraduate operating systems course. We are in the process of implementing a laboratory that allows students to experiment with a copy of the 386BSD Unix System. Students are guided through exercises with increasing complexity, from a single exercise of initializing a new file system to more complicated team projects. The laboratory does not require a set of machines dedicated to the Operating Systems Class which is the reason many instructors choose to use simulators or small academic operating systems. This is accomplished through the use of recent removable disk technology that provides enough speed and capacity to load the source code of a real system. This approach provides a more in-depth study of a system students are more likely to encounter when they leave school. It also allows students to work in teams in an environment closer to the real world and provides a strong foundation for students wishing to enter graduate school with intentions to specialize in the area of operating systems development.

The use of name spaces in Plan 9

Plan 9 is a distributed system built at the Computing Sciences Research Center of AT&T Bell Laboratories over the last few years. Its goal is to provide a production-quality system for software development and general computation using heterogeneous hardware and minimal software. A Plan 9 system comprises CPU and file servers in a central location connected together by fast networks. Slower networks fan out to workstation-class machines that serve as user terminals. Plan 9 argues that given a few carefully implemented abstractions it is possible to produce a small operating system that provides support for the largest systems on a variety of architectures and networks. The foundations of the system are built on two ideas: a per-process name space and a simple message-oriented file system protocol.

The Bubble Operating System: a control extension to data flow diagram

The authors describe a control system extension method for software specification and design using the structured analysis for real time (SA/RT) technique. The proposed method makes possible a computer-aided transition from SA/RT models to code. Simultaneously, it makes it obligatory and easy for software designers to create and maintain documentation at the SA/RT level during the whole life cycle of the system. This binding is carried out with a small real-time operating system concept called BOSS (Bubble Operating System of Salora). >

Kit and the short stack

Kit is a small multi-tasking operating system kernel written in the machine language of a uni-processor von Neumann computer. The kernel is proved to implement on this shared computer a fixed number of conceptually distributed communicating processes. In addition to implementing processes, the kernel provides the following verified services: process scheduling, error handling, message passing, and an interface to asynchronous devices. We summarize the Kit project in order to discuss the place Kit could occupy in the verified stack of system components containing Micro-Gypsy, Piton and FM8502.

Kit: a study in operating system verification

The author reviews Kit, a small multitasking operating system kernel written in the machine language of a uniprocessor von Neumann computer. The kernel is proved to implement on this shared computer a fixed number of conceptually distributed communicating processes. In addition to implementing processes, the kernel provides the following verified services: process scheduling, error handling, message passing, and an interface to asynchronous devices. As a by-product of the correctness proof, security-related results such as the protection of the kernel from tasks and the inability of tasks to enter supervisor mode are proved. The problem is stated in the Boyer-Moore logic, and the proof is mechanically checked with the Boyer-Moore theorem prover.< <ETX xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">&gt;</ETX>

The limits of correctness

On October 5, 19601, the American Ballistic Missile Early–Warning System station at Thule, Greenland, indicated a large contingent of Soviet missiles headed towards the United States2. Fortunately, common sense prevailed at the informal threat–assessment conference that was immediately convened: international tensions weren’t particularly high at the time. The system had only recently been installed. Kruschev was in New York, and all in all a massive Soviet attack seemed very unlikely. As a result no devastating counter–attack was launched. What was the problem? The moon had risen, and was reflecting radar signals back to earth. Needless to say, this lunar reflection hadn’t been predicted by the system’s designers. Over the last ten years, the Defense Department has spent many millions of dollars on a new computer technology called “program verification” a branch of computer science whose business, in its own terms, is to “prove programs correct”. Program verification has been studied in theoretical computer science departments since a few seminal papers in the 1960s3, but it has only recently started to gain in public visibility, and to be applied to real world problems. General Electric, to consider just one example, has initiated verification projects in their own laboratories: they would like to prove that the programs used in their latest computer–controlled washing machines won’t have any “bugs” (even one serious one can destroy their profit margin)4. Although it used to be that only the simplest programs could be “proven correct” — programs to put simple lists into order, to compute simple arithmetic functions –slow but steady progress has been made in extending the range of verification techniques. Recent papers have reported correctness proofs for somewhat more complex programs, including small operating systems, compilers, and other material of modern system design. 5 What, we do well to ask, does this new technology mean? How good are we at it? For example, if the 1960 warning system had been proven correct (which it was not), could we have avoided the problem with the moon? If it were possible to prove that the programs being written to control automatic launch–on–warning systems were correct, would that mean there could not be a catastrophic accident? In systems now being proposed computers will make launching decisions in a matter of seconds, with no time for any human intervention (let alone for musings about

Small operating systems for the 1990s

In the course of 24 years' association with computers, I have seen the rise and fall of several alternate ways of looking at operating systems.