Strategies for real time system specification

Abstract- an operating system for creating real

The development of high-quality real-time time applications.

systems depends on their correct

In real time the correctness of the
requirements specification, which includes
application depends on the logical
the analysis and specification of timing
correctness and the time of execution. i.e. It
issues. This paper focuses on requirements
is time critical. The output must be produced
specification of real-time systems,
within the dead-line specified. Such real
presenting a set of temporal parameters and
time systems are called hard real time
timing-constraints related to the execution of
systems. In such systems the delayed results
systems processes. Timing-constraints are
may cause in a catastrophy. There are other
expressed by formulas, being useful for
real time systems called soft real time,
defining, representing, and validating the
which can tolerate the delay in results, but
system temporal behavior, particularly in
will result in poor quality outputs. A key
hard real-time systems specifications. The
characteristic of a real-time OS is the level
primary contribution over previous studies is
of its consijo stency concerning the amount
the proposal of a more generic and complete
of time it takes to accept and complete an
set of timing-constraints, applied to the area
application's task; the variability is jitter. A
of requirements engineering for real-time
hard real-time operating system has less
systems, which has not been sufficiently
jitter than a soft real-time operating system.
explored.
The chief design goal is not high throughput,
but rather a guarantee of a soft or hard
INTRODUCTION-
performance category. A real-time OS that
Real-time operating system - A Real can usually or generally meet a deadline is a
Time Operating System or RTOS is soft real-time OS, but if it can meet a
deadline deterministically it is a hard real- tasks and with interrupt service
time OS. routines.

A real-time OS has an advanced algorithm Priority Based

for scheduling. Scheduler flexibility enables
• Tasks are implemented as light-
a wider, computer-system orchestration of
weight threads assigned a priority at
process priorities, but a real-time OS is more
time of creation.
frequently dedicated to a narrow set of
• Task priorities can be dynamically
applications. Key factors in a real-time OS
changed with OsSetTaskPri(). The
are minimal interrupt latency and minimal
new priority takes effect
thread switching latency, but a real-time OS
immediately. Tasks pending in a
is valued more for how quickly or how
priority queue are dynamically re-
predictably it can respond than for the
ordered in the queue.
amount of work it can perform in a given
• A task's priority is temporarily
period of time.
boosted when holding ownership of
a mutex being requested by a higher
priority task (priority inheritance).

FEATURES-
Task synchronization and communication
Multitasking, preemptive, re-entrant
kernel • Semaphores and queues perform
either priority or FIFO scheduling of
• Supports implementing real-time
pending tasks. Semaphores are
applications as multiple semi-
counting semaphores. Message
autonomous tasks. Tasks are always
queues have either a fixed maximum
in one of five states: running, ready,
size or grow freely, limited only by
blocked, suspended, or delayed.
the amount of available memory.
• Provides for task communication and
• Mutexes operate like binary
synchronization, both with other
semaphores with ownership and
 priority inheritance to avoid the get identifier calls which are
problem of priority inversion. infrequent operations.
• Events can make multiple tasks
Responsive
ready with a single system call.
Events are posted to a nexus which
• Timer-related processing that is
may contain any number of blocked
variant, such as sorting the timer
tasks. Tasks waiting for an event use
queue, is performed in the
a 32-bit mask to select which events
background using kernel tasks.
they respond to.
Minimal work is performed up front
• Timers can be used in a wide variety
when a system call requires timer
of system calls. Semaphores,
processing, allowing the CPU to
messages, and events can be posted
return more quickly to the
after a fixed delay or posted
application.
repeatedly at fixed intervals.
Application functions can be called Flexible Scheduler
after a fixed delay, or called
• The scheduler can be configured as
repeatedly at fixed intervals. Timers
non-preemptive, a requirement for
can be stopped, tested for expiration,
some third-party communication
and/or deleted at any time.
protocol stacks. When non-
preemptive, running tasks always
keep the CPU until making a service
Deterministic
call that blocks.
• If configured as preemptive, the
• Interrupt latency does not increase as
scheduler always runs the highest
the number of tasks, semaphores,
priority ready task. The running task
queues, etc., increase.
is preempted whenever an interrupt
• The execution time of every service
makes ready a task with higher
call is independent of the number of
priority than the currently running
tasks, queues, semaphores, etc., in
task.
the system, except for the delete and
 • Preemption can be temporarily • IsrCreate() creates an entry in the
disabled with OsLockTask(). CPU's vector table and installs
Preemption is re-enabled by either "wrapper" routines that save and
calling OsUnlockTask(), or by restore the minimal registers required
making a service call that blocks. to allow the service routine to be
• Tasks may be configured for round written in C.
robin scheduling among tasks of the • The CPU vector table is initialized at
same priority. The time slice value is startup with default vectors that
configurable and may be examined allow bus errors and spurious
or modified at any time. interrupts to be reported on the stderr
console.
Easy to Use
Command Line Debug Monitor
• A compile-time option promotes all
service call errors to fatal errors that • Displays the percent of CPU time
cause an error message on stderr and used by each task and ISR. Displays
a break into the debug monitor. This the stack low water mark for each
helps catch simple programming task. Displays a log of past system
errors that can otherwise waste calls including the time of the call,
valuable time. the name of the task or ISR making
• Kernel objects (tasks, semaphores, the call, and the values of the
queues, mutexes, nexuses, timers) parameters used. Allows interactive
are created dynamically upon request querying of the state of each task,
by the application. There is no semaphore, etc.
configuration file to edit and • Application programs, device
maintain as the application grows. drivers, etc. can extend the monitor
The only limit is the amount of by adding name strings and code for
available memory. additional commands.

Interrupt Service Routine Manager Integrated Development Environment

 • Integrated with TargetTools™, the consisting of modes & requirements,
potential implementations, and
IDE for embedded development
resource sets. The task of the design
from Blunk Microsystems with an tools is to assist the designer in
integrated compiler and kernel-aware selecting appropriate combinations of
implementations and resource
debugger, visual code editor, search assignments for all of the desired
and replace tool, BDM for board operational modes. Given the
flexibility in defining design
bring-up, and fast Ethernet
alternatives, this space can be
download. extremely large (moderately sized
design examples have defined a space
Turnkey Solution of 1024th).

• Provided with source code, default

compiler settings, linker command
files, project files, and a re-entrant
Standard C runtime library.
• Blunk Microsystems provides board
support packages for a range of
commercial CPU boards and
provides competitive bids on board
Figure 8: Design Flow in the ACS Model Integrated Design
support packages for custom designs. Environment

Royalty Free-Includes source code, User's

manual, sample applications, and one year
of technical support.

Practical example of real time

system
i.e how it is designed in an a.c
2nd practical example:-
How it is used in multi aspect
The end product of the design process
described above is a design space
model
 the behavior models is translated
to a C-based state machine
representation. The states in this
state
b) machine contain links to the
configuration files
(hardware/software). The
configuration manager executes
transitions in the state machine by
reconfiguring the system with the
appropriate configurations.
c) Hardware synthesis: For the
configurable devices in the
Figure 9: Multi-aspect graphical network, VHDL descriptions are
Models generated. The VHDL design
incorporates computational
components from the design library
To deal with such large spaces we glued together using components
from a standard interface runtime
have incorporated a multi-stage multi-
library. The VHDL specifications
resolution design analysis in the are compiled using vendor-
environment that starts with a large supplied/COTS compilers and
number of design alternatives and device specific Place-and-Route
progressively refines the design space tools to configuration specifications
to a small set of best choices. As the for the device.
number of designs under evaluation is d) Software Synthesis: For the
reduced, the resolution of the general-purpose processors in the
analysis/estimation increases to get network, software architecture
specifications are generated.
more accurate performance
These specifications provide the
information. information needed by the low-
level operating system to enact the
a) The first stage of the analysis is an desired computational behavior.
Ordered Binary Decision Diagrams Specifications include software load
(OBDD) [11] based analytical tool modules, real-time schedules,
that symbolically evaluates the communication maps, and
design space against the user- interfaces between software and
defined constraints. The principal hardware modules. The result of
benefit of a symbolic evaluation is the synthesis and post processing
that it does not require is a complete executable system,
enumeration of the design space, ready for deployment. The
which could be prohibitively deployment is performed in concert
expensive given the size of the with the Runtime Environment.
space. The constraints can be
selectively applied in this tool to e) B. Runtime Environment
eliminate the designs that fail to f) The Runtime Environment is
meet the system requirements,
thereby pruning the design space. designed such that it can be easily
Configuration manager synthesis: synthesized from the high-level
The adaptive behavior described in model-integrated design
 environment. The concepts, solving) the problems associated
properties and interfaces of the with dynamic reconfiguration.
runtime environment are made
compatible with the design
representation and synthesis
approach. Capabilities and This synchronization and control of a
interfaces are tuned to simplify the system during reconfiguration is the
generator. responsibility of the Configuration
Manager. The CM contains tables
g) The semantics of the execution capturing the behavioral state
environment implement a large- machine that defines the transitions at
grain-dataflow architecture. The which reconfiguration is to occur. Tied
Worker Function captures the tasks to these state-based descriptions is
that are performed by the system. the information necessary to configure
Communication nodes capture the the hardware and software
transfer of data between workers. components of the system. Given this
Computations can be described as information, the Configuration
a bipartite graph, where workers Manager serves as a system observer.
connect to Comm nodes, and The CM monitors relevant signals, as
Comm nodes connect to workers defined in the transitions leading out
(Figure 10). At this level, there are of the current state. When the logical
no implied semantics of the conditions for a state transition are
workers. The execution properties satisfied, the Configuration Manager
of workers (data tokens begins the structural transition
produced/consumed per execution, process.
timing of execution, etc) are
Asynchronous
maintained at a higher level. The Communication
Buffer
semantics of the Comm units are Comm
Worker
Comm
function
asynchronous queues.
Software Hardware
h) The execution environment spans
software and reconfigurable SW Process HW Process
Stream Stream FIFO FIFO
hardware. The software
environment consists of a simple, Queue in Hardware
portable real-time kernel with a kernel FIFO

run-time-configurable process
schedules, communication
schedule, and memory
management [13].
Communications interfaces are
supported within the kernel,
making cross-processor
connections invisible. Memory
management is integrated with the
scheduler and communication
subsystems, enabling (but not
Variations on a Real-Time Software
Design Course using ObjecTime
The variations that are possible in a course
on real-time software design are enormous.
In this paper, we discuss the variations we
have introduced within the past year in the
undergraduate real-time systems design
course at RMC. Our objective in the course
is to give the students an understanding of
how to approach real-time software design
by giving them an opportunity to do some
design
2. 1995/96 version of the course
The starting point for the variations was the
1995/96 version of the course:
i. Introduction to real-time systems,
review of operating systems concepts, and
overview of x86 architecture in order to
conduct the context switching lab.
ii. Real-Time Structured Analysis and
Design (RTSAD)
iii. ROOM methodology and ObjecTime
toolset.
iv. Software Cost Reduction (SCR)
notation developed at the Naval Research
Laboratory for precise, reviewable
specification of software requirements, and
an alarm clock example
v. Schedulability issues, and Rate
Monotonic Analysis in particular.This
section is important, not least because
ObjecTime provides essentially no support
for timing and schedulability analysis,
although there is some recent research that
may eventually lead to such support.
4. Variations in 1996/97
The two main variations were between the
course as taught in English, and the course
as taught in French. We will refer to them as
versions 1 and 2, respectively. The main
differences in approach for 1996/97 were:
The major choice was between emphasizing
high level design issues versus a deeper
understanding of the complexity inherent in
how real-time software interacts with its
environment. In version 1 of the course, the
emphasis was put on the transition from
requirements to design, while in version 2, it
was on the transition from design to
implementation.
References
[1] Bran Selic, Garth Gullekson and Paul
Ward, Real-Time Object-Oriented
Modelling, J. Wiley, 1994
[2] ObjecTime and MicroRTS manuals,
ObjecTime, Kanata, Ontario, 1997

[3] Terry Shepard, Colin Wortley, and

Bran Selic, "Using ObjecTime to Teach
Real-Time Software in the
Undergraduate Curriculum", Real-Time
Systems Education, Ed. J. Zalewski,
IEEE Computer Society Press, 1996, pp.
26-35

[4] Derek J. Hatley, and Pirbhai, I.A.,

Strategies for Real-Time System
Specification, Dorset House, 1987

[5] Paul T. Ward, and Mellor, S.J.,

Structured Development for Real-Time
Systems, Volumes 1, 2 & 3, Yourdon
Press, 1985