SPECIAL FEATURE:

An Architecture for Real-

Time Softuare Systems
Theodore P. Baker, Florida State University
Gregory M. Scallon, Boeing Aerospace

The Rex approach to ex, an architecture for designing ings. In particular, the executive is not part
sofblar areal-time systems based on a oftheoperating system, even though it per-
programmable standard execu- forms some traditional operating system
views executives as tive, has evolved from a series of real-time functions.)
independently
-i
. .
systems in the aerospace industry. Rex's
software architecture is characterized by its
Key keyelement. The element of this
programmable view of the executive as an independently
hierarchy is the executive, which effectively
machines that exsecute programmable machine that executes defines the interfaces between the applica-
application
conventional-language ,tional procedures written in conven- tion and the operating system levels. A
programming languages as if they standard executive provides standard inter-
application proceaures were individual instructions of a higher faces for the other system components. Rex
as individual instruc- level program. plays this role.
tionXs of a higher4evel standard it provides
Becauseinterface a programmable
to compose application Some on
imposed ofthis specificreal-time
thestandard requirements
execu-
program. program components, the executive lets tive are
system designers program in the large. This * Physical processors can be added
approach also allows prediction of system without redesigning the applications
performance via prototyping and simula- software or executive.
tion at the executive level, reuse of software * Each procedural component is
components, flexible use of multiproces- executed in a static environment -
sors, and potential for automatic recovery that is, insulated from any changes in
from failures. system state that are not direct effects
A three-tiered view of real-time software of its own execution.
architecture underlies Rex. Figure 1 illus- * The executive automatically manages
trates this view, whose main software sys- the swapping of all nonresident mod-
tem components are ules (that is, blocks of information
Application. The application is specif- such as code and data).
ically designed to solve the user's problem. * The executive incorporates control
Executive. The executive provides func- options that automatically adapt
tions such as module interconnection, scheduling plans to dynamic loading
scheduling, and dynamic resource alloca- conditions.
tion via an interface independent of the * The executive is directly programmed
host hardware configuration. The imple- with explicit control parameters.
mentation of the executive may depend on * All synchronization is accomplished
the host but is independent of the applica- by the executive.
tion - and is thus reusable between appli-
cations on a single machine. Two levels. A basic premise of Rex is
Operatingsystem. The operating system that the activities of programming in the
provides lower level services to support the large - managing resources and intercon-
executive. The services provided are depen- necting components - should be sepa-
dent on the hardware confilguration. It is rated cleanly from the activities of
therefore specific to the host machine - programming in the small -programming
but not to the application. Like the execu- individual components. Viewed as a virtual
tive, it is reusable between applications on machine that treats application program
a single machine, components as defining individual instruc-
(The terms "4executive" and "operating tions, the executive accomplishes this sepa-
system" are used here with special mean- ration. Programming in the large is

50 0740-7459/86/0500/0050$01.00 © 19861IEEE IEEE SOFtWARE

concerned with producing a program in the
machine language of the executive, while
programming in the small is concerned
with extending its instruction set.
Figure 2 illustrates the separation of aplication * solves the user's problem
these two levels. Application procedures PP * is independent of hardware details
are coded in a conventional programming istandard terface
language and compiled into the machine *- schedules application processes
code of a physical machine. A plan for the allocates storage, manages nonresident
management of these procedures' execu- ~modules
tions to form a system is expressed in asep- d rd vn e
* dispatches tasks within processes
arate system-specification language, and is a Interace
separately translated into tables (agendas) operating * handles interrupts, provides services
used by the Rex virtual machine. These * manages hardware configuration
tables are in effect a high-level machine system * detects faults, recovers
code interpreted by the executive.
This machine architecture orientation
can be contrasted with that of other work hrwr.
on execution environments for real-time
software. Much of this work is oriented
toward programming languages (for exam-
ple, RTL/1,' Modula,2 Iliad,34 and Ada5).
Although Rex is designed to support a
high-level system-specification language - Figure 1. Real-time software architecture.
and can be viewed as defining a high-level
machine language - these languages are
independent from the language used to
program procedural components of the
application.
Other work is oriented toward develop- system specification
ing operating systems (for example, language conventional programming
Thoth,6 iRMX 86,' and VRTX8). Unlike language
these operating systems, which can be
viewed as providing a virtual machine for
the application program, Rex provides a | onary comp
virtual machine for the system specifi- p 4~\
cation. sch5dulS

The application er .escribe

d
. 3a k .
The application has three kinds of procedures
components: read and write
Procedural components (procedures). dispatches
These perform all the useful work. Each datlsets
instance of a procedure in a process is inSterpreted by dispatcheed as tasks by
called a task. alocates
Informational components (data sets).
These communicate data forward in time | . .
and between tasks.PE
Organizational components (processe). { executive
These specify the sequencing of tasks and t
theThe
interconnection of tasks and data sets.
overall structure of an application
may be described in a system specification
language as a collection of data setsandtio
process specifications. The process s'peci-hadre .
fications refer to procedures coded sep- hr
arately in a conventional programming
language. A prototype of such a language,
Real, has been designed and implemented
for use with Rex as part of a simulation-
based design tool, FOSS.9 Figure 2. Programming and the Rex virtual machine.

May 1986 51
 Rex background from the data set. It may also write new
data into the datasetset. The procedure
Rex is a standard table-driven executive developed at Boeing Aerospace by Greg assumes the data Tan validudt
Scallon. It is the most recent descendant of a series of real-time executives developed assumes the data set contains valrd data
for projects in the aerospace industry. when the procedure starts and guarantees
Rex's ideas can be traced back to the AgPrep agenda preparation system developed the data set contains (possibly new) valid
by Duane Brown Associates for the NASA Apollo program and to IBM's System 360 data when the procedure is done.
operating system. Precursors include the executives of the NASA Apollo Range Corrupted. The procedure may read
Instrumentation Ship (1965-1970) and the US Army Safeguard ballistic missile defense from and write to the data set. When it is
projects (1970-72).
The Designating Optical Tracking system (1978) successfully uses a multiprocessor- finished, however, the data set may no
resident implementation of Rex. A simulated nonresident version has also been imple- longer contain valid data. This differs from
mented as part of an ongoing research program on design automation techniques for the disposition "modified" in that the
real-time software systems at Boeing Aerospace transformation applied to a modified
The goal of this research program is to devise and construct tools a designer can parameteriartof hed to a nton
use to produce complex real-time software for large-scale multiprocessor configura- parameter is part of the specified function
tions with shared memory and bulk backing storage that supports nonresident modules of the procedure, while any transformation
The research has focused on developing system specification techniques, performance applied to a corrupted data set is not
prediction tools, reusable components, and standard execution environments. guaranteed to conform to any specifi-
cation.
Further readings Each parameter also has a set of
J.A. Grupe and G. Scallon, "Functionally Oriented System Simulation for Computer-Aided Design constraints. Constraints are of the kind
of Software/Hardware systems," Proc. Ninth Annual Simulation Symp., Tampa, Florida, Mar. 1976, typically imposed by a data type in a pro-
pp. 225-240. gramming language. They include for
G. Scallon, 'Toward Computer-Aided Design of Real-Time systems," Proc. European Computer Conf. example,minternga sT e, dimenis,
on Software Systems Engineering, London, Sept. 1976, pp. 59-70. example, internal structure, dimensions,
J.A. Grupe and G. Scallon, "The FOSS User's Guide," Boeing Aerospace Report D18018617-Z Seattle and units.
G. Scallon, "Simulation for System Design," Texas Instruments Technical Report U1430-12, Proc- In addition to the formal parameters, a
ess Construction Documentation, Vol. 7. procedure may return a condition code.
G. Scallon, "Description of the Functionally Oriented System Simulation (FOSS) for Software/Hard- This is a value that can be used by the
ware Design," Boeing Aerospace Report D180-18617-1, Seattle
dispatcher to control subsequent dis-
patching via predefined sequence-control
tasks.
Since there are no global variables or
Please note that the use of defined terms each task) is viewed as an indivisible unit pointers, no side effects are permitted.
such as procedure, task, data set, and of work that, once started, is executed Because procedures are only invoked by the
process in this article is different from without interruption by any other task. dispatcher, aliasing (access to one data set
common usage elsewhere. In particular, Because they are not preemptible, proce- under different names) can also be
processes and tasks here should not be con- dures must be simple and have short, controlled. There can be no implicit
fused with "processes" in languages such bounded execution times. Execution times parameters because data may only be
as Mesa, Concurrent Pascal, and Modula, of some tasks can be longer if a separate contained in data sets, and data sets may
or with "tasks" in languages such as PL/I processor is reserved for fast-response only be accessed via formal parameters.
and Ada. Neither should data sets be con- processes. Data sets may not contain pointers to other
fused with notions like files, nor should Procedures, executed only as tasks, are data sets. These restrictions ensure that
procedures be confused with "proce- invoked by the executive. The flow of each procedure's effect is easily under-
dures" in any particular programming control between tasks is defined by the standable in terms of a transformation on
language. organizational components (processes) of explicit parameters.
the system. These are represented for the There are several other reasons to limit
Procedural components. Procedures executive by tables called agendas. Pro- procedures. One is to ensure they can be
transform data. For programming in the cedures can share code, and a single implemented efficiently. Concerns include
large, they are viewed as individual tasks. procedure may be executed concurrently as keeping down the cost of context switches
Like instructions of a machine architecture different tasks by different processors. and generating efficient code for the
(and the primitive constructs of a program- Procedures access all data through expli- procedures. Limitations on procedures
ming language), they are reusable cit parameters. The actual parameters also simplify prototyping and analytical
components. They may be used more than (data sets) of a procedure invocation (task) modeling of system designs. The restriction
once, both within a single application sys- are passed by reference. Each formal para- that procedures be reentrant and access all
tem and within different systems. meter has a specified disposition. These are data through explicit parameters makes
From an interface view, the transfor- New. The procedure writes new valid them sharable at the object code level.
mation performed by a procedure can be data into the data set. It does not expect These restrictions, together with the
abstractly specified as a relation between any valid data to be in the data set when it requirement that tasks not be preempted,
values of data before and after execution starts. reduce the need for explicit synchroni-
of the procedure. A particular procedure Unchanged. The procedure may read zation of accesses to shared data. They also
implements a particular algorithm to data from the data set. It assumes the data permit efficient dynamic linking of
achieve the specified transformation. set contains valid data. It does not write on procedures and efficient management of
The semantics of procedures are limited the data set. nonresident modules (that is, code and
in Rex. Each procedure invocation (that is, Modfifed. The procedure may read data data sets).

52 IEEE SOFTWARE
 Because all the modules required by a a process. Global data sets are used to task to access a short-term data set does so
procedure are known to the executive, they communicate between different processes with disposition "new.") By contrast,
can be guaranteed to be in memory before or between processes and the physical I/O long-term data sets (whether local or
the process invoking the procedure is of the operating system. global) are allocated storage individually.
readied for execution. Nonresident Explicitly specified locks are used to
modules may be located anywhere in mem- assure the integrity of global data sets. Organizational components. Processes
ory, since their actual addresses are There are several locking options: define the system-level structure of a
provided to the procedure at the time of No inhibit. The data set requires no particular application. They specify how
invocation via an argument list. explicit locking. The access algorithms are the resources of the system are managed to
Memory for local temporary data (data self-synchronizing (for example, circular accomplish the desired system perform-
that is accessed only by the procedure and buffers) or there is other design knowledge ance, including the order in which
that does not persist between invocations) that solves the data validity/control procedures are invoked to perform tasks
is allocated within a contiguous block problems. and how tasks are linked to data sets.
(such as a stack frame). The base address Inhibit concurrent writes. Only one task Unlike procedures, processes are not
of a corresponding block of scratch mem- at a time may be executed with disposition
ory is provided when the procedure is to write to the data set.
invoked. Inhibit access during write. No other
In a multiprocessor shared-memory task that accesses the data set (regardless Processes are run
configuration, Rex allocates a fixed block of disposition) may be executed repeatedlyatscheduled
of scratch memory to each processor,
allowing the maximum scratch space
concurrently with another task with
disposition to write.
repeatedlynatescheduled
times or in response to
needed by any task. Two forms of inhibit are provided: certain events.
More space-efficient strategies have Blocking wait. A task is dispatched from
been used for single-processor configur- some lower priority process. This has the
ations. In particular, the scratch space advantage of doing useful work while
required by each task may be treated as a waiting. ordinarily expected to be reusable between
local short-term data set and allocated Busy wait. The dispatcher idles (that is, different applications, since they embody
within the workspace of the process con- dispatches only higher priority processes) the particulars of their unique applica-
taining the task. until the lock is removed. This may provide tions.
faster response in some cases, such as when The executive runs a process by
Informational components. Data sets the lock is held by a task expected to finish interpreting a task list. Each task in the list
provide communication between tasks - soon, or when it is held by an I/O specifies the procedure that must be
between different tasks and between operation expected to finish very quickly. invoked to perform the task and the data
different executions of a single task. They Since a lock can only be held during a sets that must be linked to the formal
single task, the wait can never be longer parameters of the procedure.
than the execution time of a single The task list is one part of an agenda,
procedure. which is a table that describes a process.
Explicitly specified locks Local data sets do not require explicit Agendas have two other parts. One is the
are used to assure locks, since they are in effect automatically scheduling parameter list that provides
the integrity of provided with busy-wait locks through information needed by the scheduler, such
local data sets. intertask dependency codes. as the priority and period of the process.
In Rex, local data sets are further divided The other is the requirement list that
into short-term and long-term data sets. specifies resources required by the process,
Short-term data sets do not persist between such as special processors, code and data
are not expected to be reusable because executions of a process. They are all modules, and scratch memory. An agenda
they are typically designed for a particular allocated within one contiguous block of is produced by assembling a process
application. storage associated with the process they specification (as part of a system
A data set has a specified, limited size belong to. specification).
and a set of attributes. The size and This block, the workspace of the pro- Processes are run repeatedly at sche-
attributes must be compatible with the cess, is allocated dynamically to the process duled times or in response to certain events.
constraints of any formal parameter it is when it is triggered. Short-term data sets The task list of a process is divided into two
linked to. A data set may be designated as whose lifetimes do not overlap can be over- parts. The first part, or initialization, is
either a variable or a constant. If it is a con- lain within the workspace, conserving executed only once: the first time the proc-
stant, it may only be accessed as an memory. Because the lifetimes of short- ess is run. Whenever the process is triggered
un,hanged parameter. If it is a variable, it term data sets can be determined from the thereafter, only the rest of the task list is
may be accessed as a parameter with any dispositions of the parameters they are executed.
disposition. Other attributes describe linked to, this overlaying can be determined Processes come in two kinds: sporadic
features such as format, dimensionality, automatically by a high-level system and periodic. A sporadic process is to be
and structure of the data set's contents. assembler. triggered at unpredictable times, as may be
Data sets may be local or global. Local The high-level assembler also determines required by some random event. A periodic
data sets are used only to communicate which local data sets are short-term process is to be triggered at regular
between tasks within a single execution of according to how they are used. (The first intervals according to a specified period.

May 1986 53
 response to asynchronous events such as
hardware interrupts or software signals
passed on by the dispatcher as a direct
l l100 ms | | |effect of the execution of a scheduling task
in another process.
Periodic processes are triggered in
DS1 response to events that originate as
A ~ interrupts from hardware timers or clocks,
and represent the passage of time. The
scheduler ensures these interrupts arrive at
DSX the required times by controlling the
hardware devices that generate them and
tB ) .OS
- | | DSY by interpreting them when they arrive.
Each periodic process has a specified
period (the time interval in milliseconds)
until it is triggered. The period is used in
one of two ways, depending on whether it
is firm or stretchable. If it is firm, we have
DS2 next trigger time=
last trigger time + period
lndJ| C < (for example, the process is to be triggered
each second). If the period is stretchable,
we have
next trigger time =
Figure 3. A process with three tasks. last start of execution + period
(for example, there is to be one second
between runs of the process). With a
Figure 3 illustrates a process to be memory, it also must identify the set of stretchable period, the actual period
triggered every 100 ms. It consists of three processors that may execute a process. In between runs will increase with heavy load-
systems with bulk backing storage, mem-
tasks, appearing in the task list in the order ig as the delay between triggering of a
ABC. Task A reads from the global data set ory management involves swapping poe anthe actual trtgfexecuton
DSI and from the local data set DS Y, and modules between memory and backing increases.
writes to the local data set DSX. Task B storage.
reads from DSXand writes to DS Y. Thus Dispatching. The dispatcher assigns The resource allocator
A and B update DS Y using information processors to tasks of ready processes.
from DSl. Task C then reads from DS Y Each processor executes its own copy of the
he s ce aloro-
Whenever the scheduler triggers a pro-
and writes to the new global data set DS2. dispatcher, using one set of agendas in cess, it passes the process's identification
The data in DSI presumably originated shared memory. When the dispatcher code to the resource allocator. The resource
in another process, or from an operating reaches the end of an agenda's task list, or allocator then readies the corresponding
system I/O handler, and are no longer when the process is aborted, the dispatcher process for execution. This involves two
needed after they are read by A. The data terminates the process. functions: memory management and pro-
Cputs into DS2 presumably are consumed Figure 4 illustrates how these three cess allocation.
by another process or by an operating sys- components of the executive work together
tem I/O driver. All the data sets are long- and how the agendas provide information
all remory management and
loads all required modules (procedures and
term, except for DSX.
term exceptfor DSX. used by
used each component.
by each component. long-term data sets used by the tasks within
the process) not currently resident. It also
reserves a block of memory for the pro-
The executive The scheduler cess's workspace.
The execution of a process is under the The scheduler is responsible for As Rex is now implemented - this is not
control of the executive, which has several triggering processes. It is invoked whenever a property of the Rex virtual machine -
functions: an event that may trigger a process occurs. the memory manager monitors how each
Scheduling. The scheduler determines By consulting programmable tables, it current process is using its modules and
when processes are triggered. When a pro- determines which processes should be applies a load/unload strategy optimized
cess is triggered, it becomes eligible for triggered and passes them on to the to reduce disk activity and response time.
allocation of resources. resource allocator. The physical disk storage is organized to
Resource allocation. The resource Each process has an enable/disable flag. support this strategy.
allocator establishes and maintains aprior- The scheduler does not trigger processes Certain processes may be defined to
itized list of ready processes for use by the that are disabled. This allows simple have all required modules permanently
dispatcher. It also manages memory for a adaptation to changes such- as for recovery resident. Other individual modules may be
process's code, scratch space,-and data sets. from faults. defined to be permanently resident.
In multiprocessor systems with shared Sporadic processes are triggered in The process allocation function takes

54 IEEE SOFTWARE
over once a process's modules are all
available in memory. Process allocation
maps the new process onto the set of (passage oftirme other events
processors authorized to work on it. Each S EM .
process can be constrained to any subset of
the physical processors in the hardware scheduling
configuration.
Allocation to a set of processors means parameter X SCh Uler reuet
each prot*essor can perform any taskr
within a process. Process allocation thus
can be used to limit interprocessor
l.m
contention and allows, for example, a requirement resurc
processor to be dedicated to only fast- list aller.m
response processes. Tu i a p F
Process allocation concludes by adivising
dispatchers that the process is ready to be
executed. The resourceallocator does thisnlocation
by computing the dispatching importance tb ao s
for the process and inserting it into the t fte
ordered ready list, which the dispatcher
scans to select processes. The ready list
a
only changes when the resource allocator fsr dispatcher list
insertsa readygprocess orowhen a process i r i rr
completes execution and is removed from
the list.L
All required resources remiain allocated
until the process terminates. The resources
are released, and then become available for
reuse.
In Rex, workspaces are recovered
immediately, but, the actual recovery of
memory occupied by code and long-term
data sets is postponed until it is needed to
satisfy further requests. Thus, if a process Figure 4. Components of the executive.
is triggered again before the storage
occupied by modules it uses has been prcsocopeeatakItcosste tedsthigmotneofarcsss
reassigned, the process wil not need
fetch those modules back. Rex incor or-next task or te o task.
ete coesthe.
th ecu.Itgvnb h dispatching importancef
itprocess
ts
is
does this by scanning the r-eady list until it
ates strategies to reduce needless swapping priority
findseaadrcsitepoesossauhrzdprirtyatrhingge
+ more time
based on module size, usage rate, and
and whose next task is niot blocked. Thetdsathnpiprtne timpotne.
b coiedstatic for
Allhithertaskmoulenk s thente One virtue of this scheme is its adapta-
rovingaoeee. ak order of processes in the ready list governs
stob ingl sorage.v the dispatcher. bility. If all processes have equal priority,
Better timeperformancecan be achieved
by prefetching only the required modules
~~~~~dispatching reverts to first-in, first-out. If
at the orocess level rather than by ling Priority. As mentioned above, the grossly different priority values are
usinggbe
resource
viulm manager determines the order of assigned, it approximates fixed priority dis-
schemes. This policy is based on the processes in the ready list. It does this by patching but ensures against total starva-
assuptiotha proesse arenot arge computing a measure of dispatching tion of low-priority processes. This lets a
and that minimiizing delay is paramount. importance for each process and keeping system ride out short-term overloads.
In systems in which all code and data the ready list ordered by this ranking. This scheme has worked well in practice.
setsare ermaentl reiden, swppin is The dispatching importance of a Rex. The architecture readily permits other
nlot needed, and memory management is process is a function of two parameters. schemes, however. Moreover, because the
reduced to aissigning workspaces. If there~
One is the priority of the task; the other is calculation'of dispatching importance is
the length of delay. That is,
is sfficentemor, wokspaes my be only done when a process is triggered,
allocated statically at system generation. delay + priority =more complex schemes can be adopted
All intertask linkages then become static, dispatching importance. without increasing the dispatcher
imrproving efficiency. If there is only a Dlyidspthnaprcsishe overhead.
single processor, the resource allocator difelayc diptchine puroess
i ewen tisean the
need only enter the process in the ready list. diffeencea btrigered.Sn
the currenttimeadte Executive tasks. In addition to normal
timeit asri~red Sice he urrnt ime application tasks, which call for invoca-
c

The dispatcher is the same for all processes, and tions of procedures, a task list may contain
The dispatclher is invoked whenever a delay = current time - trigger time, special predefined tasks that control the
May 1986 5
executive's action. These tasks are inter- alternate control paths. This allows concatenation bit. If this bit is on for a
preted immediately by the dispatcher branching and looping to be implemented given task, the dispatcher must dispatch
rather than being dispatched as an appli- within a task list. A special sequence- the next task in the task list (on the same
cation. Rex supports several kinds of control task skips the initialization part of processor) as soon as the given task is
executive tasks: a task list after it has been executed once. complete - without preempting the
Synchronization. These tasks impose Scheduling. These tasks can interrogate processor.
constraints on the dispatching order within or change the values of scheduling
a single task list for a multiprocessor parameters such as priority, period, and Mutual exclusion. When tasks sharing
configuration. next trigger time. Other scheduling tasks access to data might be executed
Operating system service. These tasks can enable, disable, trigger, and abort a concurrently by different processors, the
can call for service from the operating sys- process. dispatcher must provide mutual exclusion
tem (such as initiate physical I/O on port To ensure that a sequence-control task between them.
n with buffer x). functions correctly, one must execute it If communication is between tasks
Sequence control. These can make the indivisibly with the preceding application within a single process, mutual exclusion
dispatcher deviate from its normal strict task. There may also be other situations may be enforced by static sequencing con-
sequential execution of the task list. Such where it is desirable to execute a sequence straints expressed in the task list. Such
tasks may use the condition code returned of tasks in the task list without constraints can be used to ensure that, if a
by the preceding task to decide among interruption. Each task therefore has a task accesses a data set written to by a
previous task, it is not started while that
previous task is being executed (by a
different processor). Sequencing con-
straints are inserted in the task list
automatically by a system assembler using
I J
I |A mr | intertask dataflow analysis based on the
dispositions of parameters.
dependency Such constraints are enforced by a
dependency code and an in-progress flag
attached to each task. If the dependency
code is nonzero for a particular task, it is
interpreted as the offset within the list of
another (previous) task that must not be
running when the current task is started.
Since the dispatcher assigns processors to
tasks sequentially within each task list,
execution of further tasks for the process
(a) is suspended until the indicated task
completes.
Figure 5 illustrates the use of
dependency codes. In the example shown
in Figure 5a, task A shares data sets with
II B
1C ) | tasks B and C (but B and C do not share
data sets). We can enforce B and C waiting
for the completion of A byputtingABCin
the task list, and setting the dependency
code of B to indicate that it must wait for
A. The dispatcher will start A, but will be
forced by the dependency code of B to wait
until A has completed before it starts B.
Since the dispatcher will not consider C
0 > until B has been started, C is also forced to
............... .. . synchronization task .wait.
/............ synchronization
task
Conversely, if we want A to be executed
only after both B and C have completed,
we can create a dummy task D, put BCDA
A
-" in the task list, set the dependency code of
D to make it wait for C, and set the depen-
/ | ~~~~~~~~~~~~~dency
code ofA to make it wait for B.This
(b) is illustrated in Figure 5b. The dispatcher
will not start D until C completes, and A
is not considered until D is started. Since
. ~~~~~~~~~~~~~~~~~~D
iS trivial, the scheduler tries to start A
Figure 5. Task dependencies. once C completes. The dependency code of

56 -IEEE SOFTWARE
A refers to B, so A must in turn wait for B by processes via operating system service ware architecture. Modern mainframes can
to complete. This permits B and C to be tasks. These tasks are similar to the include spare processing and memory
executed concurrently on different synchronization tasks used to control components. The Rex approach to real-
processors, but requires both to have fin- concurrency between tasks within a single time control facilitates such reconfigura-
ished before A can start. process in that they could conceivably be tion because each physical processor has its
In the above example, D is an executive supplied automatically by a high-level sys- own dispatcher - disabling a physical
task - more precisely, a synchronization tem assembler. processor is equivalent to disabling the
task. Where such tasks are required, they Data communication between the corresponding dispatcher; other dis-
rnay be inserted automatically by the sys- operating system and the application sys- patchers can take up the load. Also, the
tem assembler. An alternative is to elimi- tem is via data sets. Such data sets may memory management portion of the
nate the need for such synchronization implement different forms of buffering on resource allocator can adapt to a dynam-
tasks by using a more general task list data a case-by-case basis. ically shrinking memory resource. Con-
structure that permits specifying The real-time clock and any other oper- figuration management would cooperate
dependency of a task on more than one ating system events can trigger the with the memory manager to remap the
preceding task. Rex does not now support scheduler and call for an application pro- remaining memory into contiguous space.
this for reasons of simplicity. cess to be run. Configuration management also deals
If communication is between processes Hardware interrupts are always handled with the networking between mainframes.
that share memory, or communication is first by operating system interrupt Redundant channels and retransmission
to the I/O portion of the operating system, handlers, whose primary responsibility is protocols are automatically managed by
data set locks may be used to provide to ensure that data is not lost. If such an the operating system.
synchronization. The dispatcher locks a
data set by linking it to a task and Fault processing. Fault tolerance is an
unlocking it when the task completes. The important aspect of many real-time
dispatcher also ensures locks are honored. computing systems. The fault processing
If the communication is between Hardware lntelUpts portion of the operating system includes
processes in separate computers not are always haridled first self-testing routines as well as other checks
sharing memory but connected via a by operating system to detect failures. Once a fault is detected,
channel, the communication is treated as error recovery routines determine the
if it were through two separate data sets. p ha r,
whose appropriate response. This can involve
The operating system serves as an primaeofiuato,trgernrig-rirt
, figuration, triggering high-priority
intermediary. responsiblity IS applications recovery processes, or
It seerns reasonable to expect that this to ensure that restarting the parent process from some
form of communication could be made data is not lost. previous checkpoint.
transparent through the introduction of Rex can be logically extended to
implicit synchronization and transfers incorporate checkpointing. We are
between remote copies of a single virtual considering analyzing the effects of
data set. No attempt has yet been made to interrupt calls for action by an application communicating corrupt information to
implement such transparent distribution of process, the operating system signals the automatically determine where check-
data sets with Rex. scheduler to trigger the process. The pro- points should be inserted into each
cess will begin execution as soon as its process's task list to permit recovery of lost
The operating system priority permits, subject to the limitation data. Static recovery tables may be a
The operating system hosts the executive that any tasks currently being executed practical additional product of the high-
on a particular hardware configuration. It must not be preempted. level system assembler required to produce
serves as the first shell surrounding the Thus, while operating system interrupt the agenda.
hardware core. There are three primary handlers may preempt a processor from a The integration of fault processing and
groupings of operating system functions: task, this preemption is transparent to the configuration management features with
system services, configuration manage- task. (That is, interrupt handlers do not the Rex executive has not yet been imple-
ment, and fault processing. write on any data sets accessed directly by mented and tested. This is, however, one of
an executing task, and their execution times the areas of current research where the Rex
System services. The operating system are short enough that they can be architecture seems to offer particular
provides a real-time clock and utilities that adequately accounted for as a bounded promise.
manage physical I/O. The I/O utilities percentage overhead on the processor.) The
provide services in two forms. Interrupt processor is always allowed to complete a
handlers, which are invisible to the appli- task before any other task can be he system architecture described
cation program, bring input data into dispatched on the same processor. f here has a number of virtues we
buffers and transfer output data from The operating system also includes the hope to exploit in future research,
buffers. Utility procedures can be invoked bulk storage controller, which interfaces as outlined below.
by application processes to initiate I/O the resource allocator with the backing The architecture offers great potential
operations and to wait for I/O operations storage subsystem. for reuse of application software compo-
to complete. nents. In fact, it allows for use of these
Operating system services, such as Configuration management. Configu- components as user-defined, high-level
initiating an I/O operation, are requested ration management reconfigures the hard- instructions.

May 1986 5
 The use of such high-level instructions same application programs without 4. D.M. Berryetal., "LanguageConstructs for
is discussed here only as an assembly-level change. Real-Time Distributed Systems, " Computer
process, and only two levels of abstraction The architecture supports application Language, Vol. 7, 1982, pp. 11-20.
(the components and their assembly into systems requiring backing storage with MilitaryANSI/MIL-STD-1815A,
5-. guage, Standard A da Programming Lan-
US Depart-
a task list) are allowed. The designer is thus automatic management of swapping. In ment of Defense, Washington, DC, Jan.
constrained to think in terms of rather sim- fact, resource requirements and their man- 1983.
ple building blocks, which may not be the agement are overlain onto the application 6. D.R. Cheriton et al., "Thoth, a Portable
appropriate level of abstraction for his system rather than built into it. Potential Real-Time Operating System," Comm.
problem. Research into more powerful sys- extensions in fault tolerance and adaptive ACM, Vol. 22, No.2, Feb. 1979, pp. 105-115.
tem specification languages, for which the hardware and software reconfiguration 7. Introduction to the iRMX86 Operating Sys-
term system compiler would be appropri- areas are promising. tem, Intel Corp., 1982.
term*
ate, is needed. misig.. 8.
Also of significant promise are exten- Hunter Ready, 1985. uide,
V RTX/1750 User's G Doc. 591613,
Because a system's global structure and sions to include host architectures with 9. G. Scallon, "Description of the Function-
scheduling characteristics are separated multiple heterogeneous general- and ally Oriented System Simulation (FOSS) for
from the details of the implementation and special-purpose processors, all orches- Software/Hardware Design," Boeing Aer-
execution of the components, the pro- trated by a single high-level system pro- ospace Report D180-18617-1, Seattle.
totyping, development, validation, and gram. There are no inherent limitations in
maintenance of an application can be the architecture that preclude such an
viewed more simply and more systemati- approach.
cally. This offers potential for automatic Finally, adaptations of the architecture
generation of software from high-level to accommodate standard programming
specifications. languages such as Ada seem promising.
Particular virtues to be exploited here are One interesting possibility is the automatic
the guarantee that concurrent tasks will not translation of the native structures of such
interfere with one another and that differ- a language into procedure-like chunks that
ent implementations (for example, multi- can be managed by an executive. This tech-
processor versus uniprocessor) use the nique could be used to impose more pre-
cise management of time-critical compu-
tations than the standard language itself
provides.
Another possibility is the automatic gen- Theodore P. Baker is a professor in the Com-
eration (or selection from a library) of puter Science Department at Florida State Uni-
versity. While coauthoring this article, he was on
9 manageable cunks, coded
manageble
chunks, laguage
oded inn aa language sabbatical leave at the University of Washington,
like Ada, to meet a specification expressed where he studied tool design for real-time soft-
in a higher level language. We are explor- ware development.
ing this path, both to exploit the standard Baker received his BA in 1970 and PhD in 1974
executive architecture and to gain_ in computer science from Cornell University.
gain more His address is Department of Computer
understanding of the future role of Ada in Science, Florida State University, Tallahassee, FL
real-time applications. D1 32306-4019.

Acknowledgments
The Washington Technology Center, the Uni-
versity of Washington, and Boeing Aerospace
X_ , ; supported the writing of this articlec The authors
are also indebted to the referees for their con-
0-S S * ~~structive comments.

__References Gregory M. Scallon is an industrial research fel-

l . J.G.P. Barnes, "Real-Time Languages for low with the Washington Technology Center,
Process Control, " Computer Journal, Vol. working on real-time software development
15, No. 1,1972, pp. 15-17. methodologies. At Boeing Aerospace, he is
2. N. Wirth, "Toward a Discipline of Real- applying advanced software research to a Stra-
Time Programming," Comm. ACM, Vol. tegic Defense Initiative program.
20, No. 8, Aug. 1977, pp. 577-583. Previously, he worked for ITT and Texas
3. H.A. Schutz, "On the Design of a Language Instruments. Scallon received a BSEE from
:_ ; * for Programming Real-Time Concurrent Seattle University in 1965.
Processes," IEEE Trans. Software Eng., Scallon's address is Boeing Aerospace, PO
Vol. SE-5, No. 3, May 1979, pp.248-255. Box 3999, Seattle, WA 98124.

58 IEEE SOFTWARE