laplantekernels

8/9/2019 LaplanteKernels

1/20

CRITERIA AND AN OBJECTIVE APPROACH TO SELECTING COMMERCIALREAL-TIME OPERATING SYSTEMS BASED ON PUBLISHED INFORMATION

Phillip A. Laplante1

Penn State University

Abstract

Matching a commercial real-time operating system to a particular application is a problem forwhich there is no obvious solution strategy. While factors such as estimated production volume,likely processor involved, mission criticality, cost, reliability, software support, ease-of-use, andmaintainability need to be considered, oftentimes the selection is merely based on the preferencesof the design team, management, or intensity of vendor marketing.

In this paper the selection of real-time operating systems is examined. A set of criteria and anassociated metric are presented that rely only on published marketing information. Then, todemonstrate the application of this metric, information from several existing commercial real-time operating systems is collected and analyzed. Five hypothetical applications are thenmatched with the most appropriate real-time operating system, using the criteria and metric.

The contribution of this paper is a set of criteria, a metric, and a methodology for matching real-time operating systems to applications based on marketing information, without the need forintensive performance testing.

Keywords: metrics, real-time operating systems, selection criteria

1. Introduction

There is surprisingly little work on metrics for evaluating real-time systems. A literature searchturned up nothing for evaluating commercial real-time operating systems (RTOS2) in journals. Anumber of reports are available either from workshops or trade magazines but these were difficultto find.

The dearth of published work on evaluation of RTOS is surprising because there is both anengineering and business advantage in some formalized methodology for evaluating candidatesystems. In any case, some metrics that are documented for RTOS only involve schedulingfeatures. For example, Buttazzo gives average response time, total completion time, weightedsum of completion times, maximum lateness and maximum number of late tasks [1]. Othermetrics are based on extensive experimental procedures, [2], [3], [4], [5], [6]. Unfortunately,

these are fairly limited in scope and the results of a given test cannot be necessarily imputedbeyond the experimental platform. Hence, they provide only partial guidance in the selection of acommercial RTOS solution.

Unfortunately, unless a comprehensive experience base exists using several alternativecommercial real-time operating systems in multiple, identical application domains, there are only

1Associate Professor of Software Engineering, Penn State Great Valley School of Graduate Professional Studies, 30 Swedesford Road, Malvern,PA 19355-1443; (610) 725-5314; fax (610) 889-1334; [email protected]. The Author wishes to acknowledge Rick Bruno, Sandip Patel,

Nutthinee Katapituk, Jason Poleski, Sebastian Lesniak, Eric Shoup, from Lockheed Martin Naval Electronics and Surface Systems for assistingwith the data collection for this paper.2RTOS or OS are used as short hand for real-time operating system or operating systems, depending on the context.

1
mailto:[email protected]:[email protected]:[email protected]


2/20

two ways to objectively determine the fitness of a product for a given application. The first is torely on third party reports of success or failure. These abound and are published widely on theWeb (e.g. [3]). The second is to compare alternatives based on manufacturers publishedinformation from brochures, technical reports, and Web sites. Therefore, there should be someway to incorporate manufacturers published data into the decision-making process, especiallywhen independent performance tests are unavailable and impractical to conduct.

The contribution of this paper, then, is an objective and flexible technique for comparingcommercial real-time operating systems based on marketing information. This technique can beused, however, in conjunction with supplemental information from actual experience and thirdparty reports.

1.1 Build Versus Buy

A common question that is asked at the time of systems requirements specification is should acommercial real-time solution be used or should one be built from scratch? While the answerdepends on the situation, commercial kernels3 are frequently chosen because they generallyprovide robust services, are easy to use, and may be portable.

While commercial RTOS provide flexibility in the number of tasks supported and schedulingdiscipline, there are drawbacks in their use. For example, they are usually slower than the hard-wired interrupt driven model because tremendous overhead is incurred in implementing the task-control block model, which is the typical architecture for Commercial RTOS [7], [8].Furthermore, commercial solutions tend to suffer from featureitis too many unneeded featuresare incorporated in order for the product to have the widest appeal. The run-time and storagecosts of these features may be excessive. Finally, manufacturers may be tempted to makemisleading claims, or give best case performance figures. The worst-case response times, whichare the most informative, can generally not be known. If they are known, they are typically notpublished because they would place the product in an unfavorable light.

For embedded systems, when the per-unit charge for commercial products is too high, whendesired features are unavailable, or when the overhead is too high, the only alternative is to writethe real-time kernel. But this is not a trivial task [7], [8]. Therefore, commercial RTOS shouldbe considered wherever possible.

1.2 Commercial Real-Time Operating Systems

There are many commercial solutions available for real-time systems, but deciding which one ismost suitable for a given application is difficult. Many features of embedded real-time operatingsystems must be considered including cost, reliability, and speed. But there are many othercharacteristics that may be as important or more important, depending on the application. Forexample, the real-time operating system largely resides in some form of ROM and usuallycontrols hardware that will not tolerate many faults; therefore, the RTOS should be fault-tolerant[9]. Also, the hardware needs to be able to react to different events in the system very quickly;therefore, the OS should be able to handle multiple processes in an efficient manner [10].Finally, because the hardware on which the operating system has limited memory, the operatingsystem must also require a reasonable amount of memory in which to run [7].

3The term kernel is used to mean that part of the operating system that provides task scheduling and intertask synchronization andcommunication.

2


3/20

In fact, there are so many functional and non-functional attributes of any commercial RTOS,

that evaluation and comparison must be a subjective endeavor. Some structure, however, shouldbe used in the heuristic decision-making. Using a standard set of criteria provides such structure.

2. Criteria for selecting real-time systems

What makes a good RTOS? In short, it depends on the standard definition of a real-time system,namely, a system in which requirement satisfaction (logical correctness) is based on thecorrectness of the systems behavior in terms of data and time [7]. In essence, the RTOS musthave correct and bounded behavior under all system load scenarios.

From a business perspective, there is concern about compatibility, especially in anenvironment where there are heterogeneous and legacy systems. Furthermore, it is critical thatthe RTOS support newer or standard network technologies for flexibility of product developmentand maintenance.

Mainstream real-time researchers and engineering practitioners seem to agree on the following

desirable characteristics for real-time systems, these are:

timeliness design for survival under peak load (schedulability) predictability fault-tolerance maintainability [1]

Therefore the selection criteria should reflect these desiderata.

Consider thirteen selection criteria, 1 13m mL , each having a range [0,1]im where unity

represents the highest possible satisfaction of the criterion and zero represents complete non-satisfaction. Recognizing that the importance of individual criterion will differ depending on the

application, a weighting factor, [0,1]iw , will be used for each criterion im , where unity is

assigned if the criterion has highest importance, and zero if the criterion is unimportant for aparticular application. Then a fitness metric, [0,1]M , is formed as

13

1

i i

i

M w m

=

= . (1)

Clearly, a higher value ofM means that the RTOS is well suited to the application, while alower value means that the RTOS is not well suited for the application.

While selection of the values for im and iw will be subjective for any given RTOS and anygiven application, the availability of this heuristic metric, provides a handle for objectivecomparison, historical perspective and other uses. The following sections describe the criteria.

2.1 Minimum Interrupt Latency

The minimum interrupt latency, 1m , measures the time between the occurrence of hardware

interrupt and when the interrupts service routine begins executing. A low value of 1m represents

relatively high interrupt latency, while a high value of 1m represents low latency.

3


4/20

This criterion is important because if the minimum latency is greater than that required by theembedded system, a different operating system must be selected.

2.2 Total Number of Tasks Supported

This criterion, 2m , defines the most concurrent processes the operating system can simultaneously

support. Even though the operating system may support a large number of tasks, this metric may be further limited by available memory. This criterion is important for systems that neednumerous simultaneous processes. A relatively high number of tasks supported would result in

2 1m = , while few task supported would suggest a lower value for 2m .

2.3 Memory Requirements

Criterion 3m specifies the system memory required to support the OS. It does not include the

amount of additional memory required to run the systems application software. 3 1m = suggests a

minimal memory requirement, while 3 0m = would represent a larger memory requirement.

2.4 Scheduling Mechanism

The scheduling mechanism criterion, 4m , enumerates whether preemptive, round-robin, or some

other task scheduling mechanism is used by the operating system. Round-robin scheduling isused to allow tasks at the same priority level to share the resources of the system. Preemptivescheduling allows high priority tasks to begin immediately by preempting the current taskrunning. Most PC operating systems use preemptive task scheduling because an indeterminateamount of processes will be running, each with their own unique CPU requirements. However,when the number of processes is fixed, as in the case of many real-time systems, preemptive taskscheduling is not always a more efficient algorithm than round-robin scheduling [10].

Kernel preemption is another feature that reduces response times and increases system

schedulability. If the kernel is not preemptable, then a low priority task that is in the middle of akernel service call would inherit the highest priority to the low priority task, creating a priorityinversion. Kernel preemptability alleviates this situation.

If many scheduling mechanisms are supported and if the kernel is preemptable, then a high

value would be assigned to 4m .

2.5 Intertask Synchronization Mechanism

Criterion 5m refers to the available methods the operating system has to allow processes to

communicate with each other. Among possible choices are mutual exclusion (mutexes), binary

and counting semaphores, POSIX pipes, message queues, shared memory, FIFO buffers, controlsockets, and signals and scheduling. Each mechanism has advantages and disadvantages [11],

[12]. Let 5 1m = if the RTOS provides all desired scheduling mechanisms. A lower value for 5m

implies that less synchronization mechanisms are available.

2.6 Context Switch time

4


5/20

Criterion 6m refers to the time it takes for the kernel to save the context when it needs to switch

from running one task to another. The context may include one or more of the following: PCpointer, stack pointer, heap pointer, I/O pointer, floating point registers, temporary storageregisters, and any MMU registers. This information is needed so that the OS can return to thepoint of interruption without loss of information [13]. A relatively short context switch time

would result in a higher value for 6m .

2.7 Programming Environment

Application availability, 7m , refers to the amount of software available (either that ships with the

operating system or is available elsewhere) to develop applications to run on the operatingsystem. For example, RTLinux is supported by the GNU suite of software, which includes thegcc C compiler and many freely available software debuggers, and other supporting software.This is an important consideration, especially when using an unfamiliar operating system. Thiscriterion also takes into consideration the number of other operating systems that are compatiblewith the given RTOS.

Let 7 1m = if a large amount of software were available and compatible, while 0 would meanthat little or none was available or compatible.

2.8 Portability

Criterion 8m refers to the different processors that the OS supports. This is important in terms of

portability and compatibility with off-the-shelf hardware and software. This criterion alsoencompasses the range of peripherals that the OS can support, such as video, audio, SCSI, andsuch. A high value for the criterion represents a highly portable and compatible RTOS.

2.9 Source Code Availability

Criterion 9m refers to whether the code of the operating system will be available to the developer,

for tweaking or changes. The source also gives insight to the RTOS architecture, which is quiteuseful for debugging purposes and systems integration. Setting 9 1m = would suggest open source

code or free source code, while a lower value might be assigned in proportion to the purchase

price of the source code. Let 9 0m = if the source code were unavailable.

2.10 Software Support (warranty)Criterion 10m refers to the after-sale support a company puts behind its product. Most vendors

offer some sort of free technical support for a short period of time after the sale, with the optionof purchasing additional support if required. Some even offer on-site consultation. A high value

might be assigned to a strong support program, while 10 0m = if no support is provided.

2.11 Cost

5


6/20

This criterion is directly related to the cost of the RTOS including the development license cost aswell as the per target license costs. This consideration is critical because for some systems, theRTOS cost may be disproportionately high. In any case, a relatively high cost would be assigned

a very low value, while a low cost would merit a higher value for 11m .

2.12 Royalty Fee

Frequently, a per target license or royalty fee is charged for each delivered system. In the casewhere few targets are intended, this can be inconsequential. However, when a large number of

targets are intended then the per target licensing fee can be considerable. This criterion, 12m , is

high if a relatively low per unit royalty fee is charged.

2.13 Networking Support

This criterion, 13m , is based on a listing of what networks and network protocols are supported by

the given RTOS. A high value for the criterion represents a relatively large number of networkssupported.

3. Evaluation of Commercial Real-Time Operating Systems

A number of commercial RTOS are now examined based on the criteria introduced. Althoughthe data is real, the manufacturer names are omitted as the intention is not to imply arecommendation of any product. These systems were selected based on both the availability ofpublished information on the Web, and the knowledge that these systems have fairly widespreaduse. Of course, the scope of the study could have been expanded to consider many other viablecommercial products. But the intent of this work is to provide a methodology and someexamples of its use not to completely assess the RTOS marketplace.

Since this work was done, clearly some of the systems performance characteristics may have

changed. One must realize that any analysis is only as accurate as the data provided by themanufacturers at the time of the study4. This is typical of a real-world situation where there islittle opportunity to test the accuracy of a manufacturers claim prior to making a buy decision.However, this constraint does not diminish the value of this work, which is to provide amethodology for assessment of goodness of fit for commercial real-time solutions and a particularapplication.

In the sections that follow, the following assumptions are made:

For all the sample RTOS, assume that the calculations for the number of interrupt, theminimum time that it takes, and other system analysis based on the metrics chosen areperformed under the same conditions, i.e. sampling, time constraints, number of

processors, and etc.

Maximum or minimum of tasks refers to the OS object, such as the MMU, devicedrivers, and other system tasks.

Assume that interrupt refers to hardware interrupt. Software interrupts, togetherwith hardware interrupts and other vectoring mechanisms provided by the processor, arereferred to as exception handling.

4 The data were collected during early 2002.

6


7/20

Thread switching time is equivalent to the measurement of context switching time.

In the cases where a criterion value can be assigned, this is done. Where the criteria areprocessor dependent or indeterminate absent a real-application, assignment of a rating is

postponed, and a value of * is given. This uncertain value is fixed at the time of applicationanalysis. Note too that the values between tables need to be consistent. So, for example, if a 6

microsecond latency yields 1 1m = for RTOS X, the same 6 microsecond latency should yield

1 1m = for RTOS Y.

Consider commercial RTOS A. Table 1 summarizes the criteria and ratings. The rationale forthe ratings are described in the following paragraphs..

7


8/20

Table 1: Summary data for real-time operating system A.

Criterion Description Rating Comment

m1 Minimum Interrupt Latency * CPU dependent

m2 Total Number of Tasks Supported 0.5 32 Thread Priority Levels

m3 Memory Requirements 0.7 ROM: 60k m4 Scheduling Mechanism 0.25 Preemptivem5 Intertask Synchronization

Mechanism0.5 Direct Message Passing

m6 Context Switch Time * na

m7 Programming Environment 1 Compilers: Greenhills, ADS, ARM, Diab, GNU,Tools: Mentor Graphics, Greenhills, SDS, ARM,ADS

m8 Portability 0.8 PowerPC, ARM, MIPS, DSPs, Network Processors

m9 Source Code Availability 1 yes

m10 Software Support (Warranty) 0.5 Paid phone support

m11 Cost 0.7 approximately $2500m12 Royalty Fee 0 nom13 Networking Support 1 TCP/IP, FTP, SMTP, SNMP, PPP, ATM, ISDN,

X25, Telnet, Bootp, http-server

The product literature indicated that the minimum interrupt latency is CPU dependent,therefore a * value is assigned here (which will be later resolved as 0.5 for the purposes ofevaluating the metric). Context switch time is not given and so a * is also indicated. The RTOSsupports 32 thread priority levels, but it is not known if there is a limit on the total number oftasks, so a value of 0.5 is assigned. The RTOS itself requires 60K of memory, which issomewhat more than some of the alternatives so a value of 0.7 is assigned. The system provides

only one form of scheduling, preemptive priority, so a lower value, 0.25, is assigned here than ifother forms such as round-robin were available. Intertask synchronization and communication is

available only through message passing so a relatively low 5 0.5m = is assigned.

The company provides paid phone support, which is not as generous as other companies, so

a value of 10 0.5m = is assigned. There is a royalty cost for each unit so a zero was assigned.

Finally, there is a wide range of software support for the product, including network protocols,and the source is available so values of one are given for these three criteria.

Using the same kind of reasoning, ratings tables are obtained for commercial RTOS B, C, Dand E, shown in tables 2 through 5 respectively.

8


9/20


10/20

Table 4: Summary data for Commercial RTOS D.


m1 Minimum Interrupt Latency * CPU Dependent

m2 Number of Tasks Supported 1 Unlimited m3 Memory Requirements 1 2K memory required

m4 Scheduling Mechanism 1 Preemptive, round-robin and time slicingm5 Intertask SynchronizationMechanism

1 Binary, counting, and mutual exclusion semaphores withpriority inheritance, message queues, POSIX pipes,counting semaphores, signals and scheduling, controlsockets and shared memory

m6 Context Switch Time 0.5 14 micro second switch time

m7 Programming Environment 1 Tornado II, more then 1800 APIs available, powerful filesystem and I/O management, C++ and other standard run-time support

m8 Portability 1 x86, PowerPC, ARM, MIPS, 68K, CPU 32, ColdFire,MCORE, Pentium,i960,SH, SPARC, NEC V8xx, M32 R/D,RAD6000, ST 20, TriCore

m9 Source Code Availability 0.25 Source available for $120,000

m10 Software Support(Warranty)

0.8 Phone Tech support available

m11 Cost 0.1 $23,000m12 Royalty Fee 1 Yesm13 Networking Support 1 Full TCP/IP Suite

Table 5: Summary data for commercial RTOS E.

10


11/20


m1 Minimum InterruptLatency

1 6 microseconds

m2 Number of TasksSupported

1 32,000

m3 Memory Requirements 0.9 kernel = 6.2Kb

file management = + 32Kbperipherals = + 200Kbm4 Scheduling Mechanism 0.25 Prioritized, preemptive scheduling.

Equal priority tasks are scheduled on a time-sliced,round-robin basis

m5 Inter-task SynchronizationMechanism

1 Semaphore event flags, queuing libraries, binarysemaphores, timing semaphores, physical semaphores,and counting semaphores.

m6 Context Switch Time * Dependent on Processor

m7 Programming Environment 0.5 Editor, disk utilities, file utilities, and a virtual port thatallows the user to run, monitor, and switch betweenmultiple task output screens.

m8 Portability 0.2 68k architecture family

m9 Source Code Availability 1 Yes

m10 Software Support(Warranty)

1 Full support

m11 Cost 0.7 $2,880 5,850m12 Royalty Fee 1 Yesm13 Networking Support 0.6 Provided by BSDnetTM, which provides Ethernet, and

TCP/IP support, telnet, and ftp.

Admittedly, these assignments were somewhat subjective. Numerous arguments can be madethat a higher or lower number should be assigned in almost every case. But, the idea is that thereis some consistency in how the ratings are assigned so that like attributes can be compared

objectively. This represents the power of this methodology over heuristic or even emotionallybased approaches.

4. Matching the Application to the Operating System Using the Criteria

In order to demonstrate the use of the criteria and associated metric, a set of five hypotheticalsystems are analyzed to demonstrate how comparative metrics can be used to match anapplication to the appropriate real-time operating system. These systems are loosely described as

a hand-held game application, a controller application for the fuel injection system of typical passenger car, an animatronic robot used in the filming of a science fiction movie,

a navigation system for a fighter aircraft, and a medical device that reduces the time needed for a medical imaging scan.

These systems were selected because they are representative of a large band of the real-timeembedded application spectrum. Moreover, pedestrian familiarity with the basics of what thesesystems do, avert the need for complex systems requirements specifications.

To do the comparison, a tabular format shown in tables 6 through 10 is used. All uncertain im

are set to 0.5 where information is still unavailable for the purposes of evaluating the fitness

11


12/20

metric M . This is not the ideal manner for dealing with uncertain information [14], butconsideration of this aspect is left for further study.

The result is a set ofM values that reflect the weighted importance of each criterion for agiven application, and the known information about the candidate operating system. Aquantitative selection of the appropriate RTOS can then be made.

In the forgoing discussions, tables 6 through 10 were obtained by setting up a set of spreadsheetsin which the weighting factors are input in appropriately named column. Then the objectivemetric component values are input for the various candidate operating systems. In this way,metric M can be computed rapidly and correctly, and the weighting factors can be adjusted asnecessary for sensitivity analysis.

4.1 Hand-held game application

For a hand-held game application similar any criterion related to cost to produce and performance

are critical. Hence 1 3 5 9 11 12, , , , ,m m m m m m are given unity weights, as shown in table 6. The number

of tasks in such a system is likely to be relatively low (e.g. one task per actuator, one for video

refresh, one for sound), therefore, 2 0.5m = . The scheduling mechanism is not as importantbecause this application is likely going to be a preemptive priority system, which is supported by

every RTOS. Therefore 4 0.1m = .

Table 6: Decision Table for Hand-held Game Application

12


13/20

Criterion Description Weight, wi A B C D E

m1 Minimum

Interrupt

Latency

1 0.5 0.8 1 0.5 1

m2 Total Number ofTasks Supported

0.5 0.5 0.5 0.5 1 1

m3 Memory

Requirements

1 0.7 0.2 0.5 1 0.9

m4 Scheduling

Mechanism

0.1 0.25 0.5 0.25 1 0.25

m5 Intertask

Synchronization

Mechanism

1 0.5 1 0.5 1 1

m6 Context Switch

Time

1 0.5 0.5 0.5 1 0.5

m7 Programming

Environment

0.5 1 0.75 1 1 0.5

m8 Portability 0.1 0.8 0.5 0.2 1 0.2

m9 Source Code

Availability

0.5 1 1 0 0.4 1

m10 Software

Support

(Warranty)

0.5 0.5 0.5 1 0.8 1

m11 Cost 1 0.5 0.5 0.1 0.1 0.7

m12 Royalty Fee 1 0 1 1 1 1

m13 Networking

Support

0.2 1 1 1 1 0.6

M 4.51 5.68 5.10 6.60 7.02

Since the application will run on a special purpose device, portability, and network support are

of low importance, and 8 13,m m reflect this. Finally, software support and source availability are

relatively mild since this application is not as sensitive to the cost of the source as it is to the per

unit royalty cost (because of anticipated production volume). Hence, 9 10 12 0.5m m m= = =

Applying the weighted criteria to the five candidate systems yields the decision matrix shownin table 6. From this table it is clear that RTOS E emerges as the choice for this application.

4.2 Controller application for the fuel injection system

A fuel injection system controls the fuel/air mix in an internal combustion engine and reacts toevents to promote correct and efficient operation. The main processor, or Powertrain ControlModule (PCM) reads various input signals and controls the fuel and emissions systems to try toobtain the best performance while maintaining good mileage and emissions output [14]. Each ofthese inputs and outputs is critical to the overall operation of the entire system.

The RTOS should be able to manage multiple processes quickly and reliably, therefore high

weights were assigned to 1 3 4 5, , ,m m m m . The operating system must have a low unit cost because

13


14/20

of anticipated production volume, and the source code must be available for fine-tuning.

Therefore, 9 12 1m m= = . Processor compatibility is not critical in this highly embedded system,

there is potential for using a standard bus for sharing data. Hence 8 0.1m = and 13 0.5m =

The other criteria ratings follow the same logic as in the previous example. A summary of theratings is given in table 7, along with the associated decision matrix.

Table 7: Decision Matrix for Fuel-Injection System.


m1 Minimum

Interrupt Latency

1 0.5 0.8 1 0.5 1

m2 Total Number of

Tasks Supported

0.1 0.5 0.5 0.5 1 1

m3 Memory

Requirements

1 0.7 0.2 0.5 1 0.9

m4 Scheduling

Mechanism

0.75 0.25 0.5 0.25 1 0.25

m5 Intertask

SynchronizationMechanism

0.5 0.5 1 0.5 1 1

m6 Context Switch

Time

1 0.5 0.5 0.5 1 0.5

m7 Programming

Environment

0.5 1 0.75 1 1 0.5

m8 Portability 0.1 0.8 0.5 0.2 1 0.2

m9 Source Code

Availability

1 1 1 0 0.4 1

m10 Software Support

(Warranty)

0.5 0.5 0.5 1 0.8 1

m11 Cost 1 0.5 0.5 0.1 0.1 0.7

m12 Royalty Fee1 0 1 1 1 1

m13 Networking

Support

0.5 1 1 1 1 0.6

M 5.02 6.10 5.11 6.85 6.96

The metric suggests that RTOS E is again a good fit.

4.3 An animatronic robot used in the filming of Star Wars

These robots are complex electromechanical systems, which require sophisticated control

software, and at the same time must be easily programmable by special effects creators. Atypical robot is likely to include numerous limbs with multiple degrees of freedom. These limbswill be controlled by a variety of actuators. Consequently there is a need for a scalable embeddedsystem to control such complex machine in a predictable and reliable fashion. The decisionmatrix is given in table 8.

Table 8: Decision Matrix for Animatronic Robot.

14


15/20


m1 Minimum

Interrupt Latency

1 0.5 0.8 1 0.5 1

m2 Total Number of

Tasks Supported

1 0.5 0.5 0.5 1 1

m3 Memory

Requirements

0.5 0.7 0.2 0.5 1 0.9

m4 Scheduling

Mechanism

0.5 0.25 0.5 0.25 1 0.25

m5 Intertask

Synchronization

Mechanism

0.5 0.5 1 0.5 1 1

m6 Context Switch

Time

0.1 0.5 0.5 0.5 1 0.5

m7 Programming

Environment

0.5 1 0.75 1 1 0.5

m8 Portability 0.5 0.8 0.5 0.2 1 0.2

m9 Source Code

Availability

0.5 1 1 0 0.4 1


(Warranty)

0.5 0.5 0.5 1 0.8 1

m11 Cost 1 0.5 0.5 0.1 0.1 0.7

m12 Royalty Fee 0.1 0 1 1 1 1

m13 Networking

Support

0.1 1 1 1 1 0.6

M 4.03 4.28 3.58 5.00 5.34

The criteria ratings, and rationale for the robot are similar to those for the fuel-injectionsystem with a few exceptions. The likely number of tasks to be supported is likely high due to

the many articulated joints that need to be controlled, therefore 2 1m = . Memory requirements are

not as critical, because it is likely that a robot can more easily contain a larger memory module

than the fuel injection system, so, 3 0.5m = . The scheduling mechanism is not quite as important

in the robot, in that all tasks are likely to be preemptive priority, while in the fuel-injectionsystem there is possibly going to be additional scheduling flexibility needed. Finally, thehardware compatibility is slightly more critical for the robot because of the possibility of reuse ofexisting components from other robots and the source code is somewhat less important because

the mission criticality is lower. Therefore, 8 0.5m = . The decision metric again suggests RTOS E.

15


16/20

4.4 A fighter jet inertial navigation system

The software controlling a navigation system requires substantial input/output processing whichinherently causes large amounts of system interrupts. This is a highly reactive, and missioncritical system that requires fast context switching, minimal interrupt latency, a high degree ofsynchronization and a well-supported and reliable system. Therefore

1 2 5 9 10 11 12 1m m m m m m m= = = = = = = . Hardware compatibility is not critical because there is little

need to port the system and the number of tasks supported is relatively low, therefore 8 0.2m = .

The other criteria are set to 0.4 or 0.5 because they are only moderately important. The ratingsassigned are summarized in Table 9.

Table 9: Decision Matrix for Navigation System.

m1 MinimumInterruptLatency

1 0.5 0.8 1 0.5 1

m2 Total Number

of TasksSupported

0.1 0.5 0.5 0.5 1 1

m3 MemoryRequirements

1 0.7 0.2 0.5 1 0.9

m4 SchedulingMechanism

0.5 0.25 0.5 0.25 1 0.25

m5 IntertaskSynchronization Mechanism

1 0.5 1 0.5 1 1

m6 Context SwitchTime

1 0.5 0.5 0.5 1 0.5

m7 Programming

Environment

1 1 0.75 1 1 0.5

m8 Portability 0.1 0.8 0.5 0.2 1 0.2

m9 Source CodeAvailability

1 1 1 0 0.4 1

m10 SoftwareSupport(Warranty)

1 0.5 0.5 1 0.8 1

m11 Cost 0.4 0.5 0.5 0.1 0.1 0.7

m12 Royalty Fee 0 1 1 1 1

m13 NetworkingSupport

0.5 1 1 1 1 0.6

M 5.66 5.80 5.24 6.94 6.73

The metric suggests that RTOS D is the best match for this system.

4.5 A medical device that reduces the time needed for an MRI scan

16


17/20

Now consider a real-time operating system to be implemented within a device used to reduce thetime needed for a medical imaging scan, such as an MRI. The following discussion summarizesthe ratings shown in Table 10.

Table 10: Decision Table for Medical Imaging System.

m1 Minimum

Interrupt

Latency

0.5 0.5 0.8 1 0.5 1

m2 Total Number of

Tasks Supported

1 0.5 0.5 0.5 1 1

m3 Memory

Requirements

0 0.7 0.2 0.5 1 0.9

m4 Scheduling

Mechanism

0.5 0.25 0.5 0.25 1 0.25

m5 Intertask

Synchronization

Mechanism

1 0.5 1 0.5 1 1

m6 Context Switch

Time

0.5 0.5 0.5 0.5 1 0.5

m7 Programming

Environment

1 1 0.75 1 1 0.5

m8 Portability 0.1 0.8 0.5 0.2 1 0.2

m9 Source Code

Availability

1 1 1 0 0.4 1


(Warranty)

1 0.5 0.5 1 0.8 1

m11 Cost 0.1 0.5 0.5 0.1 0.1 0.7

m12 Royalty Fee 0 0 1 1 1 1

m13 Networking

Support

1 1 1 1 1 0.6

0

M 5.26 5.75 4.91 6.56 6.07

Such a system should be relatively fast, to reduce patient exposure to possibly harmfulradiation. Since the system is likely to be large and expensive, there are no constraints on theamount of memory used and cost. High reliability and manufacturer support for the software islikely to be at a premium, and because the system is likely to be part of a networked environment,good networking support is of high value.

Based on the setting the criterion accordingly, the metric again suggests that RTOS D is agood candidate for this application.

4.6 Summary of Case Studies and Sensitivity Analysis

Table 11 summarizes the RTOS recommendations rendered by metric analysis.

17


18/20

Table 11: Applications and metrics derived from decision matrices. Choices are shaded.

Application A B C D E

Fuel injection system 4.51 5.68 5.10 6.60 7.02

Hand-held game 5.02 6.10 5.11 6.85 6.96

Fighter navigation system 4.03 4.28 3.58 5.00 5.34

Animatronic robot 5.66 5.80 5.24 6.94 6.73

Medical imaging device 5.26 5.75 4.91 6.56 6.07

It is important to note that these conclusions do not represent an endorsement or criticism ofany particular commercial solution. Indeed, the conclusions are sensitive to changes in anynumber of factors. This reflected in the weightings choices the metric is very sensitive tochanges in the designers priorities as reflected by these weightings.

For example, in the fuel injection system, changing the scheduling mechanism weighting from0.75 to 1.0 would have caused the selection of RTOS D instead of RTOS E. Similarly, if theunknown value, * were given a value of 0 instead of 0.5, the outcome of the analysis would bequite different.

In any case, the power of the metric is that it can be used to reflect the needs, tastes anddesires of its users. One might argue with the ratings assigned, or the weights, but themethodology and metric are flexible enough to accommodate these differences of opinion.Moreover, the designer is forced to justify and document his or her choices, which will benefitthe system throughout its life cycle.

5. Summary and Conclusions

In this paper a set of subjective criteria was introduced to be used in selecting commercial RTOSto be used to match to a specific application. The formulation of a goodness-of-fit metric basedon these criteria and subjective/quantitative data provided by commercial RTOS manufactureswas discussed. Finally, a flexible heuristic approach using this metric that can be fine tuned

depending on the users needs was presented. The advantage of this metric is that it can be usedbefore the system has been built, in an environment where the experience base is limited, and canbe used in conjunction with other information from technical and experience reports.

This approach was applied to five examples to show how this might work in the real world.

Suggested future work includes studying the sensitivity of the metric and examining the effectof uncertainty on the decision making and modifying the metric to handle uncertain orunavailable information using the extended fuzzy pointing set [14].

18


19/20

6. References

[1] G. Buttazzo,Hard Real-Time Computing Systems: Predictable Scheduling Algorithms andApplications, Kluwer Academic Publishers, 2000.

[2] M. Botlo, J. Zalewski, An Evaluation of VxWorks Version 5.0, CERN Mini & MicroComputer Newsletter, No. 32, pp. 15-18, October 1991.

[3] Dedicated Systems, Comparison between VXWorks/X86 5.3.1, QNZ 4.25 and PSOSSYSTEM/X86 2.2.5, Technical Report, June 11, 2001, accessed from www.Dedicated-Systems.com.

[4] K. Low et al., Overview of Real-Time Kernels at the Superconducting Super ColliderLaboratory, Report SSCL-397, Dallas, TX, May 1991.

[5] M. Timmerman, RTOS Evaluations Kick Off. Real-Time Magazine, pp. 6-10, Issue 98-3,1998.

[6] J. Zalewski, An Independent Comparison of Three Real-Time Kernel Standards, IEEEPosix 1003.4 Working Group Meeting, New Orleans, LA, January 7-11, 1991, Paper No.P1003.4-N0289.

[7] P. A. Laplante,Real - Time Systems Design and Analysis: An Engineer's Handbook, ThirdEdition, John Wiley/IEEE Press, to appear 2003.

[8] J. J. Labrosse, MicroC/OS-II: The Real-Time Kernel, 2nd Edition, CMP Books, 2002.

[9] J. K. Muppala, Steven Woolet, Kishor S. Trivedi, Real-Time Systems Performance in thePresence of Failures,IEEE Computer, May 1991, pp. 37-47.

[10] J. A. Stankovic, Marco Spuri, Marco DiNatale and Giorgio Buttazzo, Implications ofClassical Scheduling Results for Real-Time Systems,IEEE Computer, June 1995, pp. 16-25.

[11] IEEE, POSIX Standard, http://standards.ieee.org/reading/ieee/std_public/description/posix/,last accessed 8/5/02.

[12] B. O. Gallmeister,Posix. 4: Programming for the Real World, OReilly & Associates, 1995.

[13] B. Furht, et al,Real-Time Unix Systems: Design and Application Guide, Kluwer AcademicPublishers, 1991.

[14] P. A. Laplante and D. Sinha, Handling Uncertain Data in Imaging Systems,"IEEETransactions on Systems, Man and Cybernetics, Volume 26, No. 1, February 1996, pp. 21-28.

[15] S. Raman, N. Sivashankar, W. Milam, W. Stuart and S. Nabi, Design and implementationof HIL simulators for powertrain control system software development,Proceedings of the 1999American Control Conference, Volume: 1 , 1999 Page(s): 709 -713 .

19
http://www.dedicated-systems.com/http://www.dedicated-systems.com/http://www.dedicated-systems.com/http://www.dedicated-systems.com/


20/20

laplantekernels

Documents