Reuse Insertion in Small Embedded Systems

Larry Smith

United States Air Force Software Technology Support Center OO-ALC/TISEB 7278 4th Street Hill Air Force Base, UT 84056-5205 Tel: (801) 777-9730 FAX: (801) 777-8069 Email: smithl@stsc.hill.af.mil

Vern Phipps

SofTech, Inc Layton, UT 84056 Tel: (801) 544-9200 FAX: (801) 777-8069 Email: phipps@stsc.hill.af.mil

Abstract

The Department of Defense has many large and well-funded projects investigating and inserting software reuse. There is a tendency among those organizations to neglect reuse in small or embedded defense software projects. The STSC has researched a typical small, embedded system and has results of that study. The STSC has also defined a reuse methodology that can be applied to these systems with limited resources.

Keywords: Reuse, process, process improvement, embedded systems

Workshop Goals: Learn of actual reuse insertion projects, all lessons learned, reuse tools being used, and start-up reuse methodologies. Contribute information on embedded system reuse efforts and small software project reuse.

Working Groups: Reuse process models; reuse maturity models; reuse management, organization and economics; design guidelines for reuse; reuse and formal methods; useful and collectible metrics; tools and environments; reuse handbook.

1 Background

The Software Technology Support Center (STSC) is part of the Air Force Embedded Computers Software Improvement Program (ESIP). The overall objective of the STSC is to improve the software process in the Department of Defense (DoD). The STSC’s specific objective is to transfer technologies and exchange information to satisfy its customers needs to continually improve software quality and life cycle productivity. Special emphasis is given to tools and tool support.

The STSC has established an organization to investigate software reuse in the Air Force and Department of Defense. The STSC has contracted with SofTech, Inc., to provide support in this effort. Efforts include researching the state-of-the-art in software reuse, determining STSC customer needs in software reuse, defining software reuse tools, cataloging and evaluating software reuse tools, and developing a software reuse prototype.

2 Position

2.1 Limitations of DoD Efforts

The Department of Defense (DoD) has invested large quantities of money and personnel over many years to investigate software reuse with the intent of reducing it to a viable approach [1]. Software reuse has been envisioned as a method of controlling software expenses that take up such a large portion of current and future budgets. Programs such as STARS, RAPID and AdaNET have spent large amounts of resources directed towards necessary research and pilot implementations. The results have been important and useful but their objectives have not always been in harmony with the software needs of the Department of Defense.

The emphasis in DoD reuse efforts has been towards large Management Information Systems (MIS). This emphasis has left much of the software efforts in the DoD beyond the scope of reuse insertion. This represents a significant neglect since there is a significant amount of software in the DoD that can not meet the parameters required by large reuse efforts.

2.2 Embedded Systems

A large amount of software in the DoD is embedded into weapon systems. Missiles, aircraft, tanks, and command and control systems all rely nearly completely upon software for correct mission fulfillment. Often the software process for these types of systems is poorly defined and is implemented by a small group of people. Also, embedded systems are commonly written in assembly language and are comparatively small. The systems have existed for many years yet may be poorly documented and engineered. In many circumstances, this software may be most critical to the national defense and requires quick and accurate upgrades to be most effective.

2.3 Smaller Projects

DoD Reuse efforts do not provide suggestions and methods that are applicable to smaller software projects. There is a tendency to imply that a software project must be large in order to support reuse. We are often told that successful reuse can occur only if a high level language is used, there is a defined process, a domain analysis is performed, and a formal repository is supported. This necessitates a degree of formality and sophistication to software development that may not exist in practice in small or embedded existing systems. The expected approach also necessitates a large and well funded effort with strong management support and understanding.

2.4 Experiences

Reuse may occur without all of these expectations being met, although not in as large a scale. An example is the F-16 software [2, 3, 4]. There is a high degree of functional reuse between various versions of the Operational Flight Program (OFP), yet there is no formal attempt at reuse. It occurs as a result of a small group of software engineers trying to do the most effective job.

Significant savings can be realized within the DoD by introducing reuse to small, embedded systems. The savings may not be as measurable or as dramatic as other larger and more visible systems. Yet more people can accomplish more work in less time, and this is a necessary goal in the era of reduced defense budgets.

We can learn from the experiences of organizations who have been forced into reuse by constraints such as time or resource availability: They simply had to get the job done with less resources and implemented reuse methods as their approach. Examples of this are the Navy’s RNTDS project and ICBM software.

2.5 RNDTS

The RNTDS project [5] has a very high degree of successful reuse and was implemented before methods were developed by such organizations as the Software Engineering Institute (SEI) or the Software Technology for Adaptable, Reliable Systems (STARS) Project. The project engineers were faced with the reality of not enough resources to do their job and developed a reusable software system as a result.

2.6 ICBM Software

There were two significant cases of reuse in the ICBM: The development of Minuteman III from Minuteman II technology and the development of Peacekeeper from Minuteman III technology. This reuse was the result of critical national need where the luxury of re-developing software was not available. No formal analysis of ICBM software reuse has occurred, but it is a fertile field for determining methods and successes.

2.7 STSC’s Contribution

The STSC has conducted a pilot program into a small, embedded system [6, 7]. The F-16 A/B Head-Up Display (HUD) software (and the supporting process) was analyzed from a reuse perspective. It was found that some reuse occurred as a natural result of engineers doing the best job they could. Many opportunities for reuse were identified that were not currently being utilized, especially in non-code assets. There is a process in place that generally supports reuse, but a higher degree of emphasis would result in measurable savings.

2.8 Conclusions

Reuse will occur if it must be done to meet external forces. A formal, repeatable process as defined by the major DoD reuse efforts does not have to be present in order to have success. The reuseoriented organizations need to realize this and offer help to those that are currently not being noticed. The types of software reuse described in this section has often been dismissed as ad hoc and thus not interesting. Yet this type of reuse has had and can continue to have a significant benefits on software cost in the DoD.

2.9 Recommended modifications

DoD reuse efforts should take smaller and embedded systems more seriously in their research into software process improvement. Much ground can be gained by simply educating organizations involved in small and embedded systems in the principles of reuse. There needs to be an attitude change that these systems are not important or interesting enough to be considered when it comes to software reuse.

2.10 STSC Efforts

Much was learned from the STSC’s review of the F-16 A/B HUD software. These experiences can be extrapolated into other F-16 OFPs and other embedded systems. The experience demonstrates that there are viable possibilities for improving the software process with a reuse emphasis in small, embedded systems.

The STSC has also produced a reuse methodology that can be applicable to any sort of system, whether small, large, embedded or MIS. This methodology takes into accounts the funding and resource limitations that may exist in small projects and deals with concerns of existing embedded system projects.

3 Comparison

The DoD efforts in software reuse have a tendency to support the concept that reuse can only be successful in large projects with well-defined domains and software processes. This implies also that the projects must be well-financed and visible. The STSC contends that this unnecessarily leaves a significant portion of the DoD software community out of the reuse technology.

References

[1] “DOD Software Reuse Initiative: Vision and Strategy.”

[2] “Domain Review of the F-16 HUD OFP,” tech. rep., SofTech, Inc, April 1992.

[3] “Review of the F-16 A/B HUD OFP C5 Document,” tech. rep., SofTech, Inc, April 1992.

[4] “Review of the F-16 HUD OFP B5 Document,” tech. rep., SofTech, Inc, April 1992.

[5] J. Aridis, “Deriving and managing functional commonality for software reuse: An rntds experience,” CrossTalk, February 1992.

[6] “STSC Reuse State-of-the-Art Report,” tech. rep., STSC, August 1992.

[7] “STSC Reuse Methodology Report,” tech. rep., STSC, July 1993.

4 Biography

Larry W. Smith is a Software Engineer at the Air Force Software Technology Support Center (STSC). He is the Project Lead for Software Reuse. Additionally, he works closely with other software technology domains to assist Air Force and DoD Software Development and Maintenance Activities (SDSA) with software process improvement. He received a Bachelors of Science in Electrical Engineering from the University of Utah, and is currently working towards a M.S. degree in Computer Science from Utah State University. Vern Phipps is a Software Consultant with the Ogden, Utah SofTech Office. He is currently the Ogden Office Reuse Project Lead Engineer. Mr. Phipps previously worked for TRW, Inc. where he supported the analysis and MODE maintenance of Minuteman and Peacekeeper software and performed nuclear safety analysis. Previous to TRW, Mr. Phipps was employed by the National Computer Security Center and was assigned as the NSA Liaison Officer for Computer Security for the I-S/A AMPE program at Gunter AFB, AL. He received a Bachelors of Science degree in Computer Science from Brigham Young University in 1983.