Transactions on Information and Communications Technologies vol 9, 1994 WIT Press, ISSN

Transcription

1 A prototyping approach for the Brazilian satellite launcher software development C.A.T. Moura," A.M. Cunha" & K.H. Kienitz^ ^Computer Science Division ^Electronics Engineering Division, ITA, CTA, 600 Jose doa Campos, 6*?, ABSTRACT This paper presents the prototyping approach selected to explore and develop the VLS embedded software project in its initial phase, along with some considerations about the use of this technique for the development of real-time, critical software applications in general. Besides the technical usefulness of the prototype, allowing the study of design alternatives, prototyping is shown as an effective way to improve quality in critical software projects. INTRODUCTION Since the 1960's, aerospace activities have been conducted by Brazilian government agencies. More recently, continuing these experiments, a

2 106 Software Quality Management more comprehensive program, the "Missao Espacial Completa Brasileira - MECB," was established. Its objective is to acquire capability for the development, launching and operating of low orbit satellites. In order to attain this objective, the program was divided into three segments, comprising the development of four satellites, the construction of a new launching center at Alcantara, northeast of Brazil, and the development of a launching vehicle, the "Veiculo Langador de Satelites - VLS." The VLS Project is being conducted at the "Centro Tecnico Aeroespacial - CTA", Sao Jose dos Campos. The vehicle is a multistage conventional solid propellant rocket, self-controlled once in flight, and capable of putting satellites weighting from 200 up to 1000 kg [1] into low orbits circa 750 km high. The development of such a spatial system poses significant challenges, specially if one considers the creativity and versatility demanded to satisfy not only technical but also economical and political constraints. The in-flight control system represents one of the great technical challenges, and the embedded software showed to be of special concern, due to its complexity, criticality and the high quality required. Thus, this original experience for the Brazilian reality is an important opportunity to increase scientific expertise in the development of software for critical missions. This paper presents the results of the prototyping approach selected to explore and develop the VLS embedded software project in its initial phase, along with some considerations about the use of this technique for the development of real-time, critical software applications in general. THE EMBEDDED SOFTWARE From a high level perspective, the embedded software, which is considered as part of the control subsystem, has the requirements of:

3 Building Quality into Software 107 Testing the on-board computer and the associated electrical network; Calculating the control algorithms; * Commanding theflightcontrol devices; * Commanding the prescribedflightevents sequence; Preparing data to be sent by the telemetry subsystem; and Providing means to simulation tests. During all flight preceding states, a ground control subsystem is responsible for all monitoring and command functions. In these states, the embedded software (ES for short) receives the mission data and helps to execute the control system tests. After the "Lift-off command, the ES takes over and controls the VLS during the whole flight until injection into orbit. The only possible external command during the flight is the "Teledestruction", that would be sent by the Launch Control Center in the event of aflightdisturbance with possible safety impacts. The ES is responsible for a great number of critical functions. Its failure would cause the mission to be lost. So this real-time software has critical characteristics which demand the development of a high quality product. SOFTWARE PROJECT CONSTRAINTS By the time the VLS Software Engineering Task Group - SETG was created, the required schedule to deliver the software products was defined as 12 months. It was indeed a very short period of time, considering the constraints described below. At this early stage the VLS system was still under development, with many subsystems in conceptualization, definition or design phase. The information necessary to the software project - specially from the control subsystem - had a great number of aspects still undefined or subject to even conceptual modifications. Even among the completely designed subsystems, production or procurement difficulties

4 108 Software Quality Management showed that further changes would be likely in the requirements considered already approved and stable. The on-board computer was not completely defined. Because all preceding Brazilian aerospace vehicles were simpler than the VLS, a team organized, skilled and equipped to develop the software did not exist. The SETG was formed by software developers from several different CTA institutes, thus making a heterogeneous group freshly faced with a complex project. So, all of these problems impinged a high level of uncertainty and a risky horizon upon the software development, making the project quite unstable to follow a traditional sequential process. After researching documents from international organizations involved with critical software development, such as the U.S. Department of Defense [2], NASA [3] and European Space Agency [4], the SETG has verified that the respective standards generally follow a traditional sequential orientation. Although this may not be explicitly mandatory, the process is conceived, controlled and documented as a sequence of project activities, where results of previous tasks are inputs for the next. This would be the SETG option, but faced with all problems described above, the group realized it would be extremely hard to produce the ES within the given time and with the quality required. So the SETG decided to follow the general managerial DOD orientation to document and control the development process, with the appropriated tailoring. However to overcome the risk threats, three major actions were implemented: 1. Reinforcing the procurement activities to guarantee a defined hardware as soon as possible;

5 Building Quality into Software Training the SETG with a continuous improvement philosophy, in order to incorporate Software Engineering techniques and tools stepby-step [6]; and 3. Adopting a prototyping approach to begin the exploration of the software development. Similar hybrid approaches are found in the literature under several different headings, namely: the use of evolutionary projects with prototyping [7]; the controlled experimentation of new approaches and techniques [8]; the combination of waterfall life cycle with prototyping [9], [10]; and the combination of structured techniques with prototyping [11]. Mayhew [12] and others claim the following pre-requisites for successful prototyping: suitable tools, changes in attitudes and a methodology. In the VLS case, the SETG didn't have any specific tools for prototyping, and the incorporation of new methods and attitudes would be a long way to go during the project. So the SETG considered prototyping as a process to develop software starting with an incomplete set of requirements and, with a minimum amount of analysis, project and documentation, to produce models that could help to define the software specification and the design definition. It was expected that such prototype had some characteristics such as modularity and encapsulation that would allow a high degree of reuse, allowing smooth adaptation to the VLS system evolution. Summing up, the prototype approach was chosen with the following objectives: Requirements analysis and specification; * Design alternatives exploitation; Incorporation of reusability characteristics; and Improvement of team capabilities via on the job training.

6 110 Software Quality Management THE PROTOTYPING PROCESS AND PRODUCTS The PC Prototype Since the on-board computer hardware and its respective development environment were not defined, SETG immediately began the production of a prototype to run on IBM-PC compatible microcomputers. When the development system would be available, this PC prototype, already produced with a high reusability level, would be transformed into a Laboratory Prototype. Continuing the development process, this, by its turn, would be transformed into the Target Computer Prototype or, if all the requirements were defined, into the Laboratory Embedded Software to be used in the tests. The Adopted Strategy Once the basic requirements were established, the Task Group conducted a structured analysis and defined the major functions that would comprise the embedded software. Following the typical structured analysis, the functions and data flows were decomposed, along with the analysis of the desired time behavior. With respect to the real-time constraints, a simpler design solution was assumed. Taking the estimated execution time for the more critical functions into account, as well as the sampling period required by the control calculations, it was decided that a real-time executive would be responsible to create, execute and alter a list of functions. The construction of modules followed three general design principles: the independence, encapsulation and reusability principles [13]. With independent modules and functions it was easier to establish a more stable design, according to the level of definition or the possibility of abstraction. In doing so, the majority of functions were made of one generalized part and another specific one, which permitted to isolated those aspects more subjected to further modifications.

7 Building Quality into Software 111 The encapsulation principle was used even in the module documentation. For example, the design of each function was made in pseudo-code and is maintained in the same files as the code itself. Finally the documentation, nomenclature and formats were standardized to improve readability, conciseness, coherency, or in other words, to limit the complexity to the possible minimum. The Results The PC Prototype is almost completed. The development environment and the on-board computer will soon be available. So it will be possible to begin transforming the PC Prototype into the other anticipated prototypes. Getting along with the prototype development, the required software documentation was revised and was useful to discuss and help defining many doubtful points in the related subsystems. DOD-STD formats were adopted for the documentation of other subsystems and were even required for the System/Segment Specification - SSS and System/Segment Design Document - SSDD for the VLS. This demonstrated that even a conservative approach as that one conditioned by the DOD-STD-2167A may be used together with prototyping approaches, specially in the case of many uncertainties. The prototype allowed for the exploration of design alternatives, and even though not all of them could be tested, they were important to help defining requirements. The implemented modules will be useful for the evolution of the project, specially with its generic reusable components. Training developers was one of the most important results, particularly considering many of them had no experience with this kind of software application. Although there were not many opportunities to give training courses, the construction of this prototype allowed the

8 112 Software Quality Management people involved to get in contact with the problems, the theory and the application of Software Engineering in a real case, using the tools and the knowledge actually available. So the Task Group increased its expertise level by means of this evolutionary prototyping. From a quality assurance point of view, this capability improvement is considered to be one of the most important aspects to allow the production of software that meets high quality requirements. The difficulties found in the application of prototyping demonstrated that training people with a defined methodology is very important. The experience acquired is being compiled and will be presented in a coming report as a methodology proposal. In that proposal all managerial and technical aspects necessary to conduct and control the prototyping process will be presented together. Efficient process prototyping may be an important mean to minimize risks in software development [9], [14]. This was experimented in this case, where many undefined aspects of the system were explored and resulted in a more solid basis for the projects continuation. CONCLUSION Due to a significant increase in the time schedule for the VLS project, and the team turnover in the last months, it was realized that, with the gained experience, it would be possible to continue the software development following a more traditional paradigm. Despite this change in prototyping emphasis, it's well recognized that the prototyping approach was important in attaining the following objectives: clarifying uncertainties, producing reusable components and improving team capabilities, which is important not just for this but for future projects. As culture changes are serious issues [15], the consolidation of this experience and the improvement of the proposed methodology is important in order to increase the ability to prototype effectively. It's also recognized that with prototyping CASE environments the

9 Building Quality into Software 113 prototyping process would become faster, more controllable and, in principle, more efficient. Besides the technical usefulness of the prototype, allowing the study of design alternatives, the prototyping process showed to be an important part of a risk analysis. It may give the project manager opportunities to explore those aspects that could be of greater concern, particularly when time schedule constraints are present. Considering the fulfillment of the objectives, prototyping was useful in this case. Since the final products will depend heavily on the quality of the production process, prototyping can be seen as an effective way to improve quality, specially in critical software projects where this is of major concern. ACKNOWLEDGMENT The authors gratefully acknowledge constructive remarks by Prof. J. Santellano and Mr. L.E. Penna Fernandes. REFERENCES 1. IAE. Sistema Veiculo Lanqador de Satelites. Doc. n B2011. Sao Jose dos Campos: CTA/IAE, 28 Set DOD-STD-2167A. Defense System Software Development. Washington, DC: U.S. Department of Defense, 29 Feb Software Engineering Laboratory. SEL Manager's Handbook for Software Development, Revision 1. Greenbelt, Maryland: NASA/Goddard Space Flight Center, SEL, November IAE. Piano de Desenvolvimento de Software do SOAB. Doc n /B3001(ESV-038/920819). Sao Jose dos Campos: CTA/IAE, 19 Ago 92.

10 114 Software Quality Management 4. ESA Board for Software Standardization and Control (BSSC). ESA Software Engineering Standards, Issue 2, ESA PSS-05-0 Issue 2. Paris: European Space Agency, February Howes, Norman R. 'Managing Software Development Projects for Maximum Productivity'. SE-10, n 1, p Greenbelt, Maryland: NASA/Goddard Space Flight Center, SEL, January Wiegers, Karl E. 'Implementing Software Engineering in a Small Software Group'. Computer Language, p , June Glass, Robert L. 'A Report from the Best and the Brightest'. Journal Systems Software. New York: Vol. 14:1-2, Software Engineering Laboratory. SEL Recommended Approach to Software Development. Greenbelt, Maryland: NASA/Goddard Space Flight Center, SEL, April Boehm, Barry W. 'A Spiral Model of Software Development and Enhancement'. IEEE Computer, May Yourdon, Edward. Modern Structured Analysis. Englewood Cliffs, N.J.: Prentice-Hall, Connell, John L. and Linda B. Shafer. Structured Rapid Prototyping - An Evolutionary Approach to Software Development. Englewood Cliffs, N.J.: Prentice-Hall, Mayhew, P. J., C. J. Worsley ad P. A. Deamley. 'Control of Software Prototyping Process: Change Classification Approach'. Information and Sofovare Technology, Vol. 31, n 2, March IAE. Relatorio de Acompanhamento de Atividades do Grupo de Desenvolvimento de Software do Computador de Bordo do VLS. Doc.n^ Sao Jose dos Campos: CTA/IAE, 15 Set 92.

11 Building Quality into Software Roetzheim, William H. Developing Software to Government Standards. Englewood Cliffs, N.J.: Prentice-Hall, Yourdon, Edward. Decline and Fall of the American Programmer. Englewood Cliffs, N.J.: Prentice-Hall, 1992.