Index Real-Time Magazine 99q4 on RTOS UPDATE 2

Index Real-Time Magazine 4Q99

Editorial
By Martin Timmerman, Chief-Editor of Real-Time Magazine, Real-Time Consult.
RTOS UPDATE 2 - 99q4 - p. 3
.

RTOS EVALUATIONS

VxWorks/x86 5.3.1 evaluation
Following article is an executive summary of the evaluation report of VxWorks/x86 5.3.1 from WindRiver
Systems, Inc.

By Martin Timmerman and Bart Van Beneden,
Director and Computer Engineer,
Real-Time Consult.
RTOS UPDATE 2 - 99q4 - p. 6
Back to top
.

RT-DOCTOR

Open Embedded System Strategies
ARC is a leading international market analysis and consulting firm focused exclusively on enterprise
applications and industrial automation. ARC provides strategic planning and technology assessment
services to suppliers, solution providers, and manufacturing companies around the world. In this contribution, ARC gives its viewpoint on open embedded systems strategies.

By Dick Caro, Bill Thompson, Marcus Goncalves,
Analysts, ARC Advisory Group.
RTOS UPDATE 2 - 99q4 - p. 10
Back to top
.

OSEK

A Modern Standard for Super-Small Kernels
OSEK/VDX is the specification for a real-time operating system originally intended for automotive control
processors, but much more generally applicable to deeply embedded processors in a wide spectrum of
applications. The OSEK/VDX standard includes software interfaces to the operating system, a tasking
model, and mechanisms for intertask communication and synchronization.

By Dr. David Kalinsky, Director of Customer Education, Integrated Systems, Inc.
RTOS UPDATE 2 - 99q4 - p. 22
Back to top

OSEK: a super-small kernel for
deeply embedded applications?
The OSEK/VDX specification was developed by a consortium of automotive companies and suppliers,
and has therefore sometimes been labeled as only being applicable to automotive applications. Although this label has been placed on OSEK, it is important to realize that the specification was designed to be applicable to a wide range of in-vehicle applications, and to efficiently target different word-length processors. In fact there are commercially available OSEK/VDX compliant operating systems available for a variety of 8, 16 and 32 bit microprocessors. The questions that will be addressed in this article are whether the specification is valid in other industries, and if so, for what types of applica-
tions? In order to answer these questions we need to restate the goals and the problems the specification is designed to solve.

By Marc Serughett, Marketing Manager,
Integrated Systems Inc.
RTOS UPDATE 2 - 99q4 - p. 25
Back to top
.

RTOS

Enhancing your system reliability with VRTX
The engineer who develops embedded software must master a sophisticated juggling act. Today's embedded systems include more functionality than ever before, but product development schedules shrink while quality, supportability, and performance expectations continue to rise. One way to balance these competing pressures is to adopt proven commercial off-the-shelf (COTS) software where possible. But that will only result in improved quality if the software is designed and developed to appropriate standards. This article addresses governmental safety certification standards and process, such as the US FAA. It also covers selected RTOS features (preemptibility, priority inheritance, memory protection) that help ensure system reliability.

By Linda Thompson, Product Line Manager,
Mentor Graphics Embedded Software Division.
RTOS UPDATE 2 - 99q4 - p. 28
Back to top

Driver Synthesis: Automating the Creation of BSPs
Everyone knows a BSP is needed for all high-end embedded design projects, but what exactly is a
BSP? What is involved in developing one? What means are available to accelerate the development of
a BSP? This article identifies the different types of BSPs, the issues a BSP has to handle, and describes
existing means to expedite the development of a BSP. This article also presents an emerging approach
to automate the creation of a BSP through driver synthesis.

By Shaul Gal-Oz, President & CEO,
Aisys Inc.
RTOS UPDATE 2 - 99q4 - p. 33
Back to top

Message Passing. Speed, Strength and Simplicity for Embedded Systems in Communications Applications
This article discusses the differences between message passing and mailboxes as used in inter-
process communication in a real-time operating system. The advantages of message passing as a
modular, easily handled, debugged and distributed system are highlighted.

By Bill McCombie, Manager of Third-Party Relationships,
Enea OSE Systems
RTOS UPDATE 2 - 99q4 - p. 38
Back to top

Missed it! - How Priority Inversion messes up real-time performance and how the Priority Ceiling Protocol puts it right.
In hard real-time systems it is important that everything runs on-time, every time. To do this efficiently it
is necessary to make sure urgent things are done before less urgent things. When code is developed
using a real-time operating system (RTOS) that offers pre-emptive scheduling, each task can be allocat-
ed a level of priority. The best way to set the priority of each task is according to the urgency of the
task: the most urgent task gets the highest priority (this ordering scheme is known as Deadline
Monotonic).

By N.J. Keeling, Director of Marketing,
Northern Real Time Applications (NRTA).
RTOS UPDATE 2 - 99q4 - p. 46
Back to top

Is Real-Time Linux for Real?
Microsoft's Windows NT and now Windows CE are typically at the forefront of discussions about real-
time operating systems for manufacturing. Much has been said and demonstrated about their applica-
tion in industrial settings, but many still look at these options with hesitation due to concerns about
deterministic operation. Linux is the latest operating system to enter this discussion, particularly given
the significant boost it enjoyed when Netscape recently announced its plans to support Linux. But is the
industry ready for it? Better yet, is Linux ready for IA?

By Marcus Goncalves, Analyst,
ARC Advisory Group.
RTOS UPDATE 2 - 99q4 - p. 51
Back to top

FAULT-TOLERANCE

Real-time Embedded Database Fault Tolerance on Two Single-board Computers
This document describes a generic arbiter written in C which is supplied as demonstration code, which
calls a function to determine whether the board on which it runs should be master. A dummy imple-
mentation of the function is provided, which would have to be replaced for use on an embedded sys-
tem. The architecture of the overall mechanism is as illustrated in figure 1.
Each arbiter task services the local JCP. The two arbiters do not communicate with each other, and yet,
due to the services provided by the system software (which itself will be relying on hardware mecha-
nisms), they are able to offer a reliable, distributed arbitration service to the JCPs. 'Reliable' here means
that one will not get a situation whereby both JCPs think their database should be master, except perhaps for a brief moment when a switchover occurs.

By Dr. Nigel Day, Technical Director, Polyhedra Plc,
Dave Morse, President, Polyhedra, Inc.
RTOS UPDATE 2 - 99q4 - p. 52
Back to top

TTPos - The Time-Triggered and Fault-Tolerant RTOS
In the embedded systems market, the importance of composability, dependability, and hard real-time
behavior is increasing steadily. At the same time, high volume markets demand substantial cost reduc-
tions. Conventional event-triggered solutions are not able to satisfy these requirements. The time-trig-
gered operating system TTPos™ combines a tiny footprint with very fast task switching. TTPos provides
time-triggered, priority based, cooperative preemptive scheduling; synchronization to a global time; error
detection and application modes. The TTPos kernel is augmented by the node design tool TTPbuild™.
TTPbuild supports the design of nodes participating in TTP ® clusters. Based on the node design,
TTPbuild automatically generates task schedules, the configuration for the operating system, and an
optimized fault-tolerance and communication layer.

By Christian Tanzer, Senior Software Architect,
and Martin Glück, Senior OS Designer,
TTTech.
RTOS UPDATE 2 - 99q4 - p. 61
Back to top

APPLICATION

A Real-Time Control Operating System
for Industrial Automation
MMS (Manufacturing Message Specification) is an international standard that concerns integration of
shop-floor devices such as numerically controlled (NC) machine tools, robots, programmable logic controllers (PLCs), and control computer systems. MMS introduces the concept of a Virtual Manufacturing Device (VMD) providing a common view of all physical devices. Wide spread use of MMS in industrial plants depends heavily on real-time support. This paper presents an approach to the implementation of an MMS server for shop-floor devices that takes into account real-time requirements. Our MMS server has a dynamically reconfigurable software architecture of a Real-Time Control Operating System (RTCOS). It is based on Microware's OS-9 real-time multitasking operating system kernel. In our framework, multiple reconfigurable control sub-systems represent multiple Virtual Manufacturing Devices
(VMD). The sub-systems can be developed independently of target driver devices. This paper focus on the software architecture of our Real-time Control Operating system MMS Server called RCOMS and
discusses the advantages of our approach compared to other MMS implementations.

By Brahim MAAREF, Laboratoire Système et Réseau, IMAG and Mohamed ABID, Ecole Nationale d'Ingénieurs de Sfax
RTOS UPDATE 2 - 99q4 - p. 65
Back to top

The Wireless Internet Phone, Defining the Need for a Resilient Software Foundation
The exploding wealth of immediateand digitized information on the Internet - news, quotes, market intel-
ligence, music and video - is defining new wireless and handheld applications, enabling a host of new
network-based mobility services. But the rapid evolution of the latest wireless Internet protocols creates
a mass of software taxing performance of digital pocket companion designs and challenges the execu-
tion embedded applications environment.

By Brian J Ramsey, Director, Communications Marketing, Lynx Real Time Systems Inc.
RTOS UPDATE 2 - 99q4 - p. 71
Back to top

PROJECT

Save time and money by using PC Technologies for embedded system development
Typical embedded and real-time system development is a multistep process that includes code programming, debugging, compiling, downloading, and deploying. Traditionally, these separate tasks are performed in separate environments rather than integrated with each other. But this often is a time intensive process that works against the ultimate goal when developing an embedded real-time system - reducing time-to-market. A definite way to save time is using versatile tools that are platform independent, tightly integrated and easy to use. They will save time, and thus money. In addition, code reuse will preserve capital investment over long periods of time. Traditional PC development environments have solved time-to-market problems and are now bringing rapid development tools to embedded systems.

By Jim Balent, Real-Time Systems Product Manager,
National Instruments.
RTOS UPDATE 2 - 99q4 - p. 73
Back to top

The new business imperative: achieving shorter development cycles while improving product quality
Most embedded software developers share a common assumption: productivity depends more on your tools than on your realtime operating system (RTOS). But even with the best tools, developers can spend significantly more effort on verification and maintenance than on creating new and innovative features for their products. The underlying problem? OS architecture. By their very nature, traditional OS architectures provide either no support, or limited support, for the memory management unit (MMU). As a result, an embedded software product can require extensive debugging and testing for even minor code changes. In this paper, we compare OS architectures and see how one approach, Universal Process Model (UPM™) architecture, helps developers redirect their efforts away from software integration and maintenance and back toward product innovation. Unlike other architectures, UPM allows
applications, drivers, protocol stacks, and even OS modules to run in their own memory-protected
address spaces. This approach not only eliminates needless debugging and testing, but also boosts
availability at run time. For example, a UPM-based system can recover from software faults without
rebooting and can support hot-swapping of both hardware and software, including most of the OS
itself.

By Paul N. Leroux, Technology Analyst,
QNX Software Systems Ltd.
RTOS UPDATE 2 - 99q4 - p. 76
Back to top

OTHERS

Bookreview
RTOS UPDATE 2 - 99q4 - p. 82

Agenda
RTOS UPDATE 2 - 99q4 - p. 83

Bookstores
RTOS UPDATE 2 - 99q4 - p. 84

Company Directory - RTOS Update 2
RTOS UPDATE 2 - 99q4 - p. 85

Subscription Form
RTOS UPDATE 2 - 99q4 - p. 89

Advertisement Index
RTOS UPDATE 2 - 99q4 - p. 90