Home

Developing Generic Software for Spacecraft Avionics

A standardized functional model would facilitate cost-effective reuse of common software modules.

A proposed approach to the development of software for spacecraft avionics is based partly on a concept of generic software that could be tailored to satisfy requirements for specific missions. The proposed approach would stand in contrast to the conventional approach of first defining avionics requirements for a specific mission, then developing software specific to those requirements. The proposed approach might also be adaptable to programming computers that control and monitor other complex equipment systems that range in scale from automobiles to factories.

The concept of a spacecraft avionics functional model (SAFM) is a major element of the proposed approach. An SAFM would be, essentially, a systematic and hierarchical description of the functionality required of the avionics software (and hardware) for a given mission. Although the initial input information used to start the construction of an SAFM would typically amount to a high-level description, the SAFM would thereafter be decomposed to a low level. The resulting low-level version of the model would be used to develop a set of generic requirements that could be expected to include a large fraction of all requirements for a large fraction of all missions. The generic requirements would be used to develop software modules that could be included in, or excluded from, the final flight software to satisfy the requirements of a specific mission.

By creating the opportunity to reuse common software modules on different missions, this approach would reduce the time, cost, and difficulty of developing the software. In addition, a high degree of reuse is expected to lead to increased reliability.

An SAFM would lend itself to any or all of the following five applications:

  • Education and Training
    The standard breakdown of functionality would be helpful in education and professional training in the functions that occur aboard a typical spacecraft.
  • Systems Engineering
    The breakdown would proceed, more specifically, from functions to subfunctions to roles. Such a breakdown would bring a standard template to part of the documentation of requirements. A standard template of this nature would increase the efficiency and enhance the utility of software tools used to document the requirements, while remaining flexible enough to be useful for a number of different projects. The standard template would, in effect, be a textual version of the hierarchy of the SAFM, placed into the functional- requirements portion of the requirements documentation for the spacecraft in question.
    A key element of this approach is that at the breakdown-of-requirements stage of development of a given system, the requirements would be documented with respect to functionality but would not yet have been allocated to specific subsystems. It would still be possible, at this stage, to develop any of a number of different avionics architectures that would satisfy all the documented requirements.
  • Modeling of Resources
    The next step would be the estimation of the avionics resources used by each of the roles, and of how these avionics resources change with changes in the requirements of the roles. The next step would be to tabulate the resources required for each role, and then for each subfunction, in order to determine the resources used by each function. Once functions were assigned to subsystems, it would then be possible to determine the resources required by each subsystem.
  • Analysis, Tradeoffs, and Estimation of Costs
    If the modeling as described thus far were to be implemented with the help of an automated or semiautomated software tool, the next step would be to model a number of architectures and functional breakdowns. The architectures would differ in the functions assigned to different hardware subsystems. This modeling would yield estimates of such parameters as memory usage, data and processor instruction rates, bus bandwidth, power usage, mass, and volume. These estimates could be used to determine which of the proposed architectures would best satisfy mission requirements, which would be most flexible, and how the different architectures would use system resources. The final step in modeling would be to estimate the costs of the candidate avionics architectures.
  • Functional Standardization and Commonality
    In an SAFM, the relationships among the roles within a subfunction would be the same. In other words, the roles would have constant functional contents, and their inputs and outputs would stay constant, or nearly so. This implies that if a role were used in more than one mission, it may be possible to reuse, from one spacecraft to another, the software module that implements that role. If this were done for a few missions, a library of software modules would soon be built up, making it possible for the next mission to limit itself to developing code for only those corresponding functional modules that were new, that were characterized by significantly different requirements, or that had grown antiquated.

    This work was done by Joseph Smith of Caltech for NASA's Jet Propulsion Laboratory. For further information, access the Technical Support Package (TSP) free on-line at www.techbriefs.com/tsp under the Information Sciences category.

    In accordance with Public Law 96-517, the contractor has elected to retain title to this invention. Inquiries concerning rights for its commercial use should be addressed to
    Intellectual Property group
    JPL
    Mail Stop 202-233
    4800 Oak Grove Drive
    Pasadena, CA 91109
    (818) 354-2240

    Refer to NPO-20968, volume and number of this NASA Tech Briefs issue, and the page number.

This Brief includes a Technical Support Package (TSP).

Developing Generic Software for Spacecraft Avionics (reference NPO-20968) is currently available for download from the TSP library.

Please Login at the top of the page to download.