The Community for Technology Leaders
Green Image
Applications that call for realtime systems are particularlysusceptible to failures. Our challenge is to design, analyze,and build such systems to prevent failures or (at least) tomitigate their effect on operations. The theme articles inthis issue, summarized in the box ( "Article Summaries: Safety and Reliability"), explore different ways to meet this challenge.
What differentiates the development of realtime systemssoftware from other applications? How do reliability and safetyfigure into their development?
A realtime system must respond to externally generated stimuliwithin a finite, specifiable time delay. Realtime systems aretypically embedded systems that interface directly to the physicalequipment they operate, monitor, and control. Examples of suchsystems are flight and weaponscontrol systems, airtraffic controlsystems, telecommunicationsswitching and network equipment,manufacturing processcontrol, and even speechrecognitionsystems, which are beginning to appear in telecommunicationsnetworks and personal computers.
Growing Prevalence
Not a day passes that we don't come into contact with arealtime system. And now they are becoming more prevalent incritical applications. A failure in a critical application such as atelecommunications system may result in great financial loss; in aflightcontrol system it may result in loss of life.
More effort must be expended to analyze the reliability andsafety of such systems. Analysis of hardware components incritical applications has matured over the years and commonlyfollowed techniques have emerged. However, methods andtechniques for analyzing the reliability and safety of the softwarepart of critical applications are relatively new and still maturing.Yet the vulnerability of the system to software failures is on therise and may (and in some cases do) exceed hardware failures.
Software is not only becoming more prevalent in realtimesystems, it is becoming a larger part of realtime systems. Bylarger, we mean the amount of effort expended in designing andimplementing the software over total expended effort.
Differentiating Factors
What differentiates realtime software development from othersoftware?
♦ First, its design is resourceconstrained. The primaryresource that is constrained is time. Depending on processorspeed, this time constraint equates to the number ofprocessing cycles required to complete the task. However,time is not the only resource that can be constrained. Theuse of main memory may also be constrained. In fact,designers may trade off reducing processing cycles at theexpense of using more memory.
♦ Second, realtime software is compact yet complex. Eventhough the entire system may have millions of lines of code,the timecritical part is but a small fraction of the totalsoftware. Yet these timecritical parts are highly complex, withmuch of the complexity introduced to conserve constrainedresources.
♦ Third, unlike other software systems, realtime systems donot have the luxury of failurerecovery mechanisms. Theremay not be a human around to help the software recoverfrom failure. Such software must detect when failure occurs,continue to operate despite the failure, contain the damage tosurrounding data and processes, and recover quickly so as tominimize operating problems.
In developing realtime software, more time is spent in design,especially analyzing ways to improve performance and enhancereliability and safety. Development of most other software focuseson how to handle a normal situation, but realtime,criticalapplication development also focuses on how to handlethe abnormal situation. Also, more time is spent in testingrealtime systems.
Testing not only removes faults (the underlying source ofsoftware failure) and hence improves its reliability, it alsodemonstrates reliability and safety by running software underfield conditions. For safetycritical software, additional time isspent in analyzing failure modes that contribute to safetyhazards.

William W. Everett is a distinguished member of the technicalstaff in the Software Technology Center at AT&T BellLaboratories. He is a former associate editorinchief of IEEE Software and served as guest editor for the "Software Beyond2001: A Global Vision" special issue (November 1994). Hisresearch interests include softwarereliability engineering andsoftwareprocess engineering.

Everett received an engineer's degree from the Colorado Schoolof Mines and a PhD in applied mathematics from the CaliforniaInstitute of Technology.

Shinichi Honiden is the manager of Toshiba Corp.'s Systems andSoftware Engineering Laboratory and chief researcher for theLaboratory for New Software Architectures at Japan'sInformationTechnology Promotion Agency. His research interestsinclude objectoriented methodologies and agentoriented models.

Honiden received a BE, an ME, and a DEng., all in electricalengineering, from Waseda University. He is a member of theIEEE, the Information Processing Society of Japan, and the JapanSociety for Software Science and Technology.

Address questions about this issue to Everett at AT&T Bell Labs,Room 3D416, PO Box 638, Murrary Hill, NJ 079740636; or to Honiden at Systems and SoftwareEngineering Laboratory, Toshiba Corp., 70 Yanagicho, Saiwaiku,Kawasaki 210, Japan;
99 ms
(Ver 3.3 (11022016))